Subject: Re: [homenet] routing requirements

From: Don Sturek <[email-masked]>
Date: Fri, 21 Oct 2011 11:53:20 -0700

Hi Lee,

I like this list of requirements!

One thing:  if the requirements on routing to the internet using the alternate prefix proves too complicated on a firewalled interface we should defer that feature.

Don

Sent from T-Mobile G2 with Google

"Howard, Lee" <[email-masked]> wrote:

>I've caught up on some 300 messages about routing.  Here are the requirements I've gleaned.  Question marks are unclear to me, please help.
>
>
>
>1.      Homenet router requirements
>
>2.      When evaluating a solution, discuss whether it provides for:
>
>3.      Reachability between all nodes in the home network.
>
>a.       Links may be Ethernet, WiFi, MoCA, or any other; test all solutions against mutliple L2 types.
>
>4.      Border detection.
>
>a.       Border may be upstream ISP, or may be a device that is a gateway to SmartGrid devices, e.g. a controller that speaks RPL to 802.15.4 and foo to home net.  Or there may be no border, if no external connection has been established.
>
>b.      Must be able to find "up" (a path to the Internet), but must not be dependent on "up" (Internet connectivity) existing for intra-home reachability.
>
>c.       May be discovered by routing protocol, or other means.
>
>5.      Robust to routers being moved/added/removed/renumbered
>
>a.       Convergence time a few minutes or less.
>
>6.      No configuration required.
>
>a.       We might tolerate? a single password being entered on each device.  Discuss.
>
>7.      Best-path is a non-requirement.
>
>8.      Support for multiple upstream networks is a requirement.
>
>a.       Including wireless offload, video-only, and split-tunnel VPN scenarios.
>
>b.      With separate routers to each.  Not multihomed off the same router.
>
>c.       Prefix delegated from all ISPs (upstreams).
>
>d.      ISP A is default.
>
>e.       With only traffic destined to ISP B's prefix using that link.
>
>f.       With a backup default to ISP B, if desired.  What is default condition?
>
>g.      Source address selection is out of scope.  And should be solved by rfc3484, with longest prefix match (whether ULA or walled garden).  Choosing which address to use to look up the destination address is out of scope.
>
>9.      Cannot assume hierarchical prefix delegation in the home (at least, not unless the WG develops such a solution).
>
>10.  A host with mutliple upstream paths to the same destination should be able to use another in case on fails.
>
>11.  Prevent looping.
>
>12.  Prefix stability?
>
>13.  Lightweight (cheap) implementation.
>
>Let me know if I've missed, or mistated, anything.
>
>
>
>Lee
>
>
>
>________________________________
>This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
>
>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Jim Gettys <[email-masked]>
Date: Fri, 21 Oct 2011 16:50:07 -0400

>> Let me know if I've missed, or mistated, anything.

A couple missed: reference the scars on my back I discussed earlier:

Scalability analysis, both for the dense mesh case, and the non-dense case,

Behaviour/scaling when run on wireless, and its ability to handle both
wired and wireless links.

Robustness in the face of unintentional joining of networks.
                    - Jim

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 21 Oct 2011 17:08:14 -0400

> -----Original Message-----
> From: Jim Gettys [mailto:[email-masked]] On Behalf Of Jim Gettys
> >>

Yes, I missed those, and have added them to my list.

Lee

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Oct 2011 20:39:10 -0700

This is a response to Lee's list with Jim's additions.

>> a.       Border may be upstream ISP, or may be a device that is a
>>     gateway to SmartGrid devices, e.g. a controller that speaks RPL to
>>     802.15.4 and foo to home net.  Or there may be no border, if no
>>     external connection has been established.
>>
>> b.      Must be able to find "up" (a path to the Internet), but
>>     must not be dependent on "up" (Internet connectivity) existing for
>>     intra-home reachability. 
>>

This almost covers one of Jim's points.  Jim added unitentional join.

>> a.       Convergence time a few minutes or less.

Seconds at least.  Goal for providers is 60 msec, but subsecond would
be a reasonable goal for wired.

>> a.       We might tolerate? a single password being entered on each

Default requested for core is all access disabled unless overridden by
physical access (ie: hold button and power cycle sort of thing, but
need not be a power cycle or reboot.)  The physical access can be used
to open some interface to allow install of an initial key/password.

>> 7.      Best-path is a non-requirement.

It should be a goal but not a hard requirement.

>> c.       Prefix delegated from all ISPs (upstreams).

This will be hard and may require detection of hosts with new
capabilities and a (less functional) fallback strategy for others.

>> f.       With a backup default to ISP B, if desired.  What is

With no designated A or B, closest is the default, with hysteresis.  A
tie breaker rule would be less desireable.

>> g.      Source address selection is out of scope.  And should be
>>     solved by rfc3484, with longest prefix match (whether ULA or walled
>>     garden).  Choosing which address to use to look up the destination
>>     address is out of scope.
>>
>> 9.      Cannot assume hierarchical prefix delegation in the home
>>     (at least, not unless the WG develops such a solution).

Here I disagree.  Must assume hierarchical prefix delegation.

ULAs are not globally routeable.  ND proxy will fail Jim's scalability
test in an instant.

>> 10.  A host with mutliple upstream paths to the same destination
>>     should be able to use another in case on fails.

The problem is really which address to use in this case.  RFC 3484
does not solve this unless the prefix for the now down uplink is
removed.  Adding a rule to bias the selection toward the prefix from
which the default route is learned would be an update to RFC 3484.

>> 11.  Prevent looping.

Yes please!

>> 12.  Prefix stability?

