Re: [homenet] Multilink subnet routing (MLSRv2)
Having missed the meeting, anything more recent on MLSR than this: draft-ietf-ipv6-multilink-subnets-00 Multi-link Subnet Support in IPv6 (2002-07-08, Expired) draft-thaler-ipngwg-multilink-subnets-02 Multi-link Subnet Support in IPv6 (2001-11-29, Expired) The only reference to MLSR in an RFC is in an IAB RFC, RFC4903: There was also a proposal to define multi-link subnets [MLSR] for IPv6. However, this notion was abandoned by the IPv6 WG due to the issues discussed in this memo, and that proposal was replaced by a different mechanism that preserves the notion that a subnet spans only one link [RFC4389]. Note that there is a subset of the multi-link subnet problem that can be solved using an off-link model as described in RFC 5942, and is currently deployed in DOCSIS networks. - Wes ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Multilink subnet routing (MLSRv2)
Hi Ole we (as in homenet) do not want to require host changes. And when hosts get smarter we (as in people living in homes) should benefit from it. The case of plain hosts was long debated but it would have overloaded the specs quite a bit. What we have so far: The backbone router proxies ND between a L2 backbone and one or more MLSN extensions; this allows a plain (classical) host connected to the backbone to transparently reach devices that are located over the MLSN. Things get touchy if we want to support the case of a plain device that would attach deep into the MLSN. You will not find that support specified in current RPL or 6LoWPAN specs. There's a good start though since RPL is designed to transport the material that is required by the leaf router to build RAs, so for the purpose of forming an address we can make believe that the plain host is really connected to the subnet. But the question is how the formed address can be DADed and routed. In the absence of an explicit and maintained registration, the attachment router/switch has to snoop and then proxy, either as an ND registration or as redistribution into the routing protocol; If the device as a unique, P2P connection with the router, then we can reuse what we learnt in SAVI to maintain states in the router on behalf of the plain host. If the device is connected to multiple routers and/or the device is mobile and changes that point(s) of attachment over time, things can get a lot messier. I also think the issues with flooding ND has been explored in RFC4903. Thanks for pointing this. RFC 4903 explores a number of aspects, not just ND, and in particular, TTL and link scope multicast. Specifically focusing on ND, the scope and propagation of multicast already required a new protocol. RPL started as an ND extension if you care to browse the early drafts. The work that I listed below addresses for a large part the problem of ND over MLSN, yet does a limited job for generic link scope multicast. Then again there is a good start with the optimized flooding with trickle that is good for all nodes and all routers, and a support for a multicast tree along the RPL DAG for generic multicast. Cheers, Pascal On Oct 10, 2011, at 9:33 , Pascal Thubert (pthubert) wrote: 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 -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 ___ homenet mailing list
Re: [homenet] Multilink subnet routing (MLSRv2)
Ole == Ole Troan o...@cisco.com writes: Ole we (as in homenet) do not want to require host changes. I also Ole think the issues with flooding ND has been explored in RFC4903. RPL benefits from host changes, but if you provide proxy-ND for the hosts which have not changed, then it much the same as MLSRv2, I think. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
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
Re: [homenet] Multilink subnet routing (MLSRv2)
Erik, 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. And I assume the routers would pass around /128 routes for the hosts in the home, and would automatically inject such a route when the SAVI-style table learns about a new address. Are those assumptions correct? yes. 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. What happens when the router crashes - does it loose its SAVI-style table? Does it keep it in stable storage? it could. If it looses it, then nobody would know on what link the hosts are, since the hosts aren't required to periodically send any announcement to the routers. indeed. directly connected hosts would get a L2 event. in the more creative department you could run with low timers, and you could enforce a direct mapping between MAC address, link-local address and global address. thereby being able to recreate global address binding state just from a link-local addresses. What happens when a packet arrives for an IP address that is in the /64 prefix for the home, but there is no /128 route for it? Flood everywhere? Drop? drop I'd imagine. We looked that this when we worked on 6lowpan-nd, and concluded that by doing explicit registrations from hosts to routers (the Address Registration Option) with a lifetime we can make such networks work well without requiring stable storage. But that implies a host change. yes, registration makes this safer. I just intended to point out that this could be one tool in the toolbox. not that we should necessarily build homenets this way. cheers, Ole ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
