Ted, >> you make it sound like that's a part and parcel of DHCP. I can't see how you >> can implement that today. > > Eh? It's dead trivial. The draft already sets up relay agents—the only > difference is that all relays now relay to both CERs, not just one. The > requesting routers get delegations from both CERs and use both delegations.
you cut out my question about how to build the relay topology. e.g. relays would have to replicate client messages to multiple CERs. > You are right that no existing implementation does this, but no existing > implementation does homenet, so that seems like a pretty mild criticism! :) a goal for homenet is to reuse existing implementations. >> "homenet routing protocol server"? this proposal makes do with static >> routing. > > When I said the proposal looked mostly right, I was referring to the DHCP PD > aspect, not the static routing aspect. Static routing might work, but I > suspect it would be brittle. > >> how do you deal with multiple routers on the link? just keep adding /64s out >> of the same site-prefix to it? > > Only the CERs delegate prefixes. If you have multiple paths to the same CER, > you will still only get one prefix per identity association. a link with multiple routers on it will get multiple prefixes from the same site prefix. >> how does the network react to network events? given you rely on DHCP >> snooping then network convergence time >> is rather glacial. > > Right, I'm not arguing that we don't need a routing protocol. I'm not even > particularly arguing that PD is the right way to delegate prefixes. But it > would work, and with no protocol changes—it would just require an operations > document to explain how to do it. I see you are making that assertion. I don't believe you. please write a draft how this would work. cheers, Ole
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
