Suresh... On Aug 26, 2010, at 7:20 PM 8/26/10, Suresh Krishnan wrote:
> Hi Thomas, > > On 10-08-26 08:37 AM, Thomas Narten wrote: >> I htink Woj is right and raises some fundamental issues. > > Yes. And nobody said anything to the contrary. I problem is that the issue is > orthogonal to the mechanism described in the RS mark draft. Even if > draft-krishnan-6man-rs-mark was never written, this problem would still > exist. I have tried to put the issue down in a draft so that we can discuss a > workable solution. I would appreciate your comments on the draft. > > http://www.ietf.org/id/draft-krishnan-6man-rs-lost-00.txt > >> The RS/RA mechanism *assumes* that routers send out periodic multicast >> advertisements. Having nodes send out an RS to solicit RAs is a sort >> of optimization, intended to prod routers into sending out an RA >> immediately. But the sending of RSes is NOT a fundmental part of RAs. > > Right. And in this specific scenario routers DO send out periodic multicast > advertisements as expected. But the multicast RAs don't advertise prefixes, right, so the subscriber nodes won't be able to complete SLAAC? >> Once a node has obtained an RA, the basic model assume that a node >> need not send any additional RSs out. Periodic RAs will supply the >> info it needs. This is made clear in RFC 4861, which says: > > I am not sure I agree with you on this one. Again, quoting from scripture > (Section 6.3.7 of RFC4861): > > "Responses to solicited advertisements may contain more information > than unsolicited advertisements." > > seems to indicate that the original ND spec anticipated the possibility that > the periodic multicast RAs could contain less information that the solicited > RAs. I think the point is to use standard node stacks: Windows 7, OS X, Linux. Do any of them send periodic RSs? >> 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. >> where the "above events" refers to things like the interface >> restarting, attaching to a link again, etc. >> In other words, once a node has received RAs, the protocols do not >> require it to send additional RSs, even if it doesn't recieve RAs. >> The only reason RSes are there in the first place is to handle >> restarting nodes, who want to get an RA immediately instead of waiting >> for the next periodic one. >> This is not a flaw in ND. This was the intended design in an intended >> operating environment. >> What is proposed in Suresh's draft is a configuration that simply >> doesn't match a normal network. Namely, a single broadcast domain, but >> RAs tailored to individual clients. > > I have to say that such networks are not uncommon and not limited to > Broadband Forum access networks. e.g. A wireless lan network with multiple > SSIDs and different vlans upstream to reach the router needs to act in > exactly the same way in order to keep prefixes separate between the SSIDs. > >> I am not yet convinced that the IETF needs to (or should) support such >> a configuration, as it is clear that even with the proposed option, >> there are other issues with the target environment. >> The Edge Router in the draft will be required to send unicast RAs to >> all individual devices. It will need to maintain sufficient state to >> do so, even if the Edge router restarts. Replacing the edge router >> with some other router will cause problems because the new router >> won't have the missing state, and there is no clear way to rebuild it. >> What is the BBF solution to this problem? Has it thought this through? >> A far better solution is for the AN node to have enough of an IP stack >> on it so that it can source RAs and provide the right information. >> Just because some "don't want to do this" (for cost or other reasons) >> doesn't mean we should support it, especially if we don't think the >> approach will be reliable or robust in practice. We should only bless >> an approach if we think it can be made to work in practice. > > This draft is a request for allocation of a destination option for > implementing a BBF specific mechanism. It is specifically not a request for > the IETF to bless the mechanism. The mechanism has been described in the > draft to provide the background for the usage, as requested by the WG. > > The way I see it, without this option, SLAAC-only hosts will be left without > any way of obtaining an address in these specific deployments. But this option isn't all that is needed for the deployment architecture, and it appears that there is a significant problem with that deployment architecture. It makes sense to me to hold off on approving this option until the deployment architecture in which it will be used has been shown to be deployable. > Thanks > Suresh - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
