Hi Thomas
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Narten Sent: August-26-10 8:38 AM To: Wojciech Dec Cc: Brian Haberman; IPv6 WG Mailing List; Suresh Krishnan Subject: Re: RS Lost failure scenario (Was Re: Consensus call on adopting:draft-krishnan-6man-rs-mark-06.txt) I htink Woj is right and raises some fundamental issues. 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. Alan--> I don't see it as optomistation but a way to see the "First Sign of Life" which is a concept we have in BNG nodes and in BBF docs that we "trigger" an IP Subscriber Session based on some packet sent by the host, which maybe a DHCP_Solicit or a Router Solicitation. So the same sub session state mechanism applies here on the Edge Router (BNG) for RS messages, makes perfect sense. 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: 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. Alan--> Sure I agree. And as I noted above, we are waiting for the RS to trigger the IP Sub Session. What I really like about this is in a case where my Residential Gateway dies/acts stupid (lots of them do this ;-o ) and I call my DSL SP whom tells me to detach my RG and connect a host directly to my DSL modem. In the case of IPoE + N:1 VLAN deployment model the host sends an RS etc....and the BNG receives this and triggers an IP Sub session. IF the BNG don't receive the RS then we have an issue somewhere on the path/host/network node etc... 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. Alan--> Agree This is not a flaw in ND. This was the intended design in an intended operating environment. Alan--> Agree 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. Alan-->hmmm Are you suggesting that in the case of a single broadcast domain that the SP is better to advertise a single prefix to all attached hosts on the same b-cast domain? Hmm im sure we don't want to do that...and we decided in BBF from feedback from SP's that for their IPv6 Addressing model they "want a unique prefix per subscriber line". 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. Alan--> Well IETF don't advise DSL SP whats their network architecture or what features they need to support, and if we don't do this then a lot of SP's whom have an N:1 VLAN model and have a Bridged RG or bridge some IPoE session will have to spend ooodles of $$$$. I fail to see what is wrong with the LIO for RS, we do it dor DHCPv4/v6 and it makes perfect sense to mirror this to RS. 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. Alan--> Yes have such requirements in BBF for maintaining state in the event of a reboot/node failure, so that's don't by most BNG vendors today ;-) What is the BBF solution to this problem? Has it thought this through? Alan--> as noted above. 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. Alan--> forcing the AN to keep state is not for the discussion here, I believe I spoke to you on this in Anaheim, it don't make $$$$ sense which means it aint going to happen no matter how hard you wish!!!! Thomas Alan--> In the end of the day its about having the choices so the Fixed SP can archtiect his network best suited to its needs. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
