Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-resilient-rs-01>

From: Ole Troan <[email-masked]>
Date: Tue, 3 Sep 2013 16:02:33 +0200

[resending]

all,

short and sweet document; a few comments if I may.

- this new behaviour is supposed to be implemented by all hosts, right? shouldn't this document then update rfc4861?
- "AP" isn't defined section 1.
- section 1 bullet b. couldn't you argue that turning off periodic RAs is a configuration error?
- section 1 bullet c. If a link isn't multicast capable, you couldn't send RS in the general case either.
                            ISATAP has special provisions for that. could you make c) more general?

- section 2.1. "…results in a default route". is awkward. this is the function we call "router discovery" in rfc4861,
                    where the host discovers a "default router". perhaps just copy or reference rfc4861 verbatim:
  "Once the host sends a Router Solicitation, and receives a valid
  Router Advertisement with a non-zero Router Lifetime, the host MUST
  desist from sending additional solicitations on that interface, until
  the next time one of the above events occurs.  Moreover, a host
  SHOULD send at least one solicitation in the case where an
  advertisement is received prior to having sent a solicitation.
  Responses to solicited advertisements may contain more information
  than unsolicited advertisements."

Best regards,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Sep 2013 05:08:48 +0000

Hi Ole,
  Thanks for your comments. Please find responses inline.

> -----Original Message-----
> From: Ole Troan [mailto:[email-masked]]
> Sent: September-03-13 10:03 AM
> To: Suresh Krishnan
> Cc: 6man WG
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-resilient-rs-01>
> 
> [resending]
> 
> all,
> 
> - this new behaviour is supposed to be implemented by all hosts, right?
> shouldn't this document then update rfc4861?

Sure. Will add the updates tag

> - "AP" isn't defined section 1.

Will add it.

> - section 1 bullet b. couldn't you argue that turning off periodic RAs is a

Not sure. It is commonly used in several WLAN and datacenter networks
to reduce the amount of multicast traffic.

>                             ISATAP has special provisions for that. could you make c) more

Not sure how to make this more general. Do you have some suggestions?

> 
> - section 2.1. "...results in a default route". is awkward. this is the function we
> call "router discovery" in rfc4861,

Would it work if we simply reword " an RA that results in a default route is received" 
into "an RA with a non-zero Router Lifetime"?

Thanks
Suresh

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Sep 2013 11:38:49 +0200

Suresh,

> to reduce the amount of multicast traffic.

ack.

> Not sure how to make this more general. Do you have some suggestions?

what was your intention with bullet c?
right now it doesn't logically make sense. the link is not multicast capable =>
RS uses multicast => host cannot send RS either.

> into "an RA with a non-zero Router Lifetime"?

use RFC4861 terminology, and say something like "successful Router Discovery"?

cheers,
Ole