Subject: [homenet] Prefix stability requirements in draft-arkko-homenet-prefix-assignment-00

From: Erik Nordmark <[email-masked]>
Date: Fri, 28 Oct 2011 18:16:19 -0700

The document has fairly week stability requirements:

    o  The assignments must be stable across reboots, power cycling,
       router software updates, and preferably, should be stable across
       simple network changes such as adding a new device on the stub
       network segments.  However, stability across more complex types of
       network reconfiguration events is not a requirement.

I don't understand what a stub network segment is.
Is this a segment which has only one router connected to it?
If so I think the above requirement is far to weak.

I think the goal (but not requirement, because it isn't obvious that it 
can be satisfied) should be to handle the same type of changes that 
bridges can handle without any unnecessary prefix changes on the 
segments. For example, if a segment is split in two separate segments, 
then it would be necessary to assign a new prefix since each segment 
needs a unique prefix. But apart from such necessary changes there 
shouldn't be a need to renumber because routers are added, removed, or 
connected in different ways.

Regards,
     Erik

---

From: Jari Arkko <[email-masked]>
Date: Sat, 29 Oct 2011 21:56:10 +0300

> Is this a segment which has only one router connected to it?

That got written pretty quickly, and can clearly be improved. By "stub network segment" I meant adding a new router on the edges of the network, not in the middle, between existing routers.

But I can see that it was not a well-formed requirement. It seems easy to add a new router anywhere and not have it disrupt the rest of the network, as long as you do not force a network to split into two. For instance, if the old network was

R1 - R2

and then you a new router R3 so that the network looks like this:

R1 - R3 - R2

Then whatever subnet existed before R1 and R2 now needs to change. R1 or R2 or both need to get a new prefix, because the same prefix cannot be in two places.

> I think the goal (but not requirement, because it isn't obvious that it can be satisfied) should be to handle the same type of changes that bridges can handle without any unnecessary prefix changes on the segments. For example, if a segment is split in two separate segments, then it would be necessary to assign a new prefix since each segment needs a unique prefix. But apart from such necessary changes there shouldn't be a need to renumber because routers are added, removed, or connected in different ways.

Right.

I think -- without proving it -- that draft-arkko-homenet-prefix-assignment could actually fulfill your requirement. Assigned prefixes are sticky with routers and per Section 5.3 new routers employ a wait period before assigning themselves a prefix. Barring collisions in the generated suggested prefixes _and_ parts of the network being down, or network partitions this would seem to allow the right thing to happen.

I have edited the requirement text for -01 to be as follows:

    o  The assignments must be stable across reboots, power cycling,
       router software updates, and preferably, should be stable across
       simple network changes.  Simple network changes are in this case
       defined as those that could be resolved through either deletion or
       addition of a prefix assignment.  For instance, the addition of a
       new router without changing connections between existing routers
       requires just the assigment of new prefixes for the new networks
       that the router introduces.  There are no stability requirements
       across more complex types of network reconfiguration events.  For
       instance, if a network is separated into two networks connected by
       a newly inserted router, this may lead into renumbering all
       networks within the home.

Does this work for you?

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 29 Oct 2011 14:14:56 -0700

On 10/29/11 11:56 AM, Jari Arkko wrote:
> That got written pretty quickly, and can clearly be improved. By "stub
> network segment" I meant adding a new router on the edges of the
> network, not in the middle, between existing routers.

If one of the reasons one might want routers is for redundant 
connectivity inside the home, then even something which is conceptually 
a stub (not intended for transit) will have two routers attached to it.

> But I can see that it was not a well-formed requirement. It seems easy
> to add a new router anywhere and not have it disrupt the rest of the
> network, as long as you do not force a network to split into two. For
> instance, if the old network was
>
> R1 - R2
>
> Then whatever subnet existed before R1 and R2 now needs to change. R1 or
> R2 or both need to get a new prefix, because the same prefix cannot be
> in two places.

In that case you are partitioning a link into two, and there one clearly 
needs to add an additional prefix.

> I think -- without proving it -- that
> draft-arkko-homenet-prefix-assignment could actually fulfill your
> requirement. Assigned prefixes are sticky with routers and per Section
> 5.3 new routers employ a wait period before assigning themselves a
> prefix. Barring collisions in the generated suggested prefixes _and_
> parts of the network being down, or network partitions this would seem
> to allow the right thing to happen.

I looked briefly at the solution in the draft, but it seems to 
fundamentally associate the prefix(es) with router interfaces and not 
with links.

An interesting case is a link like this

	rest of home network
	  |            |
	 R1           R2
	  |            |
	  +------------+
	  |            |
	 H1           H2

If R1 is the first router, it assigns a prefix to its southbound 
interface. I take it the solution makes R2 pick up that prefix for its 
southbound interface.
But what happens if R1 is decomissioned? Will R2 permanently assert that 
prefix for the link?

> networks within the home.

First of all, even if no new routers are introduced, there can be L2 
changes which necessitate new prefixes, such as cutting the cable/bridge 
between R1/H1 and R2/H2 above. That isn't much different than 
introducing R3 between the two halves. I.e. either

	rest of home network
	  |            |
	 R1           R2
	  |            |
	  |            |
	  |            |
	 H1           H2

or

	rest of home network
	  |            |
	 R1           R2
	  |            |
	  +-----R3-----+
	  |            |
	 H1           H2

Why would we want to renumber all the networks within the home in such a 
case?

I think a reasonable goal is that we at most cause changes locally H1 
and/or H2 see new prefixes, with no effect on the rest of the home 
network. The best we can do is that only one of H1 or H2 ends up getting 
new prefixes. But that might be hard to accomplish reliably.

   Erik