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

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Jul 2014 16:19:08 +0200

On 6/20/14, 2:46 PM, Ole Troan wrote:
>> 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?

There wasn't a consensus call from the discussion in London, but my take 
is that what would be needed (in any document which wants to specify how 
to do RS refresh) is a lot more than adding a "MAY" sentence.

We need to avoid a tragedy of the commons - I can make my host 
implementation be more robust by sending relatively frequent RSs but 
that would be harmful to the overall network and hosts' battery if other 
hosts do it as well.

One of the negative interactions is that most (all?) router 
implementations respond to a unicast RS with a multicast RA, hence 
having hosts do RS refresh would result in a lot more multicast RAs in 
deployed networks.
Furthermore, care is needed to avoid ending up with too frequent RSs 
from lots of hosts as lifetime naturally get lower for information that 
is supposed to expire. There is some discussion/suggestions on how to 
handle that in section 8.9 in 
http://www.ietf.org/internet-drafts/draft-chakrabarti-nordmark-6man-efficient-nd-06.txt

I don't know if the WG has consensus to include all of that in the 
resilent-rs. To me it seems like a significant expansion of the scope of 
the document.

Note that the cited section 8.9 isn't sufficient to allow a network to 
operate without multicast RAs. Even if all hosts on a link send RSs to 
refresh information there is still a need for multicast RAs when when 
routers have new or changed information (such as prefix withdrawal or 
prefix addition) which they quickly want to disseminate to hosts.

Thus the claim (or interpretation of the claim) in the abstract in 
resilent-rs that it allows operation on links where there are no 
unsolicited multicast RAs doesn't seem to have any basis in reality. The 
resilience mechanism does work on such links to reliably get an initial 
RA, but does not handle the cases of RA updates.

But if the WG wants to take this document back to the drawing board and 
expand its scope, we can figure out what text that needs to be added.
Or we can do that as part of a separate document -  the efficient ND 
design team has been discussing these issues but there are not any 
drafts yet from that effort.

Regards,
     Erik

>
> cheers,
> Ole
>
>
>> The minutes seem to be consistent with my impression:
>>
>> <quote>
>> Andrew: I agree with both Erik and Lorenzo. We should not explicitly
>>           prohibit hosts from 1.b.
>>
>> Suresh: If we keep 1.b., we would need to address it.
>>
>> Andrew: Don't prohibit it, so that it may be addressed in another
>>           document.
>> ...
>>
>> Dave Thaler: Keep scenario 1.b. Do constraints on rate-limiting. We have
>>           cases where ND varies by a specific ling-layer. Indeed, the mechanisms
>>           in this document comes from one of those documents. I think I'm in
>>           agreement with what I think is the consensus.
>>
>> </quote>
>> ________________________________________
>> From: Ole Troan <[email-masked]>
>> Sent: Thursday, June 19, 2014 5:08 AM
>> To: 6man WG; [email-masked]
>> Cc: <[email-masked]>
>> Subject: draft-ietf-6man-resilient-rs update
>>
>> all,
>>
>> we have had this document in a WGLC for quite a while. there has been one outstanding issue.
>> the document as currently written states:
>>
>> Abstract:
>>    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.
>>
>> Introduction:
>>    b.  Access networks/links that turn off periodic RAs and only send
>>        RAs in response to RSs.  In this case, if the link between the
>>        Access Point (AP) and the host comes up before the link between
>>        the AP and the Controller/Router, the host will never be able to
>>        connect.  This technique of turning off periodic RAs is commonly
>>        used in several wireless LAN and datacenter networks to reduce
>>        the amount of multicast traffic.
>>
>> in the specification part of the document it states:
>>    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).
>>
>> as written a host connected to a link with the properties described in b, would lose its default router after the initial RA lifetime, and would not recover.
>>
>> there are two solutions to this:
>> 1) remove the text in the abstract and introduction implying that this is a solution to links with multicast RA turned off
>> 2) modify the algorithm to restart router solicitations when required
>>
>> after discussing this issue with the authors, there appears to be agreement to we resolve this issue by focusing the document on initial connection to the link only (1).
>>
>> unless this is contentious, the authors will publish an updated revision with these changes, that we'll run a short WGLC on, and then we will advance the document to the IESG.
>>
>> Best regards,
>> Ole
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Jul 2014 17:13:01 +0200

