RE: ND (NUD) on ISATAP links (fwd)

One more.


---------- Forwarded message ----------
Date: Mon, 21 Oct 2002 09:41:14 -0700 (PDT)
From: Jason Goldschmidt <[email protected]>
To: "Karen E Nielsen (TED)" <[email protected]>
Cc: 'Vladislav Yasevich' <[email protected]>,
     "'[email protected]'" <[email protected]>, [email protected],
     'Fred L. Templin' <[email protected]>
Subject: RE: (ngtrans) ND (NUD) on ISATAP links

On Mon, 21 Oct 2002, Karen E Nielsen (TED) wrote:


Hi Karen,

> > The scalability problem is rooted in the fact that each ISATAP
> > host will have to send a unicast NUD to the router (as opposed to
> > multi/broadcast in the case of a "normal IPv6 router).  Thus 
> > ISATAP hosts   
> > can not passively listen for NA's, they must initiate a 
> > unicast NUD every
> > AdvReachableTime.  As opposed to the "normal IPv6 router" 
> > case, more NS's
> > would actually be sent and processed by the ISATAP router.
> > 
> 
> Agreed. 
> 
> In order to limit the NS/NA signalling then one could recommend ISATAP
> routers to specify an AdvReachableTime greater than REACHABLE_TIME (30
> msec) e.g. something in line with the 15 mins suggested for
> MinRouterSolicitInterval.

Though doing this makes the implementation of NUD kind of pointless.  If
the (Actual)RouterSolicitInterval (that is the interval at which RS/RA
polling will be performed and is based on the router lifetime as compared
to MinRouterSolicitInterval) is that 15 min. suggested minimum, the NUD
would provide no additional information regarding reachability.  It is
only when the (Actual)RouterSolicitInterval is greater then the 15 min
minimum, that this might be useful.  Then again, I am not sure how the
default for AdvReachableTime was established, but I imagine it had
something to do with 30 seconds not being all that long of a time to go
without verifying reachability.  15 minutes would be an eternity.  No
one is going to wait that long (even 5 minutes) to determine if a router
went poof (crashed).  For ISATAP, the router doesn't even have to crash,
it could just be scheduled down time.  I imagine if something like this
was to happen on a production network there would be some dance with the
DNS entry for isatap.domain.com (assuming this network is using DNS to
obtain the PRL).

Though this brings up a question for the authors.  What should an ISATAP
host do if after ResolveInterval expires a new PRL is obtained and a
particular router (that is currently being used by the ISATAP host) had
been removed from the PRL.  What should the host do?  Deprecate those
addresses?  Something more drastic?

I do not believe a solution for, efficiently, implementing NUD within the
ISATAP architecture can be achieved.  The ISATAP protocol could certainly
be made a whole lot simpler if the PRL was limited to a size of only one.
Or rather, the number of routers being used by a particular ISATAP link
was limited to only one.  (possibly a mechanism for working through a
populated PRL to find only one router could be created, otherwise the PRL
should be of length 1)  Yes this would limit ISATAP as a protocol, but WRT
actual useful features, I believe only complexity would be limited.  If
redundancy is the goal of having a PRL greater then 1, I think my
arguments regarding NUD show that true redundancy would be hard to
achieve without costing scalability.  Multihoming was also mentioned, is
this a strong requirement for networks that would be using ISATAP?  I am
not sure.  Yes networks might be multihomed, but does ISATAP need to
support this directly or is this just a deployment issue?

Transition mechanisms need to be simple and not perfect, otherwise people
will use them forever and never go native.  The latest ISATAP draft (5)
suggests that the authors are trying to make ISATAP perfect.  This is a
really bad direction for the protocol to go.

thanks,

-Jason


> > 
> > > Another concern is the scalability issues in relation to 
> > the resources
> > > needed at the ISATAP router in order to _perform_ NUD on its ISATAP
> > > neighbours - Do we agree that this has been ruled out - i.e. that
> > > performing NUD only is going to be demanded of ISATAP hosts 
> > - or do we
> > > want a LAN-like IPv6 functionality on ISATAP routers ?
> > 
> > It seems that if NUD is to be implemented at all, the only 
> > place it could
> > happen is the at the host.
> > 
> 
> Agreed. The keyword here seems to be "if NUD is to be implemented at all".
> 
> Karen
>