Hi all, I would like to clarify what is meant by "distribution of other configuration information"? We're all talking about distributing prefixes, but what about SIP and similar configuration parameters? In my opinion, it's not something I would like to see being distributed in OSPF/IS-IS. It's just not something routing protocols should be doing.
That being said, the alternative option is to define a new protocol... Over the last year, I've been playing with the idea of a protocol that uses the DNS idea of recursion (and discussing it with a couple of people). Let me clarify with the example of a SIP server: 1. we have a SIP server at the ISP 2. my home has 7 cascaded HGWs and none of them know the address of the SIP server 3. I want to connect my analogue phone to the sixth HGW and so this HGW needs to find out the SIP server address - he therefore asks his upstream HGW (the fifth in line) for it (of course, using this new and fancy protocol) 4. the fifth doesn't know it and asks the fourth, the fourth asks the third, etc. 5. the first one (the one connected to the ISP) gets the request and requests the ISP via DHCPv6 for it 6. upon receipt, the first forwards the information to the second, the second tells the third, etc. until the 6th receives it and then I can use my phone This approach would have to be worked on (what about multiple upstream links, routing loops?), but I like it. It could be extended to support the delegation of prefixes, active detection of "border" HGWs (when do you send out DHCPv6?)... Any thoughts? Branimir On Thu, Jan 30, 2014 at 2:18 PM, Mikael Abrahamsson <[email protected]>wrote: > On Thu, 30 Jan 2014, Ole Troan wrote: > > We need to decide, if we want prefix assignment and distribution of other >> configuration information integrated in a routing protocol. Depending on >> that decision we either need to design a separate protocol to do that, or >> we need to add support for that in a routing protocol. Prefix assignment is >> simpler with a link-state protocol, so that's why I have limited the choice >> of routing protocols for that branch. I have assumed there is agreement to >> have a single routing protocol in the home, and not support multiple. >> > > I agree with the decision chart. > > While I initially was very enthusiastic about integrating prefix > assignment into a routing protocol, I am now more sceptic to this approach. > > So question if we don't use the routing protocol for prefix assignment, > what should go in there? Should we have a new protocol for service > discovery? Topology discovery? Anything else? Anyhow, the src/dst > enhancements for the IGP has to be done, I don't see much alternative to > that. > > Anyhow, I don't think DHCPv6-PD is a good method to assign prefixes to > interfaces. > > -- > Mikael Abrahamsson email: [email protected] > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet >
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
