Re: initial issues

[Brian E Carpenter <brian@hursley.ibm.com>]

I agree. 
  Brian

Jim.Bound@nokia.com wrote:
> 
> 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
> >

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: brian@icair.org