Memphis IETF ngtrans-6bone WG minutes

[Bill Fink]

> Bill,
> > 
> > >I'm working on a Federal networks ATM addressing plan, and I'm proposing
> > >to use IPv6 addresses embedded in ATM NSAP addresses.  
> 
> I have to say I don't see the advantage in this; they are
> orthogonal addressing spaces. But if you do it, I hope you'll
> use the mapping in RFC 1888, section 6. 

Brian,

Well, IEEE 48-bit MAC addresses are orthogonal to IPv6 or ATM NSAP
addresses but there was apparently an advantage to embedding MAC
addresses in IPv6 and ATM NSAP addresses.

I happen to think there are major advantages to be obtained from
recognizing that both IPv6 and ATM NSAP addresses are 128 bits long
(not counting the AFI/ICD and SEL fields in the ATM NSAP addresses),
hierarchical, and globally unique, which allows a very natural
equivalence to be formed between the two addressing spaces.

Some of the major advantages of this approach include:

	* Simplicity and ease of understanding

	* Facilitates and simplifies network management and
	  troubleshooting of ATM networks

	* Works with both IPv4 and IPv6

	* Eliminates the need for the complexity of NHRP
	  (and possibly also ATMARP at a later stage)

	* Provides for direct shortcut routing across an ATM
	  infrastructure across LIS boundaries

	* Provides for distributed ATMARP service

	* Very easy to implement

	* Only one name and address space to devise, administer,
	  and manage

	* Scalable

	* Minimizes latency on connection setup

	* DNS would also be a directory for ATM addresses which
	  would facilitate native ATM operation if desired

	* Uniform user interface and maximum user benefit

	* Can leverage existing IP capabilities to provide the
	  same capabilities at the ATM layer, and IP can take full
	  advantage of the ATM layer - basically avoids unnecessary
	  duplication of effort which would otherwise be required
	  in solving the same basic problem (such as security
	  considerations) at multiple layers

My early ideas on all of the above I wrote up in a long since expired
Internet Draft entitled "IP/ATM Integrated Routing & Addressing (IRA)
Model".  If anyone is interested in checking it out, it is still
available at:

	http://www.nasa.atd.net/draft-fink-ipatm-ira-00.html

I am considering writing up a new version of the IRA Model I-D
(if I can ever find a few free days), based on comments I received
on the original and additional ideas that have occurred to me after
additional thought on the subject.  The one thing that has held me
back is that the IP switching model is probably an even better way
of integrating the IP and ATM layers.  It's a matter of how quickly
that model can be standardized and generally accepted.

Regarding your comment about RFC 1888, yes I was following the
format described in it for embedding IPv6 addresses in ATM NSAP
addresses.  However, I do have a question/concern regarding the
proposed encapsulation.  It uses a new AFI (35) and I don't think
that is currently one of the approved ATM NSAP formats by the
ATM Forum, so there is some concern that this could potentially
lead to some operational problems.  The original Internet Draft
version of this subject used the normal AFI of 47 with an ICD
of 0090, which definitely would not be a problem for ATM use.
What was the rationale for changing this to use a new AFI?

> > >I was originally
> > >planning to use a geographic based scheme, 
> 
> There is no defined IPv6 geographic scheme.

I know.  :-(

That's definitely a major stumbling block.  If it came down to that,
I was even considering submitting a proposal for an IPv6 geographic
scheme.  However, this may not be necessary, as the basic goal may
be readily achievable via the new aggregator based addressing format.

>   Brian Carpenter

						-Bill