For legacy hosts.  Detect hosts which don't need it.

> In message <[email-masked]>
> Jim Gettys writes:
>  

Nice list.  Thanks.

Curtis

---

From: Ray Bellis <[email-masked]>
Date: Mon, 24 Oct 2011 08:28:02 +0000

On 22 Oct 2011, at 04:39, Curtis Villamizar wrote:

> Nice list.

+1 from me, too.

This looks to me like a good basis for a detailed routing requirements draft...

Ray

---

From: "Howard, Lee" <[email-masked]>
Date: Mon, 24 Oct 2011 09:28:15 -0400

> be a reasonable goal for wired.

Why would we need that level of repair?  This is a home network, not
a carrier network.

> It should be a goal but not a hard requirement.

Why?

> capabilities and a (less functional) fallback strategy for others.

Yes.  Maybe this should be an assumption, not a requirement, and
the resolution of issues around it is dependent on how we do
address assignment.  The trouble here is that there's no way for
two ISPs two coordinate prefix assignment, so they will both reply
with IA_PD, and two routers will try to use those prefixes.

> tie breaker rule would be less desireable.

What does "closest" mean?  Longest match?

> ULAs are not globally routeable.  ND proxy will fail Jim's scalability

I would prefer a hierarchical solution.  I have not been able to finish
writing up my proposed solution, but it's pretty much "wait to see if
anyone else needs a prefix from you, then request all the prefixes you
need."

Here again, what assumptions we take for routing depend on what we
do for address assignment.  Until then, I think we should not assume
hierarchical delegation.

> which the default route is learned would be an update to RFC 3484.

Deprecating the prefix would help, yes.  For in-home destinations,
any prefix should work.

> For legacy hosts.  Detect hosts which don't need it.

I don't understand this requirement, I just captured it from discussion.
Why is it required?

Lee

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Oct 2011 09:58:13 -0700

Trimmed, leaving only responses to the points Lee brought up.

In message <[email-masked]>
"Howard, Lee" writes:
 
> Why would we need that level of repair?  This is a home network, not a
> carrier network.

On wired it is easy to get subsecond in a small topology.  It would be
nice if you streaming audio, movie, phone call to support, etc, stayed
up when a minor change was made as long as connectivity still existed.

> > It should be a goal but not a hard requirement.

Having your HD video stream avoid the 10baseT hub that you have never
bothered to through out would be a good thing.  It could also be said
that today the slowest thing out there is 10/100, but why not take a
GbE path if one is available.  Any why not take one 10/100 hop instead
of two?

Its a worthy goal since some application will eventually want the
bandwidth, even if temporarily.

With wireless, best path might be more important, but it seems to be a
more ellusive goal.  At least some people are arguing against it.

> with IA_PD, and two routers will try to use those prefixes.

We need to assume that sometimes there will be cluefull and
cooperative service providers upstream, and sometimes there won't be.

Today some configuration is required on almost any provider uplink.
In the case where the provider installs and completely controls the
CPE, and the demarc is the ethernet the other end may just act as a
DHCPv4 server and won't do anything else.  Then it is hard to identify
this as an uplink as there are all sorts of consumer products today
that do DHCPv4 and claim to have a default route even though there is
nothing connected on the uplink side.

If the provider does respond to an IA_PD with a glocally routable
prefix of length /64 (or less specific), then it can be assumed to be
an uplink.  It may also be doing IPv4 NAT and hand out private address
space typically in 192/24 or 10/8.

> What does "closest" mean?  Longest match?

Closest means what closest has always meant: least cost, ie: best
path.  Least cost is a function of how the routing protocol deals with
metrics.

This is intended as a deterministic and unambiguous tie breaker.

> do for address assignment.  Until then, I think we should not assume

Off topic a bit (your proposed solution).  If everything powers up and
waits for someone else to ask for addresses, then only the hosts ask.
The routers then ask each other in random order and those that are not
direct uplinks have no basis for a response.

If everything asks first, then the uplinks will be the only ones to
respond quickly.  The responses will progress from the uplinks along
the topology until all parts of the topology have one or more prefixes
suballocated from the prefix that was provided to the uplink(s).  In
the absense of legacy devices, all but the closest age out if they
were assigned before the closest.

In the cast where there is no uplink, after a brief timeout ULAs start
being assigned for the purpose of bringing internal routing up and
having internal connectivity.  Again if an uplink becomes available,
then in the absence of legacy hosts or routers, the ULAs can age out.

> Deprecating the prefix would help, yes.  For in-home destinations,

Consider the case where two uplinks come up and each provides a
different /64.  Using an address provided by the closest uplink yields
symetric routing with respect to the set of uplinks.  If one of the
uplinks goes down, then the prefix it provided may not be routable
through the other uplink (another provider may route toward a less
specific prefix if the more specific for your house is not globally
announced.  It is very unlikely that your /64 will be globally
announced for the purpose of your home network multihoming.  The
uplink router needs to *try* to withdraw the prefix.  For the benefit
of the legacy devices that continue to use the no longer working
prefix, the other uplink must NAT (IPv6 to IPv6).  The newer hosts and
routers will stop using the no longer working prefix and switch to the
working prefix.  Connections that were up using the old prefix will go
down (equiv of network unreachable, except more authoritative).

> I don't understand this requirement, I just captured it from discussion.

Legacy hosts need prefix stability.

You have to know which hosts don't need to be assigned a stable
address.  If all of the hosts are capable of promptly giving up the
address they were assigned, then there is no need to keep a prefix
that is no longer routeable due to an uplink going down.

Curtis