On 25 August 2010 17:18, Suresh Krishnan <[email protected]>wrote:
> Hi Woj, > > > On 10-08-25 04:31 AM, Wojciech Dec wrote: > >> Hi Suresh, >> >> thanks for looking further into this problem, and publishing an updated >> draft 07. Let me however stress that this problem is one very strictly tied >> to the (supposed?) usage context of the RS-mark mechanism, and thus it >> really needs to be described/addressed in the rs-mark draft, not some other. >> > > I respectfully disagree. Here's why. The RS-mark mechanism describes how > RSs are marked and how the responding solicited-RAs are sent. It has got > nothing to do with other neighbor discovery messages. e.g. Unsolicited > multicast RAs, Redirects, DAD NS/NAs, Address resolution NS/NAs etc. which > are sent as defined in RFC4861/62. The draft simply does not mention > anything about these other messages. If you can clarify why you think this > is relevant to this draft, I will certainly add it here. Your argument seems to be saying that the draft is not to discuss/mention the overall context/intended usage of the mechanism and that steam rolling a simple RS-marking mechanism is what should be followed. I'm arguing, as are others, that the overall context and an understanding of the scenario where the RS-mark mechanism is to be used is required, as there appear to be issues there that are of relevance to the IPv6 community. Given that you are one of the authors/proponents of this draft/mechanism in both the IETF and in the BBF simultaneously, it's only fair to ask you the question to explain the context & assumptions, given that they are no-where to be seen publicly. > > > The reason for this is simple: On regular SLAAC networks, RAs get >> periodically ad-infinitum multicast to all nodes allowing such nodes to >> perform SLAAC, thus the loss/timeout of a client in sending RSes does not >> matter much. >> In contrast, and in what I currently understand as the RS-mark usage >> scenario to be, no such periodic multicast RA is sent until the client sends >> an RS. >> > > This is not true. The draft does not modify RFC4861/RFC4862 behavior in any > way for unsolicited multicast RAs. Sigh. Please point me to *where* in does the draft mention periodic unsolicited multicast RAs? > > > > Hence, clients that time out from sending RSes have no > > chance of running SLAAC or connecting, other than perhaps through some > > manual intervention. > >> Draft 07 does not appear to address this issue, while it most definitely >> should given its rather serious consequences for regular ICMPv6 clients. >> Could you explain to us the mechanism from recovering from this problem (eg >> CPE reload?)? On the email thread, there was mention of a) this being an >> allowed un-recoverable failuire scenario or b) multicasting RAs downstream. >> The text in draft 07 does not reflect either, so which one is it? >> > > Multicasting an RA is not optional. Period. So b) is a given. The draft > does not have to specify this. It needs to be done in any compliant network. > The question is whether this periodic unsolicited multicast RA needs to > contain a PIO usable for SLAAC. For this, my answer is a NO. > So now I understand your answer, ie PIO-less multicast RAs are necessary. Perhaps then the draft should state that, but before we go there perhaps you could come to answer the following question that again is part of the original RS timeout issue, which I understand you agree exists. RFC4861 states: "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." Notice the "SHOULD", which is clearly not a "MUST" as would seem to be what the PIO-less multicast RA sending approach would need to rely on. Thus, for the scheme to work, you are either assuming: 1. A client IPv6 stack that follows more tightly (ie assumes MUST send an RS) RFC4861. OR 2. Expecting a change of RFC4861. Which one is it? Cheers, Woj. > Cheers > Suresh >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
