> 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.
by other configuration information I was thinking of two types of information: - information that is required by the other routers in the home network. e.g. zone information required for hybrid mDNS proxies - information that is passed around to the routers, and then passed on to the hosts using RA or DHCP: e.g. DNS recursive resolvers, DNS server selection policy, SAS/DAS selection policy I think there is an important 'scoping' here. the mechanisms here should be used to configure the function of the routers in the home network, and pass information to the hosts to configure the _network_ layer. I don't quite see how you can (or should) configure applications this way. cheers, Ole > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
