Hi Curtis; Makes sense, and you'll find that the backbone router draft does not say otherwise if you take the time to parse it. The approach in the draft is to proxy only at the L2 backbone from which the MLSN roots. You'll note that RPL leaves are not plain hosts but need to actively register to the routing. Some work has started to map ND registration into RPL host advertisements but there are issues, in particular when the hosts moves.
The discussion is whether we'd like to proxy again for plain hosts at the MLSN edge routers (eg RPL leaf routers) and my further mail was to indicate that this is really asking for trouble. I think that Erik 's mail leads to similar conclusions. Cheers, Pascal -----Original Message----- From: Curtis Villamizar [mailto:cur...@occnc.com] Sent: lundi 10 octobre 2011 23:35 To: Pascal Thubert (pthubert) Cc: Ole Troan; homenet@ietf.org; Erik Nordmark (nordmark) Subject: Re: [homenet] Multilink subnet routing (MLSRv2) In message <bdf2740c082f6942820d95baeb9e1a841c6...@xmb-ams-108.cisco.com> "Pascal Thubert (pthubert)" writes: > Hi Ole: > > I think you're getting closer and closer to the models that were > discussed in RPL, 6LoWPAN and Autoconf. > > There are several components to the solution that was proposed there: > - capability to register an IPv6 address using ND extensions > - capability to extend a subnet over multiple hops (RPL DIO prefix > option) > - capability to redistribute ND registration into the MLSN routing > protocol > - capability to use the ND registrar (and/or) the routing protocol for > DAD > - capability for the registrar to proxy ND over a backbone in order to > interact with classical ND clients > > See: > http://tools.ietf.org/html/rfc5889 > http://tools.ietf.org/html/draft-ietf-6lowpan-nd > http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > > cheers, > > Pascal IMHO - Any attempts to use ND Proxy masquerading as a light weight routing protocol are doomed. Failing to deal with the problems of loops in the topology and multiple attachments to the provider will just push the problem from protocol definition to customer support (when the customer's network doesn't work). It is better to get it 100% right in protocol definition, than 90% right with the other 10% going to support calls. Curtis > -----Original Message----- > From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On > Behalf Of Ole Troan > Sent: lundi 10 octobre 2011 00:38 > To: Erik Nordmark (nordmark) > Cc: homenet@ietf.org > Subject: [homenet] Multilink subnet routing (MLSRv2) > > Erik, et al, > > to expand on the ideas I presented on MLSR (or rather MLSRv2 as it > hasn't really been described anywhere) as a method for numbering a > routed home. please let me be clear that I'm not convinced this is a > good idea. i.e. why not just get < /64? > I do think we could get something working though. > > routers can be in an arbitrary topology. all routers running a routing > protocol. > the site prefix (/64) is either advertised in the IGP with a new LSA > or proxying of RA messages is done (split horizon). > a router advertises the same /64 prefix (in a PIO) on all of its > interfaces. L bit is 0. > > the link model here is that all hosts are off link from each other. > link-local scope is restricted to only the physical link. multicast > link-local scope as well. > > a host uses SLAAC (or DHCP) to create an address, then does DAD as > normal. the first hop router uses it's routing topology database to > check for conflicts. similar mechanisms described in SAVI are used to > glean address information from the host. the SAVI binding database is > then used to inject host routes into the IGP. > > this requires no flooding of ND, or any other changes to on-link > protocols for loop detection. no changes in hosts either. > only downside is that it requires a host to have sent a packet of some > form for the SAVI binding to be initiated. > it might also be possible to support host mobility with the home with > this mechanism. > > cheers, > Ole _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