On 6/20/14, 11:56 PM, Suresh Krishnan wrote:
> Hi Ole,
>
> On 06/20/2014 08:46 AM, Ole Troan wrote:
>>
>>> 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.
> 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.

If hosts implement that MAY and they operate on a network with existing 
routers (that multicast the solicited RAs) we will see lots of multicast 
RAs. MRT=3600 seconds, thus as 1200 hosts we will have on average one RS 
every 3 seconds, resulting in a multicast RA every 3 seconds. (Can't be 
more frequent since the multicast RAs are rate limited to 1 per 3 
seconds by 4861.)

Such frequent multicast RAs will not help with battery life, and will 
also use up wifi multicast bandwidth.

Coupling the hosts' use of RS refresh with the routers responding with 
unicast RA would help, but the resilent-rs draft doesn't do that.
Hence that MAY is dangerous.

Regards,
    Erik

> Cheers
> Suresh

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Jul 2014 17:09:33 -0400

Suresh, et al,

to pick up this after my holiday.

> 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

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 23 Jul 2014 01:28:34 +0000

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

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

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Jul 2014 22:14:41 -0400

Dmitry,

> 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

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 23 Jul 2014 18:13:34 +0000

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

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

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Wed, 23 Jul 2014 23:01:19 -0400

Dmitry,

> 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

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 25 Jul 2014 01:06:05 +0000

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

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

cheers,
Ole

> Cc: Suresh Krishnan; <[email-masked]>; 
> [email-masked]; 6man WG
>> option provides.) </quote>
>> 
>> Cc: Dmitry Anipko; <[email-masked]>; 
>> [email-masked]; 6man WG

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Jul 2014 23:24:38 -0400

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

today, links without periodic RAs are not supported.

cheers,
Ole

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 26 Jul 2014 00:21:17 +0000

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.

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

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jul 2014 10:48:31 +0200

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

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.

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

I think the argument made is that the issues are somewhat tangled together. 

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

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
3) links without periodic RAs

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

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Jul 2014 00:14:23 +0900

> ii) solve both problem 1 and 2. which implies taking the document back to

If we pick #1, are we still allowed to clarify that a host MAY send a
router solicitation when it feels it needs to (e.g., when some parameter it
is interested in is about to expire?)

---

From: Ole Troan <[email-masked]>
Date: Tue, 29 Jul 2014 19:26:52 +0200

Lorenzo,

> If we pick #1, are we still allowed to clarify that a host MAY send a router solicitation when it feels it needs to (e.g., when some parameter it is interested in is about to expire?) 

in my opinion, that should be part of solving problem 2. in any case a "SHOULD stop sending periodic RS, but MAY do something else", the MAY is redundant.

cheers,
Ole

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 29 Jul 2014 20:33:28 +0000

Hi Ole,

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

>> I think the argument made is that the issues are somewhat tangled together.

While the issues might be somewhat tangled, it doesn't necessarily follow that the solutions have to be tangled - particularly if the solution to the massive multicast background traffic may not come fast.

>> if you made RD more resilient against packet loss, then you may end up solving the "no periodic multicast" case as a side effect.

Yes, it might happen, and I think it's fine if we solve that scenario currently described in the draft. 
That said, I don't think that for this draft we must pursue the goal of addressing the general multicast issues raised in the other recent drafts. This draft pursues incremental improvement in the context of the existing protocol.

Speaking for myself only, I think either (1) & (2) or (1) & (2) & (3) are fine.

>> ii) solve both problem 1 and 2. which implies taking the document back to the working group

I'd suggest re-phrasing this as "instructing the authors to update the scenario text and the suggested host behavior and re-submit for LC".

Thank you,
Dmitry

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2014 1:49 AM
To: Dmitry Anipko
Cc: Suresh Krishnan; <[email-masked]>; [email-masked]; 6man WG
Subject: Re: draft-ietf-6man-resilient-rs update

cheers,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Wed, 30 Jul 2014 11:55:47 -0700

At Tue, 29 Jul 2014 10:48:31 +0200,

> ii) solve both problem 1 and 2. which implies taking the document back to the working group

Not a strong opinion, but given that we've already spent quite a long
time for the draft, I think I'd prefer option (i).

--
JINMEI, Tatuya