RE: initial issues

[Jim.Bound@nokia.com]

good mail Thomas. It is very important the community adhere to Thomas's
warning here about not pressing hot buttons.  That will start this whole
effort off on the wrong foot. Also ipng has not even heard this yet so lets
be cool.

also for the multihoming jargon for the charter and discussion we need to
make sure we define all acroynms no matter how common up front.  Don't
assume anything.  Also vince's explanation of aggregation entropy needs to
be somewhere too and other abstractions that will be useful to those in the
wg.

lastly as an implementor of ipv6 stacks (doing another one now) I do not
take stock of TLA/NLAs or even the Format Prefix bits.  All code treats ipv6
as classless.  I think TLA/NLA have other values but not to avoid classless.
The only real implementation that may take dependency on TLA/SLA boundaries
are the A6 records in DNS fyi and that is being discussed now on ngtrans.
This may be more input for that discussion at some point.  Even the APIs
don't look at the address as non classless.

/jim

> -----Original Message-----
> From: ext Thomas Narten [mailto:narten@raleigh.ibm.com]
> Sent: Tuesday,February 13,2001 1:02 PM
> To: Brian E Carpenter
> Cc: Sean Doran; multi6@ops.ietf.org
> Subject: Re: initial issues 
> 
> 
> Things are jumping a little bit of ahead of themselves. To clarify:
> 
> Brian E Carpenter <brian@hursley.ibm.com> writes:
> 
> > Sean Doran wrote:
> > ...
> > > Randy noted also that
> > > the IESG has asked for a revision to §2.5.6 of 
> > > draft-ietf-ipngwg-addr-arch-v3-04.txt to make it classless rather
> > > than clasful.  In other words, the multihoming environment for v6
> > > is going to be identical to v4, viz. CIDR.   TLA/NLA will 
> no longer exist.
> 
> > Somehow I doubt if this is a done deal in the WG.
> 
> 
> The IESG is currently discussing
> draft-ietf-ipngwg-addr-arch-v3-04.txt. The IPng WG has requested that
> it be advanced to Draft Standard. During the IESG discussions, text
> relating to Section 2.5.6 is being scrutinized (appended here for
> your reading pleasure).
> 
> > 
> > 2.5.6 Aggregatable Global Unicast Addresses
> > 
> >    The global aggregatable global unicast address is 
> defined in [AGGR].
> >    This address format is designed to support both the 
> current provider
> >    based aggregation and a new type of aggregation called exchange
> >    providers.  The combination will allow efficient routing 
> aggregation
> >    for sites which connect directly to the current type of 
> providers and
> >    who connect to exchange providers.  Sites will have the choice to
> >    connect to either type of aggregation point.
> > 
> >    The IPv6 aggregatable global unicast address format is 
> as follows:
> > 
> >    | 3|  13 | 8 |   24   |   16   |          64 bits               |
> >    +--+-----+---+--------+--------+--------------------------------+
> >    |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
> >    |  | ID  |   |  ID    |  ID    |                                |
> >    +--+-----+---+--------+--------+--------------------------------+
> > 
> >    Where
> > 
> >       001          Format Prefix (3 bit) for Aggregatable Global
> >                    Unicast Addresses
> >       TLA ID       Top-Level Aggregation Identifier
> >       RES          Reserved for future use
> >       NLA ID       Next-Level Aggregation Identifier
> >       SLA ID       Site-Level Aggregation Identifier
> >       INTERFACE ID Interface Identifier
> > 
> >    The contents, field sizes, and assignment rules are defined in
> >    [AGGR].
> 
> The point has been made that this address format, and in particular,
> the hard boundaries that are implied here, have no business being part
> of the IPv6 *architecture*. That is, from the perspective of
> implications for implementors, these boundaries are meaningless and
> shouldn't be taken into consideration in implementations. Furthermore,
> the boundaries themselves may not be correct today (or ten years from
> now), so again, having them be part of a draft standard seems
> inappropriate. So, one of the discussion points has been to move this
> out of draft-ietf-ipngwg-addr-arch-v3-04.txt. Some other points have
> been discussed, but they haven't been written up yet. I.e, this is
> fast-breaking news (all in the last few days) and so hasn't made it to
> the IPng list yet (or to the WG chairs, authors, ...)
> 
> Also, let's be careful about terminology here.  Calling the TLA/NLA
> stuff equivalent to "classful routing" is (IMO) at best misleading and
> has a tendancy to push people's hot buttons in ways that is NOT
> productive or constructive, as the implication is that IPv6 is
> reinventing classful routing, and hasn't learned anything from IPv4
> and CIDR.
> 
> Thomas
>