Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/ipngwg/ipng-interim-minutes-97feb.txt

Text File | 1997-05-22 | 30KB | 812 lines

Editor's Note:  These minutes have not been edited.


IPng Working Group
February 27 & 28, 1997
Palo Alto, CA USA

Bob Hinden, Steve Deering
Co-Chairs

Meeting hosted by Allyn Romanow / Sun Microsystems, Inc.  Many thinks to
Allyn and Sun for this service to the IETF.

The minutes were taken by Bob Hinden.

----------------------------------------------------------------------
----------------------------------------------------------------------

Agenda
-------

Thursday
   Introduction
   Review Agenda
   8+8 Overview
   Detailed Review
      Uniqueness of ESD's
      DNS forward lookups
      DNS reverse lookups
      DNS Structure
      TCP/UDP Connection Identification
      Effects on Applications
      Rewriting of RG (inbound, outbound)
   Lunch
   Continuation of Detailed Review
      Map RG into current Internet
      Rehoming Site
      Multihoming Site
      Rehoming Multihomed Site
      Rehoming Small Provider
      Multihoming Small Provider
      Rehoming Multihomed Small Provider
   Summary of Discussions
Friday
   Review Remaining Agenda
   Review impact on existing specifications
      Base IPv6 Specification
      Addressing Architecture
      Provider Based Addressing Documents
      Neighbor Discovery
      Address Autoconfiguration
      IPoverFoo
      ICMP
   Lunch
   New Documents which Need to be Written
      GSE Specification
      ESD Guidelines
      RG Allocation
   Impact on Implementations
   Summary and Conclusions


Review of Agenda
----------------

Discussion about purpose of meeting and outcome of meeting.  Possible
outcomes:

 1) Working group will not adopt GSE proposal.
 2) Working group will adopt proposal.
 3) Working group leaning toward adoption, but there important missing
    pieces that must be specified before the working group can make final
    the decision

What problems is this solving?  Suggestion was made to generate list of
pro's and con's


Problems being Solved / Mike O'Dell
-----------------------------------

Goals and Non-Goals

Goals:

Thinks biggest problem in internet is complexity of routing computation
in the backbones (where there are no default routes).  Specifically, the
cost of BGP computations increases as internet grows and policy issues
become more complex.  Thinks computation grow is exponential.  Issue is
that from a routing perspective the backbone is relatively flat.

Why is this better than current provider based design?  Current provider
based topology schemes rely on renumbering sites to improve route
computation.  He thinks the aggregation model for provider based
addressing has potential for catastrophic collapse.  What could happen is
that a few very large sites will refuse to renumber (i.e., lawyers go to
court), and that will effectively stop everyone from renumbering.  CIDR
has worked well, but will not continue into the future.

GSE deals with this problem by keeping changes resulting from renumbering
the Internet local to edge of site, and keeps changes from propagating
into the site.  Internal routing infrastructure is isolated from external
changes.

Proposal allows backbone routing topology to change independently of
sites without having to get the sites involved in.  Advantage is allows
backbone renumbering to happen independently from site renumbering.

Allows Multihoming without increasing size of backbone routing.  This is
important because more and more sites are becoming Multihomed.

Also helps second tier providers to change their first tier providers
without forcing their customers to renumber (and potentially losing their
customers).  This is a very important benefit.

Comment by Masataka Ohta: Doesn't think completely solves multihoming,
but is a good first step.

Non Goals:

Does not solve mobility problem.  Does not keep TCP connections alive
during renumbering.

It would be nice to have TCP connections survive loss of one connection
when multihomed.


Uniqueness of ESD's
--------------------

6Byte IEEE Mac's are proper subset of 8byte IEEE-1394 (firewire)
addresses.

Are they unique enough?

Dimitry Haskin said he doesn't like using MAC addresses for ESD's.  He
would like something which has same properties of current IP address.

Discussion about how most sites will use MAC, while still allowing sites
to use something else if desired.

Jim Bound thinks it is unique enough.  ESD should be eight bytes long.
Discussion about this.

Thomas Narten: What are the consequences if there is a collision?  Easy
to detect on a link, but hard to detect globally.

Steve Deering suggested that it is a relatively low probability event.
We could later build in additional mechanism to help deal with this.

Are IEEE1394 addresses compatible with SMDS addresses?  Not an issue,
SMDS addresses are E.164.

