[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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@iprg.nokia.com