Re: Request to Publish ISATAP

[Fred Templin <osprey67@yahoo.com>]

Itojun,

Let me first say, it should be clear to all that I am struggling
with process details. But, how can *anyone* be expected to get
things exactly right when the NGTRANS closing has come upon us
so quickly and the closing procedures have been so nebulous?
The new charter seems restrictive to the point of requiring
authors to leap high buildings just to get their documents
recognized - even though some (like ISATAP) have been out in
the public discussion for over *two years* now.

The chairs have asked for transition scenario documents, and
one has been written, presented and revised for ISATAP. I am
certain that ISATAP can provide useful benefit to some of the
other operational areas as well, and additional scenario documents
could be written. But again, how high does an author need to jump
to get on your radar screen?? If this document can't go standards
track right now, let's at least get it through as experimental
so we can prove to the community in due course that further
progression is warranted.

Now to your questions: 

--- itojun@iijlab.net wrote:
> 	(chair hat off)
> 
> 	sorry for doing it in this late stage (from Fred's view),
> 	i see a couple of major technical problem with ISATAP-08 document.
> 
> 	in 5.1, the document proposes a different handling of link-layer
> 	address option in ND from the normal ND.

This is explicitly *allowed* by RFC 2461, section 7.2.2, last paragraph
on P. 59. I won't cut-and-paste the tex for the sake of brevity, but the
normative text that allows what ISATAP is doing is plain for all to see.

>       also in 5.2, the document
> 	proposes special handling of router discovery.  ND and router discovery
> 	have to be link-layer independent, and if we wish to make any changes
> 	to ND/autoconf, we must update RFC2461/2462, in link-layer independent
> 	manner.

Remember; this is an IPv6 over NBMA document. But, in RFC 2461, section 1,
we have the following text:

   However, because ND uses link-layer multicast for some of its
   services, it is possible that on some link types (e.g., NBMA links)
   alternative protocols or mechanisms to implement those services will
   be specified (in the appropriate document covering the operation of
   IP over a particular link type).

Clearly, no updates to RFC2461 are necessary since ISATAP is exactly
such "the appropriate document..." as described above.

> 	in 5.1, paragraph 2, what does "enhanced address resolution" mean?
> 	is it documented in ISATAP document?  if so, where?

This refers to the text exactly one sentence earlier, which says:

   ISATAP hosts SHOULD enhance the static address resolution computation
   with a unicast Neighbor Solicitation(NS)/Neighbor Advertisement(NA)

So, "simple address resolution" = static computation with no neighbor
discovery exchange, and "enhanced address resolution" = static computation
plus a unicast NS/NA exchange. How clear do we need to be?
 
> 	it is proposed that router discovery mechanism (near 5.2, find "PRL"
> 	for Potential Router List) would use DNS for discovering ISATAP router.
> 	it creates circular dependency between link layer (ISATAP) and DNS.
> 	the use of DNS must be dropped from the router discovery mechanism.

Yes, DNS is one alternative for discovering the ISATAP router - but
not the only one. Even so, the sequence a dual-stack node can use
the following bootstrapping procedure:

  - discover IPv4 address; DNS server
  - configure the IPv4 stack
  - wait for a while for native IPv6 RAs to arrive
  - if no native v6 service:
    - discover a domain name for the ISATAP service
    - resolve the name into a list of IPv4 addresses
      by name service lookup (could be DNS, could be
      static file, ec.)

Can you explain to me a scenario in which this would *not* work?

> 	ISATAP router is a choke point wrt scalability of the mechanism
> 	(for instance, link speed of ISATAP router would be the bottleneck for
> 	all of the nodes in an ISATAP-based site).
> 	we might be able to achieve some level of load-balancing using
> 	coordinated advertisement of ISATAP router via PRL announcement,
> 	however, it is not enough.

Talk about unsubsantiated opinions! This statement would have been
like the founding architects saying: "packet switching networks can
incur congestion in some cases, so let's not even bother building them".
Clearly, there is a need for better understanding of ISATAP's scaling
properties - but, that's what experiments are for!

BTW, my belief is that the ISATAP scaling question is a non-issue.
Even if a site administrator felt the need to strategically deploy
equipment for fault tolerance, load balancing, etc. the specification
provides abundat flexibility to support this. It is left to implementors
to create robust products to satisfy the anticipated needs of customers;
the ISATAP specification has no business meddling in implementation
details.  
 
> 	i can't really parse section 7 paragraph 2.  what does it mean?
> >   Appendix B proposes a specification for managing the IEEE OUI
> >   assigned to IANA for EUI-64 interface identifier construction.  This
> >   specification is made freely available to IANA for any purpose they
> >   may find useful.

Let me recommend that you give it 1-2 more re-reads, then skip ahead to
Appendix B. The meaning is there, and the words (while not optimal) seem
adequate to me. If you are still confused, let me assure you this text
has absolutely no operational bearing on the rest of the specification. 
 
> 	(and to re-itereate)
> 	ISATAP does not supersede automatic tunnelling in RFC2893.  automatic
> 	tunnelling does not limit itself to the use within a site (::/96 route
> 	won't be there from RFC2772, but anyways, RFC2893 does not limit the
> 	domain of usage like ISATAP).  there's no equivalent to ISATAP router
> 	in auto tunnel.  ISATAP and automatic tunnelling are different
> 	mechanism, therefore the Plea to AD was technically incorrect.
> 	(mech-v2-01 obsoletes automatic tunnelling for different reason - lack
> 	of implementation/scaling/usage)

See my above comments on process; I'm sure you can sense my frustration
in having been stuck on the outside looking in after all this time of
collaborative contribution to the community.

Fred Templin
osprey67@yahoo.com

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com