Subject: Re: draft-ietf-6man-resilient-rs update

From: Ole Troan <[email-masked]>
Date: Mon, 4 Aug 2014 12:20:17 +0200

Dmitry,

>>> I do agree with that. the specific concern with the MAY, is that we'll end up with inconsistent behaviour on the link. I'd much rather that we specified behaviour in detail.
> 
> Ok, can you elaborate to what level of details you'd expect the behavior to be specified? Is statement on rate limiting would be sufficient, or you think the description of the algo along the lines of DHCPv6 retransmissions is needed (or the latter could be referenced)?

Erik Nordmark has raised a number of questions that needs to be answered if we were to specify this:
I think you'll find them here:
https://mailarchive.ietf.org/arch/search/?q=draft-ietf-6man-resilient-rs+and+nordmark

if we were to go down the route of solving 2 and 3, we'd need to see text.

cheers,
Ole

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Aug 2014 16:41:04 -0700

[Delay in responding due to travel and vacation]

On 7/25/14, 5:21 PM, Dmitry Anipko wrote:
> Let's separate discussions on the substance and on what exact language we put in the draft.
>
> Substance wise - IMO, the change tries to reduce existing fragility of RD in some situations. We had very real real-world support cases with one of the top mobile operators in the US, where the network was not sending new RAs before expiring the info in the initial one. Yes, this was  a misconfiguration / bug on the network side. Yes, this is where it was eventually fixed, and yes perhaps the support teams should not have taken as much time to figure it out. But the end-users don't care about that part, and they would be better off in the meantime if the protocol had more resiliency against misconfiguration or packet loss. Speaking for myself only, this is the scenario I'm concerned about. I'm sure there are others who know the "no multicast RAs, period" scenario better than I do, and they can speak for that.

Dmitry,
I don't understand how we can make the protocol specification more 
robust against the above type of misconfiguration - at least not without 
resulting in a lot more chatty protocol.

For instance, suppose we say that hosts should send unicast a RS every 
10 seconds. That would be quite chatty and would still result in the 
same failures if the operator accidentally configures the router (and/or 
prefix) lifetime to be 5 seconds.
And having the hosts look at the remaining lifetimes and decide to 
unicast (or multicast) RSes closer and closer together as the 
lifetime(s) get closer to expiry might result in an explosion of RS 
messages during a network outage.

    Erik

