[Erik]"While it might not make much difference in connectivity" Connectivity is the benefit of section 3.6.
[Erik]"What are the claimed benefits of no longer doing longest-match routing as outlined in example 3.6?" Failover is the benefit of choosing the next longest matching route that is reachable when the longest matching routes are unreachable. As for determinism - it's one thing to say that the admin wants to route packets to P1::/48 through R1/R2 and not through R3/R4 and packets sent to R3/R4 destined to P1::/48 are dropped. It's another thing to say that he doesn't expect packets to P1::/48 at R3/R4 altogether. As I understood you are saying that this second non-deterministic behavior is bad. But how does this operationally affect an admin. Is it the processing load on R3/R4 to discard packets? A determined host can always send packets destined to P1::/48 to R3/R4. On the other hand 4191-3.6 allows an admin to route packets based on an prefix based policy in a network with infrequent packet losses while maintaining connectivity when there is an occasional outage - without altering the longest-match in steady state. And the admin has the option to prevent routing through R3/R4 anyway. Simha -----Original Message----- From: Erik Nordmark [mailto:erik.nordm...@sun.com] Sent: Tuesday, December 08, 2009 5:25 AM To: Narasimhan Venkataramaiah Cc: Templin, Fred L; IPv6 Maintenance WG Subject: Re: Question on RFC 4191 inconsistency Narasimhan Venkataramaiah wrote: > I guess adding a default gateway to achieve the scenario below is a > shortcut to cluttering the host with a lot of specific routes that > exclude P1::/48 > > If the admin wants the hosts to route all packets to P1 go via R1 or > R2 for load balancing or optimization - this algorithm should not > break the original intentions in steady state. A few packets getting > routed through R3/R4 shouldn't be a big deal in this case - of course > if the network is super flaky then there is a problem - however this > algorithm will not make a big difference to connectivity in such a > network. While it might not make much difference in connectivity, it makes it harder for the network operator to understand things, because from an operational perspective it doesn't look like the host honors longest-match routing. What are the claimed benefits of no longer doing longest-match routing as outlined in example 3.6? Erik > Any other stricter intention will most likely have some filtering on > R3 and R4 to drop packets destined to P1::/48. In this scenario this > algorithm has not altered the host's connectivity in any way. 1. > Without this algorithm - the preferred routers R1 and R2 are not > reachable. Still the host attempts to resolve these addresses and > potentially drop the packets while they are unreachable. 2. With this > algorithm - when R1 and R2 are unreachable - the host attempts to > send to R3 and R4 - they fail too (assuming filtering on R3 and R4). > The host keeps probing R1 and R2 and when they are reachable the host > switches to R1 / R2. The time to switch may be a little more with the > algorithm. > > The extra work on the admin's (Which is probably done anyway in the > non-loadbalancing scenario to prevent misconfigured hosts from > sending packets destined to P1::/48 to R3 and R4) part is to filter > the packets for P1::/48 on the routers R3 and R4 if they truly want > all packets destined to P1::/48 to go over R1 or R2. > > Simha > > -----Original Message----- From: Templin, Fred L > [mailto:fred.l.temp...@boeing.com] Sent: Monday, December 07, 2009 > 9:09 AM To: Erik Nordmark; Narasimhan Venkataramaiah Cc: IPv6 > Maintenance WG Subject: RE: Question on RFC 4191 inconsistency > > Erik, > >> -----Original Message----- From: ipv6-boun...@ietf.org >> [mailto:ipv6-boun...@ietf.org] On Behalf Of Erik Nordmark Sent: >> Monday, December 07, 2009 1:33 AM To: Narasimhan Venkataramaiah Cc: >> IPv6 Maintenance WG Subject: Re: Question on RFC 4191 inconsistency >> >> >> Narasimhan Venkataramaiah wrote: >>> This behavior is implemented in Vista and Windows 7. >>> >>> Can you explain the concern about unpredictability more? The >>> algorithm reacts to the changes in the >> network - hence there is bound to be unpredictability on the time >> line of when the packets start getting routed to a different next >> hop - but given a history of data packets it isn't all that >> unpredictable. Is the concern about the non-standard mechanism used >> to detect unreachability? >> >> If a host is connect to more than two routers, for instance two >> pairs of routers, with each pair routing to very different parts of >> the universe, then the admin on the routers can no longer control >> where packets go. >> >> Say R1 and R2 advertise P1::/48 with high preference, and R3 and R4 >> advertise P2::/48 with high preference. All four routers also are >> default routers. > > The presence of default routes means that the host should accept > packets from all four routers equally, i.e., and not only accept the > ones from R1 and R2 while dropping those from R3 and R4, right? > >> Here the admin wants packets to P1 to only go via R1 or R2. >> >> However, should there be some short-term flakyness for the >> connectivity between the host and R1 and R2 (just some wireless >> packet drops over a 40 second period is sufficient), then NUD could >> decide that R1 and R2 are unreachable. > > But if R1 and R2 are both truly unreachable, shouldn't the host be > allowed to fail over to R3 and R4, which are legitimate forwarders of > packets that the host accepts? > > Fred fred.l.temp...@boeing.com > >> If the implementation follows the example in section 3.6 that would >> cause packets to P1 to be routed to R3 or R4, which would violate >> the intent of the router admin in this example. And the router >> admin has no influence when a host might declare a neighbor >> unreachable; with base RFC 4861 there is no need for such control >> since the hosts behave in a predictable way by always picking among >> the equal default routes. >> >> Thus having NUD affect the choice among equal routes (same prefix >> length) is one thing, but the example in 3.6 looks like a bad idea >> to me. >> >> Erik >> >>> Thanks Simha >>> >>> -----Original Message----- From: ipv6-boun...@ietf.org >>> [mailto:ipv6-boun...@ietf.org] On Behalf Of Erik Nordmark Sent: >>> Sunday, December 06, 2009 9:23 AM To: IPv6 Maintenance WG >>> Subject: Question on RFC 4191 inconsistency >>> >>> >>> The default router preferences RFC seems to be internally >>> inconsistent on the scope of the "non-reachable router" >>> implications. >>> >>> Section 3.2 contains: using route preference values as a >>> tie-breaker if multiple matching routes have the same prefix >>> length. If the best route points to a non-reachable router, this >>> router is remembered for the algorithm described in Section 3.5 >>> below, and the next best route is consulted. >>> >>> thus it talks about multiple matching routes *with the same >>> prefix length*. Nothing in section 3.5 contradicts this. >>> >>> Yet the example in section 3.6 talks about falling back to the >>> default route (or any route with a shorter match) when all the >>> longest match routes lead to unreachable routers. >>> >>> It is quite odd that the example is the only source of this novel >>> behavior. >>> >>> I'm concerned that going to shorter matching routes isn't only >>> complex to implement, makes the protocol operationally >>> unpredictable (who knows how quickly a host might decide a router >>> is unreachable when there is non-zero packet loss), but also >>> charters completely new territory in terms on longest-match >>> routing. >>> >>> Have this example behavior in section 3.6 been implemented? Do we >>> have any operational experience with it? >>> >>> Erik >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list ipv6@ietf.org >>> Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
