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. 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. 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?
Regards, Woj. On 25 August 2010 03:46, Suresh Krishnan <[email protected]>wrote: > Hi Woj, > > On 10-08-20 03:34 AM, Wojciech Dec wrote: > >> Hi Suresh, >> >> Good to hear that you will be clarifying the draft. I take it that showing >> the full intended RS/RA message exchange will be part of that clarification. >> > > I think that the issue you and Ole raised about the lost RSs is an > important one and is, I believe, applicable to all SLAAC hosts even if they > do not implement this spec. For this reason, I have written a short draft > about this failure scenario and my expected view of how the host can/will > recover and what the network needs to do in order to assist. I intend to > publish it soon. I will send a pointer to the ML after I do so. Please take > a look and let me know if addresses your concern. > > Thanks > Suresh > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