>
> So I think it would be good to first understand, leaving specific RFC language aside, whether there is consensus to improve RD reliability when the host sees that previously received information has expired / about to expire. My impression from the discussion in London was that there was such consensus - but perhaps I misunderstood. Letting the host do additional rate-limited transmissions to solve that, to me looks like a simple and reasonable approach. If you agree with that, then what's the specific concern on putting that as MAY?
>
> I do disagree with the viewpoint, that because if ND use of multicast is inefficient, let's not make any improvements to ND until multicast issue is solved. Yes, the multicast-related issues in general do need to be addressed over long term. But addressing them will take time, and there are issues today which end-users are hitting, for which incremental limited fixes within existing framework are possible and reasonable.
>
>>> today, links without periodic RAs are not supported.
> Since this is a statement about today, it equally applies (or not applies), to the option 2 you suggested and the option I suggested, so it's not a differentiator. Furthermore, it basically is equivalent to option 1, which makes it not an independent argument, but re-iterating option 1, and can't be used as a differentiator there either.
>
> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]]
> Sent: Thursday, July 24, 2014 8:25 PM
> To: Dmitry Anipko
> Cc: Suresh Krishnan; <[email-masked]>; [email-masked]; 6man WG
> Subject: Re: draft-ietf-6man-resilient-rs update
>
>>>> wouldn't those hosts initially do router discovery, then not ever send RS again, and would be left without a default router when the router lifetime expired?
>> Assuming there are no other events, such as media state change - correct, and that's the behavior they get today. As I understand it, this MAY is about a specific behavior improvement, compared to the today state, which a vendor may choose to implement.
> today, links without periodic RAs are not supported.
>
> cheers,
> Ole
>
>> -----Original Message-----
>> From: Ole Troan [mailto:[email-masked]]
>> Sent: Wednesday, July 23, 2014 8:01 PM
>> To: Dmitry Anipko
>> Cc: Suresh Krishnan; <[email-masked]>;
>> [email-masked]; 6man WG
>> Subject: Re: draft-ietf-6man-resilient-rs update
>>
>> Dmitry,
>>
>>>>> what would happen with the hosts that didn't implement the feature on links w/o periodic multicast RAs?
>>> It would not get this particular improvement in behavior compared to the pre-draft state. But since the answer seems to be trivial, I'm not sure I understood the question correctly?
>> wouldn't those hosts initially do router discovery, then not ever send RS again, and would be left without a default router when the router lifetime expired?
>>
>> cheers,
>> Ole
>>
>>
>>>
>>> -----Original Message-----
>>> From: Ole Troan [mailto:[email-masked]]
>>> Sent: Tuesday, July 22, 2014 7:15 PM
>>> To: Dmitry Anipko
>>> Cc: Suresh Krishnan; <[email-masked]>;
>>> [email-masked]; 6man WG
>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>
>>> Dmitry,
>>>
>>>> Given the definition of MAY in RFC 2119, why is the wording, which is currently in the text, not an option?
>>>>
>>>> <quote>
>>>> In the
>>>> same vein an implementation which does include a particular option
>>>> MUST be prepared to interoperate with another implementation which
>>>> does not include the option (except, of course, for the feature the
>>>> option provides.) </quote>
>>>>
>>>> Where "the feature" would be e.g. "supporting links w/o periodic multicast RAs"?
>>> what would happen with the hosts that didn't implement the feature on links w/o periodic multicast RAs?
>>>
>>> cheers,
>>> Ole
>>>
>>>> -----Original Message-----
>>>> From: Ole Troan [mailto:[email-masked]]
>>>> Sent: Tuesday, July 22, 2014 2:10 PM
>>>> To: Suresh Krishnan
>>>> Cc: Dmitry Anipko; <[email-masked]>;
>>>> [email-masked]; 6man WG
>>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>>
>>>> Suresh, et al,
>>>>
>>>> to pick up this after my holiday.
>>>>
>>>>>>> My impression from the discussion in London that the consensus was closer to (2) than (1) - that on such links the hosts should be allowed to restart transmissions in a reasonable / rate-limited manner, when connectivity parameters expire. And that we should add MAY text for that.
>>>>>> that's also fine with me. if there was a text proposal it would most likely be easier for the working group to come to a decision.
>>>>>> is that something the authors can take on?
>>>>> In my view, the text in the draft already reflects something akin to what Dmitry was talking about (but not exactly option 2 from your original mail on this thread). This is the relevant text from the draft.
>>>>> Hosts MAY continue retransmitting the RSs even after router discovery is successful.  If the host continues to retransmit RSs, it is RECOMMENDED that such retransmissions be rate-limited to one every MRT.
>>>> the current text states: hosts SHOULD stop, but MAY continue.
>>>> on a link where there are no periodic multicast RA, then all the hosts that doesn't implement the MAY will fail after the initial Router lifetime seconds.
>>>>
>>>> to me it appears we have two options.
>>>> 1) only solve the initial connection case.
>>>> remove any mention of links without periodic RAs (remove the last sentence of the abstract, and bullet 1b.).
>>>>   possibly remove the MAY in the "SHOULD stop, but MAY continue"
>>>>   advance the document to the IESG
>>>> 2) take the document back to the WG and solve the problems that Erik outlined in his mail.
>>>>
>>>> cheers,
>>>> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Aug 2014 17:01:49 -0700

On 7/29/14, 1:48 AM, Ole Troan wrote:
> I think the argument made is that the issues are somewhat tangled together.
>
> if you made RD more resilient against packet loss, then you may end up solving the "no periodic multicast" case as a side effect.
>
> so for the question of what to do with the resilient RS draft. there seems to be at least three problems:
> 1) the initial connection problem
> 2) not robust enough in case of packet drop / what to do when (last) router lifetime expires / last address expires

I thought Dmitry's case was different - not sufficiently robust against 
misconfiguration.
That sounds more like and implementation and operational issue and not a 
protocol issue.

The default values in RFC 4861 makes the periodic multicast RAs robust 
against packet loss by having the router lifetime be 3x times the 
advertisement interval. And on lossy links the routers can be configured 
with a higher ratio.

When the periodic multicast works there isn't an issue when the last 
router lifetime or address expires; that would only happen when either 
the connectivity was completely lost (i.e. packet loss large relative to 
the above chosen ratio), or the administrator intended to expire a 
router and/or a prefix.
Doing something extra in that case seems counterproductive.
Thus I don't think there is a #2 problem.

