Alan Kavanagh <[email protected]> writes: > 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. It is an optimization from an IETF IPv6 architecture/protocol perspective. It is an optimization in the sense that hosts will operate correctly even if they *never* send out an RS. (They may not have connectivity while waiting for an unsolicited RA, but they will eventually get it.) In other words, sending RSs is not *required* for correct operation. And if your architecture requires that RSs be sent in order to make things work, you will certainly to run into real problems. > 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. And my point is you cannot assume you will always get an RS. And when you do not, communication will fail and you will have people calling your Help Desk. There are scenarios that will happen in practice where you will not get RSes when you think you will. There is actually extensive experience with such failures on the IPv4 side with DHCP, where DHCP packets are needed to ensure that edge routers (or whatever entitity it is) learn what subscribers are active. They've had to extend/hack various DHCP protocols over the years to handle all the failure cases. You would do well to learn from their experience to be sure your approach covers all the cases they experienced... (And from what I can, you have gaps.) > 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... Right. And things work again for a few weeks. Then they break again. Then the customer goes through the same process. Multiply this by millions of customers and ask yourself if the savings you derive from cheap/dumb ANs makes up for your recurring Help Desk costs.... > 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? Yes. That is what ND assumes. That is a basic assumption. If you have a different environment, you'd be far better off using DHCP. RAs are desgined/intended for environments where all nodes on the link receive the same information. Where none of the RA options are "client specicic" and where all RAs are periodically multicast at L2, because all nodes get the same info. RAs work a lot less well (from a protocol perspective) if you unicast RAs with client-specific information in individual RAs. DHCP is the much better choice for dealing with the type of scenario you have architected. > 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 have no problem with that. My problem is with how you are going about architecting the overall solution. > 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. You can pay me know or you can pay me later (in help desk/operational costs). :) > 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 ;-) And the question I have (which you did not answer) is how do you rebuild state when it is lost? And to repeat myself, you *cannot* rely on RSes for this. I think your proposed approach has real gaps that you have not considered (at least not from what I understand of the overall approach). Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
