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