On 26 August 2010 00:47, Suresh Krishnan <[email protected]>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 [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
