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

From: Ole Troan <[email-masked]>
Date: Thu, 19 Jun 2014 14:08:05 +0200

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

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 19 Jun 2014 16:16:46 +0000

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.

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,

Abstract:

Introduction:

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 20 Jun 2014 14:46:12 +0200

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

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?

cheers,
Ole

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 20 Jun 2014 17:56:33 -0400

Hi Ole,

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

Cheers
Suresh