Subject: RE: (ngtrans) ND (NUD) on ISATAP links

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Mon, 14 Oct 2002 09:28:22 +0200

Hi Fred

Thanks for initiating the discussion.
I am happy with the outcome so far.

Karen
> 
> Karen,
> 
> It sounds like you are satisfied for the most part by the responses?
> Pending further discussion with the ISATAP co-authors, we will take
> this under consideration for the next ISATAP draft version.
> 
> Fred
> [email-masked]
> 
> Karen E Nielsen (TED) wrote:
> >>Consider a behavior of an ISATAP host that connects to multiple
> >>ISATAP router and is attempting to establish a connection
> >>to an IPv6 native address.
> >>
> >>I can see NUD being performed to the ISATAP router and
> >>if NUD proves the router unreachable (IPv6 address of
> >>the router is not reachable), another router may be tried.
> >>
> >>This is the case where I see NUD being usefull in the ISATAP
> >>environment.  You are right that it is not very usefull between
> >>2 ISATAP hosts.
> >>
> >>-vlad
> >>
> >>
> > 
> > I agree that this works. 
> > 
> > If the prime object by requirering NUD on ISATAP links is to 
> > require ISATAP host to perform NUD on their default ISATAP router. 
> > Then this should be clarified in the draft, I think.
> > 
> > (Another way to obtain reachability 
> > confirmation in this particular case 
> > would be for the host to
> > perform the RS/RA exchange with its default 
> > router frequently enough. 
> > But the recommended 15 min's interval in
> > between RS/RA exchanges would 
> > then of course
> > probably not suffice)
> > 
> > Karen
> 
> 
>

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 17 Oct 2002 14:55:26 -0700

Hi Jason,

 > Can you please explain the benefits of having an ISATAP host connect to
 > multiple ISATAP routers?  If the goal is for redundancy, this might be a
 > hard goal to achieve if the above problem can not be solved.

At present, I see no benefit for an ISATAP node to affiliate with
more than one ISATAP router. If any such benefits exist, I am sure
they will be identified by the design team studies. However, I think
it perfectly reasonable for a host to know about multiple *candidate*
ISATAP routers; even if it only affiliates with one at a time. (Sort
of like "Candidate Access Router discovery" in the Seamoby group).

Please check my recent submission entitled "Proposed Solutions for
ISATAP Operational Issues" under "Operational issue #5". You need to
cross reference this document against the isatap-05 document, which
you may need to pull from my webserver *again* if you are not seeing
a proper matchup with the solutions document. (I made a mistake
in the original posting and had to post a new version.)

Fred

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 17 Oct 2002 15:12:55 -0700

Fred L. Templin wrote:
 > ISATAP Operational Issues"

P.S. I am hoping that this document will serve as a suitable framework
      for discussion of ISATAP issues, as stated in the introduction.

---

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Sun, 20 Oct 2002 13:09:21 +0200

Hi All,

> 
> The scalability problem you mention only happens when there are
> very few routers serving a lot of hosts.  In that case, a 
> particular router
> is more likely to be picked as a next hop and NUD will be run 
> after the
> AdvReachableTime has expired. The consuption of resources on 
> that ISATAP 
> router will roughly equivalent to a normal IPv6 router in a similar 
> configuration (+ the extra is a tunnel overhead) so I don't 
> see a large 
> problem with scalability.
> 
> 

As I understand it, there are two sides to this question.

In the above, the resources that you speak about 
are the resources needed at a particular ISATAP
router in order to _participate_ in NUD
performed by its ISATAP host (responding to NS's).

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 ?

(As is (static address resolution) "ISATAP" NUD does not work on routers)

Karen

---

From: "Karen E Nielsen (TED)" <[email-masked]>
Date: Mon, 21 Oct 2002 09:58:11 +0200

Hi Jason,

Thanks for the comments.

> 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.

> 
> > 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

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 21 Oct 2002 18:02:45 -0700

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-masked]

Jason Goldschmidt wrote:
 > On Mon, 21 Oct 2002, Karen E Nielsen (TED) wrote:
 >
 >
 > Hi Karen,
 >
 >
 >>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
 >
 >
 >