Re: ND (NUD) on ISATAP links

Jason,

It would be helpful if you could phrase your concerns with reference
to the 'isatap-05' draft and my accompanying document entitled:

  "Proposed Solutions for ISATAP Operational Issues"
  http://www.ietf.org/internet-drafts/draft-templin-isatap-issues-00.txt

Thanks,

Fred
[email protected]

Jason Goldschmidt wrote:
 > 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
 >>
 >
 >
 >
 >