Erik Nordmark: Think they are unique enough.

Hinden: Thinks MAC address will be unique enough.  He mentioned that MAC
only addressing has been used successfully in large bridged networks and
in large IPX networks.  Also, IPX networks are mostly PC which is the
area where there has been the most concern about duplicate MAC address.

Bound: Do we have a consensus on uniqueness?

Questions about systems (such as Sun's) which only have one MAC per Node?

Long discussion.

Group concluded that IEEE Mac addresses are unique enough to serve as
globally unique ESD's.


Does ESD need to have structuring?
----------------------------------

Masataka Ohta: Thought they should have structure for security.
Discussion about this point, concluding that structure was not necessary
for the purpose.

Jim Bound: This all requires changes to DNS.  Everyone agreed.  He does
not think there is a need for structure in an ESD.

Assumption that to do reverse mapping is more difficult if there is not
some structure in ESD.  Discussion of this point.

Discussion evolved into what are requirements for reverse mappings of
ESD's.  Alternative suggestion was made for ICMP "Who Are You" with ICMP
"I Am XXX" message returning DNS name to perform this reverse mapping
function.

We will need manual defined ESD space, but this should be the exception.
Most nodes will not need to use.


Discussion about Adding Routing Goop Records to the DNS
-------------------------------------------------------

Proposing to add "site names" to DNS.  Would correspond to routing group
for site.  Could reverse lookup RG to "site name".  "Site name" is not
the same as DNS suffix.

Important to only do connection identification using only ESD, not
RG+ESD.  This will allow future development of secure RG redirect later
to improve transport behavior when RG changes.

Assumption that site renumbering was relatively infrequent, not a
frequent "real time" event.

Discussion about use of RG as identifier for site and effects on
firewalls.

There will not be inverse lookups of IPv6 addresses!  It will be replaced
by ICMP "Who Are You" message.

Matt Crawford raised issue about rate limiting "Who Are You" messages.
He is concerned if senders don't cache answers.  This could create a
heavy load of "Who Are You" message.  An alternative is to have the DNS
servers send the "Who Are You" message when the receive a reverse mapping
request.  This seems to be a good idea.

Rough consensus of the group is that ESD's do not need to have structure.

Dimitry Haskin pointed out that for links which do not have MAC such as
PPP serial links we can no longer auto-configure these links.  ESD's for
these links will have to be manually assigned.  This is about the same as
IPv4 operation today, but not as good as what the current IPv6 over PPP
specification provides.  Is this an acceptable limitation?

Discussion about use of random numbers as ESD tokens.  Are they unique
enough, etc.  Not much agreement on using random numbers as ESD tokens.


Mike O'Dell Presentation on Multihoming
-------------------------------------


        Provider Provider
            1       2
          +----+ +----+
          |    | |    |
          |    | |    |
          |PBR | |PBR |
          +--x-+ +-x--+
             |     |
          RG1|     | RG2
             |     |
          +--x-----x--+
          | SBR   SBR |
          |           |
          |   Site    |
          +-----------+

   If RG1 link fails, then Provider PBR tunnels traffic which would have
   been sent to the site via RG1 and sends it to the Provider 2 via RG2.
   Requires that both PBR in site 1 & 2, and SBR's understand that tunnel
   has been created.

If TCP saves RG when SYN packet is received for connection, and never
switches to RG received in subsequent packets, it can protect against
it's connections being hijacked.

Long discussion, even more complicated pictures and scenarios.

Hinden asked question of how this was different/better from what can be
done with current IPv6 specifications.  Not clear what the win is here
for multihoming.

Erik Nordmark made observation that if node remembers all of the RG's
returned from the original DNS lookup, then it would be OK for it to
switch to one of the returned RG's if packet started arriving from a
different one.

Rebecca Nitzen talked about how in this scheme it will be very easy to
load share multihomed site.  Traffic in both directions will follow the
same route.  The only thing necessary to do is divide the primary default
between the ISP connections.  Might also be possible to return DNS
replies for the site to divide the load by replying with the appropriate
RG based on where the requester is.


TCP/UDP Connection Identification
---------------------------------

Pseudo header checksum always use ESD.

Do we require all unicast to work the same way?  Yes.  OK for provider
addresses which been autoconfigured.  Important to require all addressing
plans to have same characteristic.

How about multicast addresses?  Include an ESD?

Discussion about what to do when node starts receiving packets with new
routing goop.  When node does not have any other information, node should
drop packet.  If node thinks the new routing goop is valid (perhaps by
having received it in original DNS lookup) then it can reply and start
sending to new Routing Goop.

Need to look at what happens if routing goop is corrupted?  This needs
analysis to access the impact.

Long discussion about if some of the RG could be included in the
checksum.  Allison proposed having the host include it's RG in checksum.
Not clear how source node would get RG.  Makes rewriting RG on in bound
traffic impossible (?).  This could be viewed as a hybrid proposal.

Mike O'Dell suggested that TCP should not bind to a particular RG for
remote side until three way handshake is completed.

General comment made that it is important that this proposal not change
TCP protocol.  No TCPng!!!!!!

Long discussion about what happens if RG is corrupted.  Worst case is
when first SYN packet is corrupted because connection will never be
established.

Erik Nordmark asked would implementing this architecture make it harder
to make changes to TCP later in the future?  What is the effect of hiding
RG from the host?

Matt Crawford proposed that we continue to rewrite RG, do not include RG
in pseudo checksum, non-established TCP treat packets with different RG
as different connections, for any UDP or TCP in established state pass
all packets to application, connected socket for any transport do not
update outgoing RG address.

Long discussion about connection identification, checksums, what happens
when RG changes, etc.

Jim Bound stated that renumbering while important was it was not the top
of the list of what his customers wanted.

---------------------------------------------------------------------------
Friday
---------------------------------------------------------------------------

Introduction to meeting.  Today will continue detailed review of
proposal.  Start with DNS issues.  Continue to work through the list:

   Uniqueness of ESD's
   DNS forward lookups
   DNS reverse lookups
   DNS structure (effect on caching, performance)
   TCP/UDP Connection Identification
   Effects on Applications
   Rewriting of RG (inbound, outbound)
   Effect on V6 mobility, multicast, anycast


DNS Forward lookups
-------------------

What if site is multihomed, does requester get multiple DNS entries?

Two-Faced DNS

Solution: Remote DNS are sort of part of local universe, so they need to
know site RG and provide appropriate answer.

Jim Bound: Thinks the split between RG records and AAA will work.
Suggested list of topics to discuss on DNS:

 - Boot strapping DNS delegation records
 - How do replies get fabricated
 - What new record Types
 - Two faced DNS
 - Dynamic Update to RG (for renumbering)

Boot strapping DNS delegation records
-------------------------------------

Need to have hard coded address of DNS servers.  For example to get to
foo.sun.com, .com server needs to have address of ns.sun.com.  This is
way IPv4 works today.  Discussion focus on making DNS servers have
addresses which are not renumbered.  This should work as long as there
are not too many DNS servers.  Need to update DNS servers when RG
changes.  Likewise this is essentially the same as IPv4 and a general
IPv6 issue not specific to this proposal.

When site renumbers, it must change it's DNS servers.  When an ISP
renumbers it must make it transparent to sites.  O'Dell suggested that if
DNS servers get RG info from routers this could be made easier.

Problem could be made less severe if the top level name servers had
addresses which were not renumbered.  We could support some amount of
non-renumbered addresses for important servers.

Important to identify where in DNS there are hardwired addresses.

Thomas Narten: This is a generic point about renumbering.  Not specific
to this proposal.


What new record Types
------------------------------

    RG Record
    AAA  (Deering suggested calling it "aAA")


How do replies get fabricated
------------------------------

Matt Thomas suggested that AAA record be split into Subnet + ESD record
(AA) Matt Crawford agreed this would be a good idea.  We do need a site
record for RG?

General conclusion that splitting the DNS records was a good idea even if
proposal not adopted in whole.


Two Faced DNS
-------------

Server has to have information to know what kind of reply to send.  If RG
of source address from request is same as RG which was to be in the reply
it should substitute site local RG.

Matt Crawford described a problem where DNS queries are forwarded between
servers, RG will be lost as request goes between sites and backbone and
this will not be work.

General conclusion that these topics needs an owner to describe how all
of this works.


Dynamic Update to RG (for renumbering)
--------------------------------------

Decided this was a future need and was not required now for this
proposal.


Effects on Applications
-----------------------

 - Prohibition of Storing non-refreshed non-ESD addresses.  Not specific
   to this proposal.  General renumbering (and transition to IPv6) issue.

 - Use only ESD for peer identification (not address)

 - Avoid carrying addresses in payload

 - Flow identification.  Probably need to only use ESD instead of whole
   address.

 - Effect on reassembly

 - All packet identification needs to use ESD's

 - Effect on routing header?  If RH is to be replied then BR would have
   to fix up RG inside of RH.  This happens on both first exit BR and
   final BR.  Not clear if it is important to make source routes RH
   reversible.  Border router (which may not be one of the SR hops) will
   have to know to look inside of RH to rewrite appropriate RG's.

   Might be better to embed DNS names in packets because they are global
   and can be looked up.

   Comment that overall this adds complexity for programmers.  They would
   need to have good understand of RG, subnet, ESD's, addresses, and how
   they interact..  Prior to this proposal they only need to understand
   addresses.

 - Effects on tunnels.  If tunnel crosses site boundary, end points must
   perform BR functions.  Which router does rewriting?  Long discussion
   on how this works.  End point of tunnel needs to be able to rewrite
   destination RG w/ site prefix.  Host-Host secure IPSEC tunnels
   require hosts to be able to recognize that the RG (actually it's own)
   is one of it's interface and accept the packet.

   Anytime you tunnel it in effect requires all tunnel end points to be
   border routers.  They need to be able to rewrite RG on exit and entry.

   Renumbering breaks all configured tunnels.

- Addresses in MIB's and Address in SNMP Traps.  Makes it harder for agents.

- ICMP error messages.  Returned packet has packet with error.  Need to
  only look at ESD to match error reply.


Steve Deering's fortune cookies from lunch
------------------------------------------

   "A thrilling time is in your immediate future"
   "Avert misunderstanding by calm, poise, and balance"
   "He who hurries cannot walk with dignity"
   "If your desires are not extravagant they will be granted"
   "Simplicity and clarity should be your theme in dress"
   "Strong and bitter words indicate a weak cause"
   "The best prophet of the future is the past"
   "The laws sometimes sleep, but never die"
   "Time is precious, but truth is more precious than time"
   "What's vice today may be virtue tomorrow"
   "Wise men learn more from fools, than fools from the wise"
   "You have a quiet and unobtrusive nature"
   "You will be recognized and honored as a community leader"


TCP Connection Identification / Matt Crawford & Allison Mankin
--------------------------------------------------------------

If checksum doesn't cover RG, and we want to accept packets from
different RG's, there are a few problems.  The most serious are avoided
by sending only to one RG in any given connection.  Replying to any RG
that is heard from opens TCP to serious security and reliability holes.

Proposed Rules for Case of RG-Rewriting, RGs not Checksummed:

 1. Accept any source RG on incoming packets and deliver to application.
    Only use ESD for this.

 2. For Active TCP "Open" and all UDP: Application specifies destination
    RG.  Send only to the application's requested RG, but receive from
    any.

3.  For Passive TCP Open: send only to the first RG that arrives during
    the opening handshake.

Based on 3., if source RG is corrupted, the connection will never open.
The passive open side will ack the good SYNs to the corrupt return RG of
its peer.  The alternatives to this (if we can't have the sender able to
checksum its local address's RG) require opening up the TCP handshake
logic into three or so special cases, and they also may still have
security problems.

Result: if there is a bit error in the source RG received in TCP LISTEN
state, the rescue can only come from a higher layer than TCP.  Weighed
likelihood of this corruption against the risks of choosing from among
several RGs that arrive during the handshake, and decided the best thing
to do is recommend that source RGs be known to senders, so they can be
included in the checksum.

Corrupted of destination RG is not a problem.  Packet will be
misdelivered and discarded, retransmission will get to correct site,
connection will open.

Because of never switching RG, multihomed connection will be broken if RG
changes.  Also applies to rehoming.

The approach does help when there are two different RG exit paths and
routing changes which causes a different RG to start being used in the
middle of the connection.

Nordmark noted that this makes connection identification easier than
existing IPv6 because only need to look at ESD instead of list of
possible addresses.  Also suggested that it might be worse because sender
doesn't know anything changed.

Future transports could be developed which allow complete separation of
RG and ESD which had other connection identifications mechanisms,
authentication, etc.


Conclusions
-----------

Deering asked group for their overall impression of what people think now

Mike O'Dell:  He draws several conclusions:

Thinks it is unreasonable to move forward with the current proposal.

Thinks there are a number of things which are worth pursing.  There are a
bunch of pieces which we think we should do.  This has really pushed our
thinking about what it means to renumber.

Most of hard questions dealt with impact of renumbering.  He is
perfecting willing to not go forward with his as main proposal. Thinks we
should see what we can extract and move forward.

Steve Deering: Can we still get some of these advantages with current
scheme?

Mike O'Dell: Long term requirement is to control aggregation topology
independent of getting sites to participate.  That was the fundamental
goal.  This proposal does not enable this in toto.  Still other things
which need to be done.

Questions is what pieces should we take?

Jim Bound: Likes some of the parts of GSE, does not like some of current
parts of provider based addressing.  There are lots of pieces here which
are improvements.  Main thing didn't like was the renumbering approach.

Dimitry Haskin: Agree with Mike that at this point proposal is not
deployable.  Too much risk involved.  When meeting started he thought it
was feasible, but now thinks it is not possible.  Should we continue
working on proposal as research project?  Not practical for deployment
now.  Could have a transition mechanism.

Lixia Zhang: Thinks fundamental problem is renumbering.  DNS still needs
work.

Charlie Perkins: Agree this is too much definition to be done in time for
IPv6 deployment.  Likes separation of address into ESD and locator.
Might make other problems easier in the future.

John Stewart: Advantage he sees of independent of rewriting packets is
aggressive aggregation.  This proposal does it by rewriting of
addressing.  Wondering if there is a middle ground with provider based
addressing but changing with [???]  Take best pieces of each approach.
There are lots of subtle transport issues that we may not understand yet.

Mike O'Dell: Believes that large structure proposal used is a much better
model for aggregation than provider based addressing.

Margaret Forsythe: Thinks the addressing part is inherently useful.
Could have something like this, but do not need to take full advantage of
this now.  New transport protocols could take advantage of protocol.

Allison Mankin: A lot of the attractions are ones which are ones which we
have been striving for in the IPng area.  Thinks would be a shame if we
didn't pursue this.  Thinks we should pursue some parts of GSE in
transitional way.

Erik Nordmark: Thinks it would be useful to take advantage of ESD's.  We
could use for connection identification.

Bob Hinden: Suggested that it is good to require an ESD in all addresses.
This may have advantages for multihoming (sites and nodes) and permit new
transport protocols to be developed which take full advantage.

Jim Bound: Will put out draft why renumbering is not important.  Location
and identification is not going to work for a long time.

John Stewart: Ramification of large routing tables along with increase
with things like multihoming.  Reasons why we now need to aggregate from
leaf up.  Single homed sites do not need any information about routing
(just default), they don't much want any pain to renumber.  We should put
the work of renumbering in places which need flexibility.  Multihomed
sites.

Alex Conta: Thinks current provider based addressing scheme is good.
Reason we thought that provider based scheme was thing to do, because we
thought there would be problems with separate identification and
location.  We now have a better view of the costs of renumbering.  We
should document this.  Cost to site, provider, etc.  Could also conclude
the multihoming problem is not solved by node-id and locators.  GSE did
seem to provide better form of aggregation.  We should continue looking
for better forms of aggregation.  Conclusions we draw today are the high
costs for using GSE to improve aggregation.

Dimitry Haskin: Does not like requirement to make ESD in all addresses.
He is opposed to this.  Thinks price of administration is too high.

Matt Thomas: Like the ICMP "Who Are You" message and putting it in DNS
server.

Dan Harrington: Renumbering is hard, we now know better.  Need support to
support multihoming without breaking aggregation.

Matt Crawford: Hope that by 3:30pm we will list topics to pursue.  For
now have the sense of the room but thinks that it is something that is
worth going forward with but don't have time to fully pursue.  Should do
a few small things now to allow options later.  Possibilities:

  - PCB Lookup Rules
  - Pseudo checksum rules
  - "Who Are You" you message
  - 8 byte node id
  - Two faced DNS ?

O'Dell added:

  - Split records in DNS
  - Revisit provider based addressing model.  Problematic.
  - Minimal address is to split

Steve Deering:

    Keep term "Routing Goop"!!!

Erik Nordmark: Argument to make two faced DNS is to isolate site from
changes would be to return site local addresses in site to site local
communication.  Reduces the risk of a failure of renumbering from
disrupting site communication.

Allison Mankin: Should remove "registry" field from provider based
addressing.  We can work to improve this.

Steve Deering: TCP depends on it's weak security by depending on address
providing both location and identification.  TCPng could do different
things which allow separation.

Jim Bound: Seconds large structure internet draft.  Provider based
document was compromise.  Thinks we can do better.  Agrees about TCP weak
security.

Bob Hinden: Suggested that if connection identification is limited to ESD
and pseudo-checksum covers full addresses (essential providing packet
integrity) that it would be easier to support multihomed sites and nodes.
TCP would then accept packet sent from any interface of multihomed node
and/or received on any interface, but avoids the problems relating to
corrupted source addresses.

Masataka Ohta: Hope that many things can be made to work with GSE.  Would
like pursue as an informational RFC.

Thomas Narten: Will need a two faced DNS if we are using site local
addresses.

Allison Mankin: There should be work done to develop a new transport
which could just work with ESD's.


Next Steps
----------

Steve Deering broke out parts of proposal to see what parts the working
group could move forward.

Node ID: Change from 6 bytes to 8 bytes.  This would break provider based
addressing documents.  Discussion about keeping 6byte MAC or expanding to
allow 8 bytes.  Deering polled group.  Most people thought we should
change to make room for 8byte MAC.

Brief discussion and poll to put structure in ESD's to allow lookup.
Strong consensus to not add structure to ESD's.

Group initially agreed that low order 8 bytes would be required to be
globally unique.  This will make it harder for links without built in MAC
addresses.

More discussion.  Now less clear that there is a consensus on making ESD
globally unique.

Conclusion is to review the ESD issue at the Memphis IETF.  We need more
data before we can make a final decision.

RG Structure: General agreement to rewrite provider based addressing
specifications.  We can make a number of improvements.

PCB look up rules: Document now, but decision depends on making globally
unique ID's.  Also applies to flow identification, fragment
identification, etc.

Checksum: Don't change pseudo checksum algorithm.  Will continue to
include full IPv6 source and destination addresses.

Two faced DNS is useful for site local address.  Work on how to use site
local addresses for intra-site communication.

Summarized into the following table:

  Legend:  X = do not adopt
           Y = adopt
           * = needs more study

  X  Rewriting by routers
  X  Name for Sites & Mapping to/from RG
  *  ESD's
  Y  RG structure
  *  PCB Lookup rules
  X  Pseudo checksum rules
  Y  8byte node ID
  Y  Two faced DNS for site local
  Y  Resolve DNS via ICMP "Who Are You"
  Y  DNS response synthesis
  *  Auto-Injection of prefixes into sites
  Y  Inter-provider partition healing protocol(s)
  *  Use only site-local prefixes for intra-site communication
  *  How much of address is AH
  *  Flow identification change
  *  SA Ident change


Actions Items for Memphis
-------------------------

1. Minutes for this meeting, and meeting report / Bob Hinden

2. "WhoAreYou" ICMP Message / Matt Crawford

3. Modify Link Name Draft / Dan Harrington

4. Synthesized AAAA Replies / Jim Bound , Mike O'Dell

5. Revised Provider Based Addressing and Addr Architecture / Mike O'Dell
   and Bob Hinden

6. Unique ID's (ESD's) Assignment, Mike O'Dell, Allison Mankin, Matt
   Thomas

7. Experimental Addresses Rewrite:  Bob Hinden

8. IPoverEthernet/FDDI :  Matt Crawford

9. IPoverPPP: Dimitry Haskin

10. Lessons from meeting: Thomas Narten, John Stewart, Allison Mankin,
    Lixia Zhang, Matt Crawford


Work We Think Other People Should Do
------------------------------------

1. Non-corrosive multihoming of sites (partition homing)
2. Auto-aggregation of public topology
3. Auto-aggregation of site topology
4. Auto prefix dissemination in site
5. Auto prefix acquisition by sites
6. DNS vs. Renumbering


Meeting End
-----------

Next meeting will be at the Memphis IETF.  Sessions are schedule for
Thursday and Friday.

---------------------------------------------------------------------
---------------------------------------------------------------------