> 3) links without periodic RAs

I think the line should include "multicast".

There are links where periodic multicast RAs can be used, but are quite 
resource intensive. Not only the wifi links we've talked about but also 
for cellular networks where paging etc considerations come into play. 
(E.g.,

  draft-garneij-6man-nd-m2m-issues-00

)

> solving 2 may inadvertently solve 3.
>
> before posing the questions to the working group, let's agree on the questions.
> can we ask the working group to choose between the following two options:
> i) only solve problem 1 in the resilient-rs draft. which implies remove text about no periodic RAs
> ii) solve both problem 1 and 2. which implies taking the document back to the working group

While I don't think the problem 2 exists in any interesting and useful 
form, I think the choices for the WG are as you specified.
FWIW I'd be willing to work on the problem, whether the WG wants to hold 
back resilent-rs or put this in a separate document.

Regards,
    Erik

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 15 Aug 2014 00:13:21 +0000

Hi Erik,

After some offline discussion, here is the adjustment of the text we'd like to propose. Please let me know if this sufficiently mitigates your concern.

Replace the first paragraph of the section 2.1 of http://tools.ietf.org/id/draft-ietf-6man-resilient-rs-03.txt  with the following:

<text>
On multicast-capable links, the hosts following this specification 
SHOULD stop retransmitting the RSs when Router Discovery is successful 
(i.e. an RA with a non-zero Router Lifetime that results in a default 
route is received).

When and if all of the following conditions are met:
1. The host received an RA with non-zero Router Lifetime since the 
last attachment of the interface to the link, and has not received 
later an RA with zero Router Lifetime from the same router.
2. Less than N seconds (where N is randomly chosen by the host at the 
interface initialization time to be IRT < N <= 2*IRT) remain till the 
expiration of all of the known default routers on the interface.

the host MAY re-start sending of the RSs following the Proposed 
algorithm, described in the section 2.
</text>

-Dmitry

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Thursday, August 14, 2014 4:41 PM
To: Dmitry Anipko; Ole Troan
Cc: <[email-masked]>; [email-masked]; 6man WG; Suresh Krishnan
Subject: Re: draft-ietf-6man-resilient-rs update

> Substance wise - IMO, the change tries to reduce existing fragility of RD in some situations. We had very real real-world support cases with one of the top mobile operators in the US, where the net…

Dmitry,
I don't understand how we can make the protocol specification more robust against the above type of misconfiguration - at least not without resulting in a lot more chatty protocol.

For instance, suppose we say that hosts should send unicast a RS every
10 seconds. That would be quite chatty and would still result in the same failures if the operator accidentally configures the router (and/or
prefix) lifetime to be 5 seconds.
And having the hosts look at the remaining lifetimes and decide to unicast (or multicast) RSes closer and closer together as the
lifetime(s) get closer to expiry might result in an explosion of RS messages during a network outage.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Aug 2014 11:15:57 -0700

> expiration of all of the known default routers on the interface.
What is IRT?
> algorithm, described in the section 2.

This ensures that as long as there is no outage there would be no extra 
RS messages.

However, if there is some outage all the hosts are likely to flood the 
network with RS messages at the same time.
(For instance, if L2 is fine but some L3 breakage results in the router 
not getting the RAs out.)

The "at the same time" part would be quite bad in a large network e.g. 
10000 hosts on the link - whether WiFi or cellular.
One could try to address that by adding a random delay, but that is a 
bit hard because the host doesn't know whether there are 10 or 10,000 
hosts on the link.

Furthermore, the algorithm in section 2 is to send multicast RS. That is 
needed if the last router silently died and a replacement router (with a 
different MAC and IPv6 address) has been put in place instead. 10,000 
muticast RS as the same time seems bad.

But if the issue is instead that the link isn't very good at delivering 
the multicast RAs and the router is fine, then a unicast RS would suffice.

But I still don't understand (or I don't agree) with the problem you are 
trying to solve.

Is the problem you want to solve a misconfigured router (which sends 
periodic RAs less frequently than the default router lifetime)?
Is it links where multicast (RAs) are very unreliable, hence the host 
can miss the 3 that should appear before the default router lifetime 
expires?
Routers which get replaced (without VRRP or HSRP) *and* do not send an 
initial set of multicast RAs?

For links with unreliable (or no) multicast RAs there are much more 
robust ways to do this.

    Erik