Subject: Re: I-D Action: draft-ietf-6man-resilient-rs-02.txt

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jan 2014 11:46:29 -0800

On Mon, Oct 21, 2013 at 4:38 PM, <[email-masked]> wrote:

>    When an interface on a host is initialized, the host transmits Router
>    Solicitations in order to minimize the amount of time it needs to
>    wait until the next unsolicited multicast Router Advertisement is
>    received.  In certain scenarios, these router solicitations
>    transmitted by the host might be lost.  This document specifies a
>    mechanism for hosts to cope with the loss of the initial Router
>    Solicitations.  Furthermore, on some links, unsolicited multicast
>    Router Advertisements are never sent and the mechanism in this
>    document is intended to work even in such scenarios.
>

Authors,

One comment here.

If the intent is that we should be able to run networks that do not send
periodic RAs at all, then this document will need to require that hosts
send router solicitations when their RAs (or whatever is in the RA
contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about
to expire - otherwise the hosts will lose connectivity.

This may be difficult to specify correctly. Specifically, it may be hard to
distinguish something that is being deprecated by the network (e.g., an RA
whose lifetime is counting down because it comes from a PD) from an RA that
is about to expire.

If the intent is not that we should be able to run networks without
periodic RAs, then at least the text in 2b needs to change.

Cheers,
Lorenzo

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jan 2014 11:55:13 -0800

[Resending with hopefully correct author mailing list]

On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti <[email-masked]>wrote:

> This may be difficult to specify correctly. Specifically, it may be hard
> to distinguish something that is being deprecated by the network (e.g., an
> RA whose lifetime is counting down because it comes from a PD) from an RA
> that is about to expire.
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Jan 2014 12:05:39 -0800

On Jan 22, 2014, at 11:55 AM 1/22/14, Lorenzo Colitti <[email-masked]> wrote:

> On Wed, Jan 22, 2014 at 11:46 AM, Lorenzo Colitti <[email-masked]> wrote:
> If the intent is that we should be able to run networks that do not send periodic RAs at all, then this document will need to require that hosts send router solicitations when their RAs (or whatever is in the RA contents, including lifetimes of PIOs, RIOs, RDNSS options, etc.) are about to expire - otherwise the hosts will lose connectivity.

I think it's worse than that.

A host on a multicast-capable link on which "unsolicited multicast Router Advertisements are never sent" will have to use the same transmission behavior as a host on a non-multicast-capable link, so that the host can learn of changes in the link prefixes in a timely fashion.

Furthermore, a host on a multicast-capable link won't know if multicast RAs are being sent on the link, so all hosts will have to send periodic RSs.

- Ralph

> 
> This may be difficult to specify correctly. Specifically, it may be hard to distinguish something that is being deprecated by the network (e.g., an RA whose lifetime is counting down because it comes from a PD) from an RA that is about to expire.
> 
> If the intent is not that we should be able to run networks without periodic RAs, then at least the text in 2b needs to change.
> 
> Cheers,
> Lorenzo
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jan 2014 21:15:26 +0100

> Furthermore, a host on a multicast-capable link won't know if multicast RAs are being sent on the link, so all hosts will have to send periodic RSs.

for periodic RAs Router Lifetime /  RtrAdvInterval >= 3 to ensure that the mechanism works even when a couple of multicast messages are lost.
if it is specified that the periodic RS is sent only after 2/3s of the router lifetime has passed, then either the host would have received the multicast advertisement, and dropped sending the periodic RS, or it lost the multicast messages, and would be best off sending the RS anyway, or it was on a link-type that didn't send periodic RAs.

cheers,
Ole

---

From: Ralph Droms <[email-masked]>
Date: Wed, 22 Jan 2014 12:19:48 -0800

> for periodic RAs Router Lifetime /  RtrAdvInterval >= 3 to ensure that the mechanism works even when a couple of multicast messages are lost.

Agreed.

> if it is specified that the periodic RS is sent only after 2/3s of the router lifetime has passed, then either the host would have received the multicast advertisement, and dropped sending the peri…

OK ... but the host will not learn about new prefixes assigned to the link in a timely fashion, which is (I infer) the motivation for this text:

   On non-multicast links, the hosts following this specification MUST
   continue retransmitting the RSs even after an RA that results in a
   default route is received.

- Ralph

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jan 2014 21:27:32 +0100

Ralph,

[...]

>   default route is received.

I'm not sure that 3600 seconds is timely fashion. ;-)
I'm not quite sure why the reference to non-multicast links is there.
(and I'm not sure we need to talk about it, if the only example is ISATAP).
ND doesn't really run over non-multicast links. I can recommend RFC2022. ;-)

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jan 2014 13:54:27 -0800

> Furthermore, a host on a multicast-capable link won't know if multicast RAs are being sent on the link, so all hosts will have to send periodic RSs.

Even if you jump to a period RS from every host approach, there would 
still be operational questions on what timer to use, and whether there 
is a way for the operator to quickly introduce a new prefix (and retire 
an old prefix).

With multicast RAs the operator can change the list of prefixes (to 
handle some problem) quite quickly. To accomplish the same thing without 
the multicast RA option would imply either
  - frequent periodic RSs from all the hosts, or
  - robustly tracking the set of hosts in the routers so that unicast 
RAs can be used for such changes.

Regards,
    Erik

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jan 2014 23:00:34 +0100

Erik,

> Even if you jump to a period RS from every host approach, there would still be operational questions on what timer to use, and whether there is a way for the operator to quickly introduce a new prefix (and retire an old prefix).
> 
> With multicast RAs the operator can change the list of prefixes (to handle some problem) quite quickly. To accomplish the same thing without the multicast RA option would imply either
> - robustly tracking the set of hosts in the routers so that unicast RAs can be used for such changes.

I don't think this document should make any reference to links that does not send unsolicited RAs.
that doesn't mean it cannot say how router discovery can work more robustly.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 22 Jan 2014 23:18:34 +0100

Erik,

> Are you speaking as a co-chair or as a WG contributor?
> I don't know whether this is your gauge of WG consensus or personal opinion.

as a working group contributor.
there clearly isn't any consensus to gauge, given that the issue identified as brand new.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 22 Jan 2014 14:53:57 -0800

> that doesn't mean it cannot say how router discovery can work more

Is it reasonable to say that a host that knows that RA-learned connectivity
parameters (e.g., prefixes, default router, DNS servers) will expire
shortly MAY send an RS in an effort to refresh those connectivity
parameters before they expire and cause disruption?

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2014 09:48:08 -0800

> This may be difficult to specify correctly. Specifically, it may be hard to distinguish something that is being deprecated by the network (e.g., an RA whose lifetime is counting down because it com…

Might not be necessary to differentiate.  Regardless of why the prefix lifetime expired and whether the host has configured other , the host will likely want to send periodic RSs in case a new prefix becomes available and "unsolicited multicast Router Advertisements are never sent" implies no RA to announce new prefixes.

- Ralph

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 23 Jan 2014 10:52:33 -0800

On Thu, Jan 23, 2014 at 9:48 AM, Ralph Droms <[email-masked]> wrote:

> Might not be necessary to differentiate.  Regardless of why the prefix
> lifetime expired and whether the host has configured other , the host will
> likely want to send periodic RSs in case a new prefix becomes available and
> "unsolicited multicast Router Advertisements are never sent" implies no RA
> to announce new prefixes.
>

That's true, but then you get into Erik's concern that whenever a host sees
that $SOMETHING is about to expire then it sends out an RS with exponential
backoff (until what? until it gets an RA - any RA, from anyone?).

The concern is that basically ends up with hosts sending RSes all the time
- in other words, you implement dynamic reconfiguration via polling. This
is not necessarily a good use of hosts' CPU and battery resources.

I do think that nodes should be free to send RSes if they so choose, and I
think we should say that a host MAY do so in this draft, but I don't think
we should attempt to design an architecture that depends on polling.

Any objection to saying that hosts MAY send RSes when they want to refresh
information (e.g., when it's about to expire)?

---

From: Ralph Droms <[email-masked]>
Date: Wed, 29 Jan 2014 13:24:15 -0500

On Jan 23, 2014, at 1:52 PM 1/23/14, Lorenzo Colitti <[email-masked]> wrote:

> That's true, but then you get into Erik's concern that whenever a host sees that $SOMETHING is about to expire then it sends out an RS with exponential backoff (until what? until it gets an RA - any RA, from anyone?).
> 
> The concern is that basically ends up with hosts sending RSes all the time - in other words, you implement dynamic reconfiguration via polling. This is not necessarily a good use of hosts' CPU and battery resources.

You and I are pretty much in agreement here.  I'm not trying to argue in favor of sending RSes all the time.  I'm just making the observation that the basic assumptions lead to the use of periodic RSes.  I don't see that solution as an improvement over periodic RAs.

- Raph

> 
> I do think that nodes should be free to send RSes if they so choose, and I think we should say that a host MAY do so in this draft, but I don't think we should attempt to design an architecture that depends on polling.
> 
> Any objection to saying that hosts MAY send RSes when they want to refresh information (e.g., when it's about to expire)?

---

From: Erik Kline <[email-masked]>
Date: Wed, 29 Jan 2014 11:34:42 -0800

> A host on a multicast-capable link on which "unsolicited multicast Router Advertisements are never sent" will have to use the same transmission behavior as a host on a non-multicast-capable link, s…

Not necessarily.

Consider the situation in a which a router responds to multicast RSs
with unicast RAs.  The host may in fact continue to receive unicast
RAs periodically.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 29 Jan 2014 22:22:49 -0800

Erik,

In such an approach when would the router stop unicasting RAs to a 
particular address? Forever? Until NUD fails? What is the host was gone 
for 30 seconds without the host noticing and as a result the router saw 
a NUD failure.

Without clear details one can't say 1) whether this will work and 2) 
weather it would save any resources.

Note (in case it isn't obvious) that a router can respond to a RS with a 
unicast RA - that is already allowed by 4861 and its predecessors.

    Erik

---

From: Erik Kline <[email-masked]>
Date: Wed, 29 Jan 2014 23:41:25 -0800

On Jan 29, 2014, at 10:22 PM, Erik Nordmark <[email-masked]> wrote:

> In such an approach when would the router stop unicasting RAs to a particular address? Forever? Until NUD fails? What is the host was gone for 30 seconds without the host noticing and as a result the router saw a NUD failure.

I like your “until the router detects a NUD failure for the host” notion, I think.  In that case, I think the host will either:

   [1]  enter into NUD detection from its perspective because communications are failing (no replies to packets sent), or

   [2]  it had to packets to send so didn’t notice anything, and then the RA timers get “low” and the host enters into the proposed “retry RSes (probably requiring multicast)” behaviour that launched this thread.

I do agree that if a network is going to rely on RSes before it sends a periodic RA (say, because the network is one of these split horizon things) some guidelines for the RA-sending side are probably in order, but I’m not yet convinced it’s terribly complicated.

…but maybe I just haven’t thought about it enough.

-Erik (the lesser)