Re: [homenet] Egress Routing Discussion: Baker model

[Ray Hunter <[e-mail]>]

> Lorenzo Colitti <mailto:[e-mail]>
> 22 February 2013 11:17
> On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <[e-mail]
> <mailto:[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.
>  
ACK.
>
>     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.
>
Don't understand. Maybe I'm being really dumb.

What about figure 2 of the Homenet Architecture? <fixed width>

           +-------+-------+     +-------+-------+         \
           |   Service     |     |   Service     |          \
           |  Provider A   |     |  Provider B   |           | Service
           |    Router     |     |    Router     |           | Provider
           +------+--------+     +-------+-------+           | network
                  |                      |                   /
                  |      Customer        |                  /
                  | Internet connections |                 /
                  |                      |
           +------+--------+     +-------+-------+         \
           |     IPv6      |     |    IPv6       |          \
           | Customer Edge |     | Customer Edge |           \
           |   Router 1    |     |   Router 2    |           /
           +------+--------+     +-------+-------+          /
                  |                      |                 /
                  |                      |                | End-User
     ---+---------+---+---------------+--+----------+---  | network(s)
        |             |               |             |      \
   +----+-----+ +-----+----+     +----+-----+ +-----+----+  \
   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |  /
   |   H1     | |   H2     |     |    H3    | |    H4    | /
   +----------+ +----------+     +----------+ +----------+

                                 Figure 2

</fixed width>

IPv6 Host H1 will receive RA messages from R1 and R2, and add them both
to the default router list (RFC2461 6.3.6).

IPv6 Host H1 will receive two PIO's, one each from R1 and R2, with
autoconfiguration and on-link flags set, and configure /64 prefixes from
both provider 1 and provider 2 (RFC 2461 4.6.2) and it will know these
as being on-link.

But IMHO there's no further AS number/provider information/upstream
topology information coupled to these /64 prefixes. There might be a
router-router interconnect LAN between R1 and R2, or there might not be.

How will the host H1 know to associate source address prefixes from
provider2 with router2 for off link destinations e.g. to a Provider2/56
or Provider2/32?

My expected host behavior would currently be that it'd just choose one
of the known available default routers from the list. If correct fine.
If not, then wait for an ICMPv6 redirect to be told to use the other router.

But the ICMPv6 redirect doesn't have any facility to include source
prefix specific info: only a redirect for a destination prefix to use
another router (for all source prefixes), not for a source/destination
pair. In the situation depicted in Homenet Arch figure 2, there will
almost certainly be two valid routes to e.g. www.google.com, one via
each provider, with the correct 1st hop router dependent purely on the
source prefix.

Even with RFC4191, the extension only provides routing information for a
host to be able to select a default router based on the destination
prefix, not an associated source prefix.

Are we saying that H1 should tightly couple source address selection
with RA PIO & default router selection?

Thus H1 should never send packets with a source address derived from a
PIO received in an RA from R2, to a potential default router R1 that
sent an RA message but did not include a PIO for this particular source
prefix?

Where is this behavior defined in an RFC? I don't see it in
http://www.ietf.org/rfc/rfc2461.txt Section 4.2 or
http://tools.ietf.org/html/rfc4862#page-18
In fact section 6.3.6. on default router selection is quite explicit and
doesn't mention associating potential default routers with prefix
information options at all AFAIK.

Are we saying that R1 should forward any packets it receives for
(source_provider_prefix 2, ::/0) back over the same LAN to R2 without an
ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is managed
by Provider 2]

Won't the providers naturally want to apply their BCP38 ingress filter
on the LAN interface of their CPE routers? 
as per draft-ietf-v6ops-6204bis-12 L-14 [LAN side requirements]

The IPv6 CE router MUST send an ICMPv6 Destination Unreachable
          message, code 5 (Source address failed ingress/egress policy)
          for packets forwarded to it that use an address from a prefix
          that has been invalidated.


> 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).
>
Understand this. It's the first hop that bother me.

Maybe Figure 2 in the Homenet Architecture is actually a fundamentally
flawed topology, purely from a management perspective.
> 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.
Yes.
> 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?
>
No problem, but why worry about it now if it greatly increases the
complexity?

draft-ietf-v6ops-6204bis-12 effectively limits information in Homenet to
simple default routes per provider only.
 
 W-3:  Absent other routing information, the IPv6 CE router MUST use
         Router Discovery as specified in [RFC4861] to discover a
         default router(s) and install default route(s) in its routing
         table with the discovered router's address as the next hop.

WPD-7:  By default, an IPv6 CE router MUST NOT initiate any dynamic
           routing protocol on its WAN interface.
>
>     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?
Yes. http://www.ietf.org/mail-archive/web/homenet/current/msg02130.html
> Ray Hunter <mailto:[e-mail]>
> 22 February 2013 10:52
> I have read all of your drafts, and those of the other authors,
> carefully, once. No doubt I'll have to re-read them.
>
> This response is limited to high level comments regarding the overall
> approach, and isprobably applicable to all 3 sets of authors :
>
> 1. Some drafts talk extensively about the need for an "extensible"
> routing protocol, and often mention the desirability of TLV
> (type-length-value) objects.
>
> I agree that a TLV structure potentially solves many issues of how to
> encode and transport new options between routing protocol speakers.
>
> 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?
>
> Is there a need for all speakers to first agree the (newest)
> commonly-understood subset of options that all speakers in a Homenet
> can/will honour before any extension options are transmitted?
>
> 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?
>
> 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?
>
> 4. We're still planning on doing something about source address
> selection, aren't we?
> For all the suggested complexity of the packet routing solutions
> suggested so far, isn't the real "route" selection going to be performed
> in the host?
>
> 5. Flow label routing: hasn't rfc6437 scuppered any chance that the flow
> labels themselves will directly carry any meaning that could be
> realistically used to make deterministic forwarding decisions by
> low/mid-powered routers, because you're essentially going to have to
> reverse a 20 bit hash function to make a forwarding decision? Wouldn't
> the requirements in rfc6437 also suggest a routing table explosion,
> because each individual flow would have to be associated with an
> individual IS-IS route? Perhaps you could distribute some intermediate
> result to end hosts and routers via IS-IS,which is deterministic and
> related to policy based routing (such as including the tenant label in a
> TLV), but which after applying some hash transform and adding some
> entropy, would comply with the requirements of 6437? That'd potentially
> reduce the IS-IS routing table size dramatically. I've been waiting 15+
> years for fully dynamic PBR and I fully expect to wait some time longer.
> In any case, with all due respect, I don't think it's relevant for
> Homenet,
>
> 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).
>
> Do I need to write a draft on this, or is this already clear?
> Would someone be willing to help out/ collaborate?
>
> If I have other detailed comments on the individual drafts, I'll come
> back with those.
>
> regards,
> RayH
>
> Fred Baker (fred) wrote:
>
> ------------------------------------------------------------------------