big sigh in dealing with this absolutely silly response....oh well. When you dont send an RS "regardless of the LIO" and the Edge Router is "configured to send an RA only when in receipt of an RS" then this case will fail even when you have a 1:1 VLAN scenario. So in the event that these hosts are SLAAC only based this is an issue and this occurs regardless of the LIO.
I agree with you this is an issue but not in the context of LIO for RS. Alan ________________________________ From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Wojciech Dec Sent: August-26-10 4:19 AM To: Suresh Krishnan Cc: Brian Haberman; IPv6 WG Mailing List Subject: Re: RS Lost failure scenario (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt) On 26 August 2010 00:47, Suresh Krishnan <suresh.krish...@ericsson.com<mailto:suresh.krish...@ericsson.com>> wrote: Hi Woj, I think this is the basis of our disagreement. There are no assumptions that this document is making. There are usage scenarios not involving the mechanism proposed in this document that are relevant to this issue you are bringing up. Indeed, this seems to be the base of the current misunderstanding. Based on the available information, the intent of the rs-mark mechanism is to use the additional line-id information at/by the edge-router to selectively assign a *different* IP prefix to each subscriber (where subscriber = one or more IPv6 end-devices behind a given Line-id). This has been corroborated by statements made on the thread. Based on all this, one can currently conclude that that such end-devices will *only* obtain valid IP addressing info *after* they send an RS, and then receive a response by means of a unicast RA, not at any time before before. The latter aspect has been confirmed by the presence of periodic PIO-less multicast RAs in the scheme. Hence, I come to ask: Suppose an end-device time-outs in sending RSes before getting an RA in response. How does a context relying on the rs-mark scheme deal with this case? If the answer is "it uses PIO-less multicast RAs", then it does not appear to be enough (based on RFC 4861 not mandating hosts to respond to RAs). Alternatively, what assumptions are you going by (eg. a special type of IPv6 end-device? a plan to modify rfc4861? other?)? IMO such assumptions need to be documented Let's say the mechanism proposed in this draft did not exist in either the IETF or BBF. Does the problem of the lost RSs exist? I contend that it does. What do you say? Unless we have a common view on this, I do not think we can agree on a resolution. I certainly agree with you that RS losses and/or timeout issues are not unique to the rs-mark usage context, but unlike in the traditional case, where periodically sent multicast RAs would contain a PIO allowing an end-device to acquire an address, here I don't see how recovery from such issues takes place. The result appears to be end devices having no IPv6 connectivity, which I'm sure you agree is not a good thing. In other words, the RS lost/timeout problem appears to be particularly severe in its consequences when used with what the RS-mark mechanism says it is intended for. Thanks, Woj. Thanks Suresh
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
