Subject: [homenet] Multilink subnet routing (MLSRv2)

From: Ole Troan <[email-masked]>
Date: Mon, 10 Oct 2011 00:38:28 +0200

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

---

From: Mark Townsley <[email-masked]>
Date: Mon, 10 Oct 2011 00:18:27 -0400

it would seem that we only have 3 choices once we run out of /64s to give out on links that for whatever reason we cannot bridge on.

1. No IPv6
2. NAT IPv6 
3. MLSRv2 (if what you propose works, I don't yet see why it wouldn't)

I think this is a case of what is the least bad option. We shouldn't ignore the problem though.

- Mark

On Oct 9, 2011, at 6:38 PM, Ole Troan wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Oct 2011 09:33:55 +0200

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Ole Troan
Sent: lundi 10 octobre 2011 00:38
To: Erik Nordmark (nordmark)
Cc: [email-masked]
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

---

From: Ole Troan <[email-masked]>
Date: Mon, 10 Oct 2011 13:25:18 +0200

Pascal,

we (as in homenet) do not want to require host changes.
I also think the issues with flooding ND has been explored in RFC4903.

cheers,
Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Oct 2011 17:33:00 +0200

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

> protocol.
> the site prefix (/64) is either advertised in the IGP with a new LSA 
> or proxying of RA messages is done (split horizon).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Oct 2011 14:01:14 -0400

>>>>> "Ole" == Ole Troan <[email-masked]> 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[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Oct 2011 11:43:26 -0700

On 10/9/11 3:38 PM, Ole Troan wrote:
> 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?

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?

> 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?

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.

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?

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.

    Erik

---

From: Mark Townsley <[email-masked]>
Date: Mon, 10 Oct 2011 15:19:22 -0400

On Oct 10, 2011, at 2:43 PM, Erik Nordmark wrote:

> 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.
> What happens when the router crashes - does it loose its SAVI-style table? Does it keep it in stable storage?
> 
> 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.
> 
> 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?
> 
> 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.

I heard a lot about stable storage being a requirement for a homenet router... and not much objection from the vendor reps. Perhaps that is a difference between homenet and lowpan.

- Mark

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 13:50:13 -0700

In message <[email-masked]>
Ole Troan writes:
 
> good idea. i.e. why not just get < /64?  I do think we could get
> something working though.

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].

As to the second comment regarding /64: The magic /64 boundary should
be interpreted as follows:

  Anything shorter than or equal to /64 can be globally routable.

  Anything longer than /64 may not be globally routable.

For core routers the usual behaviour (or at least goal) is:

  Anything shorter than or equal to /64 can be forwarded at full
  speed, even for long bursts of very small packets.

  For anything matching a 64 bit "local subnet" address, look at the
  bottom /64 and still forward at full speed, even for long bursts of
  very small packets.

  For everything else (ie: not in a local subnet, and longer than /64
  prefix) forward anyway, but maybe not at full speed.

The whole purpose of this is that longer LPM lookups take time and at
high speed like like 10 Gb/s or 100 Gb/s (or more), it is really hard
to go faster without a high cost in silicon die area and power (and
worse yet for anything using external TCAM, two external lookups).

The /64 boundary was rather arbitrary.  (And IMNSHO further evidence
that 128 bit addrseeses was a bone headed choice and much too long,
but it is way too late by about a decade or more to change that).

There is no reasons that homenets (generally supporting 1 Gb/s or
less) can't further subnet a /64.

> 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.

Not a good assumption.  There will still be dumb Ethernet switches and
bridging only WiFi hubs out there for a long time, so multiple hosts
on a subnet/link.

> then used to inject host routes into the IGP.

Neither SLAAC (rfc2462) or DHCP6 (rfc3315) supports allocation of a
non-link-local prefix for the purpose of subdividing a prefix.  For
example, in DHCP6, the IA_TA and IA_NA are assumed to be link-local.
The IA-PD added this capability to DHCP6, but there is no
corresponding addition to SLAAC, so DHCP6 is preferred for routers.

Where multiple routers exist, all will initially be sending an IA-PD
request to each other.  If there is no connectivity to a service
provider who responds to an IA-PD, and none of the routers are
configured, then none should respond (can't sub allocate what you
don't have).

If the provider sends an IA-PD, response with a /64, then that border
router can respond with suballocations.  There is no guidance in
rfc3633 as to what to initially send in a IA-PD, but I suggest the
following (which lacks loop suppression):

  send 0/112 (65K addressses) initially

  send 0/[len+8] if the following are both true:
    the router has received an IA-PD request from another router, and
    the router already has a prefix assignment, and
    the existing prefix assignment is too small, and
    len is the longest prefix length it has

What is needed then is request loop suppression.  A new IA-PD would be
needed.  One possibility is a new IA-PD option in which the set of
IA-PD requestors is listed.  This creates a path vector loop
suppression, much like BGP using AS numbers.  If a router gets two
replies, prefer the one with the shorter path.

Having set up one or more prefixes, a router can then select a
router-Id (non-trivial) and start running a link state IGP (or link
state IGP with specialized metric for LLN or whatever).  That will
have to be the topic of another thread (please).

Another issue brought up is a multihomed connection.  If the provider
is smart, both of the connections will respond with the same /64 to an
IA-PD request.  That would be set up at service provisioning time.  If
the client was also smart, the border routers would not even bother
with an IA-PD request and have the /64 configured.  Absent of this,
then the homenet would have two /64s to allocate from and would
allocate from both.

There is no harm in a subnet having more than one prefix allocated to
it.  If a routing protocol is running, then any arbitrary fault, short
of a partition, would maintain connectivity.  With a partition, bad
things can happen.  Do we solve that?

> 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.

The other down side is you essentially have host routes.

I'm definitely not in favor of making homenets run more like bridged
networks which is what MLSR does (afaik).

ND Proxy (rfc4389) is also making a network look more like a bridged
networks (no traceroute support, does not always use shortest path,
less than robust zero configuration loop suppression, etc.  IMHO ND
Proxy should also not be considered.

cheers,

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 14:20:59 -0700

In message <[email-masked]>
Mark Townsley writes:
 
>  
> it would seem that we only have 3 choices once we run out of /64s to
> give out on links that for whatever reason we cannot bridge on.
>  
> 1. No IPv6
> 2. NAT IPv6 

There is no reason to give out /64 or shorter to every link.

A prefix longer than /64 is not *globally* routeable.  It is locally
routeable.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Oct 2011 14:35:25 -0700

In message <[email-masked]>
 
> http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Oct 2011 00:46:15 +0200

Erik,

> Are those assumptions correct?

yes.

> 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.

> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Oct 2011 14:07:12 +0200

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:[email-masked]] 
Sent: lundi 10 octobre 2011 23:35
To: Pascal Thubert (pthubert)
Cc: Ole Troan; [email-masked]; Erik Nordmark (nordmark)
Subject: Re: [homenet] Multilink subnet routing (MLSRv2)

In message
<[email-masked]>

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

---

From: Wes Beebee <[email-masked]>
Date: Tue, 11 Oct 2011 09:46:55 -0400

>    different mechanism that preserves the notion that a subnet spans

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