Memphis IETF ngtrans-6bone WG minutes

[Bill Fink]

> Date: Tue, 15 Apr 1997 21:18:58 -0700
> From: Bob Fink <RLFink@lbl.gov>
> 
> 1. an exchange (like a NAP with extra functionality) can be registered as
> well as a provider at the top-level.  This makes it quasi geo/metro-like.
> People getting their delegation from an exchange (as opposed to a provider)
> will then arrange who will be their transit provider beyond the exchange
> point of connection, and won't have to renumber as long as the exchange
> operator stays in business.  Maybe transit arrangements are also another
> business opportunity for the exchange operator.

I like this.

> 2. the TLA (Top Level Aggregator) is limited to 13 bits to limit the
> high-level routing complexity.  no words yet on who gets to be one of
> these...stay tuned.
> 
> 3. no registry bits are wasted, small blocks of TLAs will be handed out to
> various registries as appropriate.

This is kind of critical.  For the Federal networking addressing
I'm working on, I'd like to have the IANA allocate a small block
of TLAs to for example NIST, as the standards body for the US, who
could then suballocate portions of this space to various federal
organizations.  The general consensus among the federal groups I
am working with favors some type of geographic based addressing
scheme.

> 4. the IEEE EUI-64 was accepted, thus fixing the node id to 64 bits and
> reducing the "routing goop" site prefix size to just 48-bits.  With the
> site partition (subnet) field being 16 bits it means that the routing is
> now able to be done on 64 bits.

I really don't like this at first glance.  64 bits of basically flat
space for a given subnet seems like major overkill.  I thought that
48 bits of flat space was overkill, but I could see the significant
advantage to that.  I don't see any advantage to increasing this to
64 bits and I do see a major disadvantage.

The disadvantage is that it only leaves 32 bits for the NLA, which
seriously reduces the flexibility of the RG.  If you broke this down
for example into 3 fields for provider, sub-provider, and site, each
field would only be about 10 bits or about 1000 possibilities, and
you might want to have more fields.  For the geographic based scheme
I was proposing as a strawman, I had 5 fields, namely region (10 bits),
metro (10), locality (10), organization(10), and site (8), which adds
up to 48 bits.  Trying to squeeze something like this down into 32
bits would be quite difficult.

> 5. the EUI-64 "global/local" bit will have significance in that if it is
> set to "global" it may be treated as globally unique, while setting it
> "local" will mean that it can then be formatted in a non-globally unique
> fashion.

Maybe I missed it in the web page reference, but I didn't notice any
reference to the "global/local" bit, although I know they have this
for EUI-48.  Once again, I don't see any utility/advantage to using
EUI-64.  EUI-48 makes sense since it's used quite universally in
Ethernet, FDDI, ATM, etc MAC layer addresses, but I've yet to see
anything that uses EUI-64, and it just seems a monumental waste of
valuable address space.

>  | 3 | 13 bits |      32 bits   |    16   |            64 bits              |
>  +---+---------+----------------+---------+---------------------------------+
>  |010|   TLA   |        NLA*    |  subnet |        EUI-64 node id           |
>  +---+---------+----------------+---------+---------------------------------+
> 
> TLA = Top Level Aggregator
> NLA* = Next Level Aggregator
> EUI-64 = http://standards.ieee.org/db/oui/tutorials/EUI64.html
> 
> >I'm working on a Federal networks ATM addressing plan, and I'm proposing
> >to use IPv6 addresses embedded in ATM NSAP addresses.  I was originally
> >planning to use a geographic based scheme, but perhaps I should check
> >out this new addressing I-D to see what options it provides.  The bottom
> >line is I need real IPv6 addresses from some registration authority.
> >Is a registry for the US / North America defined at this point for any
> >of the addressing options?
> 
> No registry exists at this time.  We anticipate starting with a test TLA
> for the 6bone so we can start testing this whole thing, including
> delegation and renumbering, as soon as possible.

As indicated earlier, I would like to see IANA allocate a small block
of TLAs to someone like NIST, who could then suballocate addresses to
US federal organizations.

> Comments now appropriate from "all" on usability of EUI-64 for your
> purpose.  There is a registry for it.

EUI-64 would make what I'm trying to achieve more difficult, since
there's no longer a natural match with existing 48-bit MAC addresses,
which the ATM addressing currently uses as the ESI.  However, I'm not
saying it's impossible, only that it's no longer as natural a fit.
Also, for handling IPv4 addresses in ATM NSAP addresses, I was looking
to embed the IPv4 address in the low order 32 bits of the ATM NSAP
address (not counting the SEL field), with an appropriate IPv6 route
prefix (RG) in the upper bits of the ATM NSAP address (not counting
the AFI/ICD fields).  I'll have to see how this can fit into the new
aggregator based IPv6 addressing format.

> Apologies if I've misrepresented any of Bob's ideas here, but it is
> probably useful to have some interpretation of this plan while we are
> waiting on Bob :-)

I think it's quite useful.  Thanks for sketching it out.  I look
forward to reading all the gory details when the I-D comes out.

> Bob

						-Bill