Re: [homenet] Egress Routing Discussion: Baker model

[Lorenzo Colitti <[e-mail]>]

On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <[e-mail]> wrote:

> But given that route determination is a distributed algorithm, and that
> Homenet devices will not always run the latest and greatest code,
> what action should nodes that are running older code take regarding any
> TLV options that they don't understand?
>
> Isn't there a danger that extensibility will lead to more routing loops,
> instability, and black holes?
>

Yes. If intermediate devices don't understand SADR, you can get routing
loops. We should document that clearly and find out how to avoid it.


> 2. Aren't we forgetting the first hop?
>
> Given a shared subnet/prefix/link with 2 CPE routers performing some
> fancy new form of forwarding (based on PBR or SADR or whatever) that is
> also shared by existing host implementations, how will the routers
> signal these new default route semantics to end hosts?
>
> Would we need a new prefix information option in ND?
>
> Would we need an extension to RFC 4191 Section 2.3 Route Information
> Option to include (source prefix,destination prefix) routes?
>
> Would we need a new ICMPv6 redirect message to extend RFC2461 Section
> 4.5 to include the possibility of (source,destination) redirects?
>

The beauty of this approach is that you don't need to signal anything to
the hosts for things to work properly. The hosts pick whatever source
address they choose and the network takes care of getting the packet to the
right exit.

If the right exit is down or gone, then the packet gets dropped, but as the
SADR draft explains, you can fix this by telling the homenet routers to
deprecate prefixes for which there is no exit. The hosts will then avoid
those source addresses for new connections. (The authors of said draft do
not agree amongst themselves whether this is the right thing to do or not;
but no doubt the WG will have useful opinions here).

If you want the hosts to do better load-balancing, then you do need to give
them more information. We haven't looked at this.

If you want to support walled garden prefixes that do not have complete
reachability, then you need to tell the hosts not to use them. I believe
DHCPv6 options exist to configure RFC 6724 policy on hosts, but I don't
know if anyone supports them, and I haven't thought about the security
issues or how to propagate that information through the homenet.

3. Limiting this discussion strictly to Homenet requirements:  Aren't we
> forgetting the inter-provider management boundary?
>
> My view of the Homenet is a network that is potentially a member of
> multiple overlapping AS's simultaneously, without being an AS itself.
> That's highly unusual in routing protocol terms.
>
> I think that it is very unlikely that any operator will allow any
> dynamic routing between a CPE managed by a customer and a PE managed by
> the provider.
>
> I think there's also a potential issue of anyone making any assumptions
> about dynamic routing being available between a provider-managed CPE and
> a customer owned CPE. Software version control will not be trivial.
>
> The current most likely source of external routing information is
> DHCPv6-PD, used to locally autoconfigure a "floating static" default
> route on the Homenet BR, pointing out of the upstream interface to "the
> Internet".
>
> As such, how will any routing information beyond a simple default route
> (related to a single delegated prefix) be injected into the Homenet?
>
> Why are we importing the extra complexity (related to data centres and
> enterprises) into Homenet?
>

I thought the idea was that border routers would just do DHCPv6 PD and
inject whatever routes they get into the homenet tagged with whatever
source prefix they get. They wouldn't participate in any routing protocol
with the ISP. We don't currently have any other mechanism for learning
external routes, but when we do we can simply treat them in the same way.

Does this not work for some reason?

6. Other potentially simpler approaches that might be faster to market
> I have provided detailed feedback to Ole & Lorenzo, suggesting how
> Homenet could potentially work without modifying any routing protocols
> at all, with multi-homing, without resorting to NPT, and with BCP38
> ingress/egress filters (albeit with a hard link to some
> yet-to-be-defined autoconfiguration protocol, and a limit that the
> prefixes of any walled-gardens must be disjoint from other AS's directly
> connected to this Homenet, and possibly some other limitations such as
> dumb hosts should not be connected to dual routers from competing
> providers).
>

Did I miss this? Where can I find it? Was it sent to the list?