Re: Reachability confirmation issue for ISATAP routers (plus solution)

Hi Fred,

Sorry for the slow reply and thank you for summarizing the problem for 
everyone.

Fred L. Templin wrote:

>
>  2. When a node affiliates with multiple routers, upper-layer hints of
>     forward progress MUST NOT be used for reachability confirmation.
>     Instead, the node MUST actively probe neighboring routers using
>     unicast Neighbor Solicitation messages as in the second paragraph
>     of RFC2461

I don't understand how this is a solution.  Requiring this probing will 
seriously limit the scalability of ISATAP.  Given the architecture for 
ISATAP, NS/NA messages will need to be sent unicast between ISATAP hosts 
and routers.  What this means is that each ISATAP host will be sending 
an NS message every 30 seconds or so (depending on the host 
configuration, but 30 seconds is the default timer for ND).  The ISATAP 
router would need to reply to all of these messages, since there is no 
way for hosts to passively listen for ND messages sent to 
ipv6_all_nodes.  This would create a packet storm of ND messages on a 
semi-large network deploying ISATAP.  Requiring (or even making this 
mechanism a SHOULD) is a really bad idea.  At best it should be a MAY 
with strong wording suggesting the scalability issues I mentioned above.  

>
> Note that in case 2), ONLY those routers that are actively carrying 
> outgoing
> traffic are probed. There is no need to probe routers that carry only 
> return
> traffic, since the forward direction is all that is needed.


I don't understand what you mean by "routers actively carrying outgoing 
traffic"?  Is it possible that you are refering to only those routers 
that an ISATAP host has affiliated with and has defined a 'default 
route'?  It seems you are talking about a scenario (packets going out 
router B from A->D and returning on C from D->A) were the usage of the 
PRL is compounded.  I want to understand how router 'C' might not fall 
into your "ONLY" statement above.

thanks,
-Jason

>
>
> Comments?
>
> Fred Templin
> ftemplin-LXTkK8GSST62oZ/[email protected]
>
>
>
>