Subject: [homenet] Egress Routing Discussion: Baker model

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 21 Feb 2013 19:23:03 +0000

On Feb 22, 2013, at 6:22 AM, Fred Baker <[email-masked]> wrote:

> In Atlanta, Mark asked Lorenzo and I to put together a draft of an approach to source/destination, and especially egress, routing. I pulled together a plan of attack that I applied to both IPv4 and IPv6, and to both IS-IS and OSPF and sought review from a limited list including Lorenzo; this includes capabilities for at least one other use case I'm looking at. Mark asked me to cut that down to make things separately implementable (which they would be anyway, but to make it apparent). So I have broken it into components.
> 
> ......
> 
> I have documented my approach, which provides the generalized concept, is built into the routing protocols IS-IS and OSPF, and also addresses at least one other "tagged routing" option, which is to look at flow labels.
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-automatic-prefix
>  "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-flowlabel-routing
>  "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing
>  "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-flowlabel-routing
>  "Using OSPFv3 with Role-Based Access Control", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing
>  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13
> 
> http://tools.ietf.org/html/draft-baker-ipv6-ospf-extensible
>  "Extensible OSPF LSAs", Fred Baker, 17-Feb-13
> 
> I'll say why I think mine is the correct approach in another email, as I imagine my colleagues will for theirs. But the working group should consider the question.

This is that separate email. As I start, may I make the most direct possible apology to my colleagues with other approaches. I'm going to say that I think you're "wrong", and say why. That is in the spirit of open discussion in which we have a technical disagreement. BTW, you should be aware that I have a fair set of people who are telling me I'm wrong as well, hopefully in the same spirit. Some of them are pretty irritated with me, and I have gotten irritated with them.

Two parts of the question here relate to "what problem do we think we're solving" and "how do we model the network". A third will be "how do we implement it in a router?"

Homenet, I believe, thinks it's solving "how do I provide egress routing with zero, or perhaps epsilon, configuration, using open source code in the cheapest possible implementation." That's laudable; that said, I do believe that egress routing is a requirement for any IPv6 network involving multiple provider-allocated prefixes, and that as a result this is something to be built into the base protocol. In OSPF terminology, it is sufficient to build on an AS-external-LSA if that's the only source/destination route to be considered (it is certainly a principal use case); for a general network, however, we don't generally carry a lot of AS-external information around. So we need, I think, the ability to use native default routes as well as AS-external default routes, which means that we also need to look at the intra-area-prefix-LSA and the inter-area-prefix-LSA. The problem, I argue, is how to tag a route with a set of attributes and apply a route policy to it. One possible attribute is the source prefix that might be used by systems communicating with this destination, and there are other possible attributes. The route policy is that traffic is forwarded to a stated destination if and only if it also matches the other specified attributes. So, when we want to source/destination route to a specified egress, the destination in question is a default route (::/0), the source is the relevant PA prefix, and we are asking the network to build routes in the way it natively does so for traffic that has the specified set of attributes.

As to "how we model it", there are at least two possible approaches. When Jon Moy was first building what we now call OSPF, one of the problems that the Internet was dealing with was congestive collapse. There were several experiments, one of which I was involved in with Neil Bierbaum of NASNET, in which we wanted to send interactive traffic using paths that had relatively low delay, and high volume file transfer traffic on other paths that had high throughput. It was not unusual for those "high throughput" paths to also have long delay, such as through a geosynchronous satellite. The technology for doing this was originally documented, at least publicly, in RFCs 1131 and 1247, commented on in RFC 1812, and has evolved to RFC 4915's Multi-topology Routing; it was developed in parallel in IS-IS as well. The multi-topology model is based on the premise that routers and/or links differ from each other in some important way, such as capacity, delay, or capability (do they support IPv6? Do they have a stated diffserv configuration?), and that it is useful to segregate them into sub-topologies and build routes within those topologies. The other possible model, which I am following, presumes that one is not routing "to a destination", although arriving at an intended destination is an important facet, or "through a specific topology"; ultimately, one is routing a class of traffic, as I described in http://tools.ietf.org/html/draft-baker-fun-routing-class. That class of traffic (as seen by a given router) consists of the datagrams that will pass through a stated router and have some set of attributes, which might include destination address, source address, a flow label, a DSCP, or several other characteristics. For a DSCP, topology is important - I need to know whether the links have the attributes I am asking about. Those other attributes are not, in my view, topology-relevant - they simply help define the class of traffic. 

So I'm modeling the routing of a class of traffic identified by a set of attributes in what is otherwise a single topology.

When you looked at my list of documents, you no doubt thought "the working group is focused on OSPF as the routing protocol; why IS-IS?" I looked at IS-IS first because it is the simplest to update in this way. The way IS-IS works is that each router advertises an at-least-in-concept single Link State PDU (LSP) that contains information about itself and its neighborhood. The information is stored in type-length-value (TLV) objects, and the LSP is in essence a list of them describing a single router. Each router starts with its own LSP, determines how it will reach its neighbors, and then their neighbors, and so on until it has figured out how to reach every router in the network (including LANs, which are modeled as virtual routers called pseudonodes). Along the way, it also discovers that routers advertise reachability of various kinds: "if you have a route to me, I can deliver data to <>", where <> might be an AppleTalk subnet, an IPv4 subnet (RFC 1195), an IPv6 subnet (RFC 5308), or any of a number of other things. RFC 5308 specifies such a TLV, which specifies an IPv6 prefix with some attributes like how it got into the network. It also specifies the ability to have sub-TLVs, TLVs that specify additional attributes for the larger TLV, although it doesn't define any. Those are for "future extension". Welcome to the future.

So, from my perspective, in the routing protocol, we need to specify sub-TLVs for any additional attributes, such as source prefixes, that we want to include, and IS-IS has given us that capability. What's necessary next is a FIB that the routes can be stored into. I'll come to that later.

Of course, IS-IS isn't going to be very useful in homenet without a way to allocate prefixes to LANs. draft-baker-ipv6-isis-automatic-prefix is in essence draft-ietf-ospf-ospfv3-autoconfig for IS-IS. Shoot me.

But we wanted to do this in OSPF. Here, I have a problem. OSPF is designed with fixed LSAs, not extensible LSAs, so adding an attribute to an LSA is difficult without fundamentally changing the LSA. I started by defining a set of extensible LSAs in draft-baker-ipv6-ospf-extensible; they are direct counterparts to RFC 5340's LSAs, and intended to be backward-compatible with them. I'm not stuck on exactly that approach; I have since found that an extensible LSA was considered and set aside by the working group in 2006/2007, in http://tools.ietf.org/html/draft-ietf-ospf-mt-ospfv3. Give me an approach that gives me the ability to add a sub-TLV to an OSPF LSA such as I did for IS-IS, and I'm pleased as punch. draft-baker-ipv6-ospf-dst-src-routing is a direct counterpart to draft-baker-ipv6-isis-dst-src-routing, and draft-baker-ipv6-ospf-dst-flowlabel-routing is a direct counterpart to draft-baker-ipv6-isis-dst-flowlabel-routing; they add attributes to an extensible LSA. The theory is the same.

Which brings us, I suppose, to the FIB. There are many ways a FIB can be designed, and I would expect every vendor to do it their own way; this is not a matter for standardization. However, to have the discussion, it seems important to at least mention some possible approaches. In appendices in the drafts, I mention two. They are far from the only two; they are two.

Mark felt it was important to specifically state how these might play with the Waikato source address routing extensions in Linux, so I addressed that. I generalized it a little bit; there is a trade-off, and I wanted to comment on it. The premise in Waikato is that one identifies the source prefix and uses that to select a destination FIB. In terms of writing code quickly, that's a reasonable approach; the FIB itself is already designed, the question is how to have more than one of them. My question is how many FIBs one might have, and what memory impacts that might imply. In a generalized model, one could imagine having quite a number of FIBs. But now, what routes do we expect to put into those FIBs? I expect that, at least in a small-to-medium sized network, one has some number of PA prefixes and as many egress default routes; most of the routes, whether few or many, are traditional destination routes within the domain. So, I can have a FIB per PA prefix, put egress default routes only into the FIBs for their source prefixes, and put every single destination route into each FIB. That results in a potentially-large number of FIBs, each of which contains mostly-identical information. If memory is a concern, I throw out a second option; I could have a destination-only FIB and a set of PA prefix-specific FIBs, which are usually relatively small, perhaps only a single route. When you do a route lookup, you look in both the destination-only FIB, which will find local routes, and the PA-relevant FIB, which will get you a default route, and use the one that is most specific.

That said, I think there is a much simpler approach, although it may take some time to explain. A PATRICIA trie is a structure originally discussed in 1968 for searching through ASCII text, and used in route tables. It allows you to build a set of discontiguous bit strings, and do a radix search through the trie. For the details, I'll refer you to discussions of PATRICIA tries on the web and the appendix in the document. 

So there are at least two possible FIB approaches; there are no doubt other approaches, and they might be better. To each his or her own.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Feb 2013 09:41:42 +0900

On Fri, Feb 22, 2013 at 4:23 AM, Fred Baker (fred) <[email-masked]> wrote:

> This is that separate email. As I start, may I make the most direct
> possible apology to my colleagues with other approaches. I'm going to say
> that I think you're "wrong", and say why. That is in the spirit of open
> discussion in which we have a technical disagreement. BTW, you should be
> aware that I have a fair set of people who are telling me I'm wrong as
> well, hopefully in the same spirit. Some of them are pretty irritated with
> me, and I have gotten irritated with them.
>

For what it's worth, as as a co-author of draft-troan-homenet-sadr-00, I
don't think there is a disagreement. The draft cites your work, because we
(or at least, I) think that the correct approach is in fact one where the
routing protocol passes around source+destination routing pairs.

The reason why the draft also proposes a simplified version of SADR that
integrates with prefix assignment protocol is that it's possible to
implement this without having to make substantial changes to OSPF.
Extending the routing protocols will be a long and possibly hard road, and
we feel that the group should at least consider the possibility of an
approach with better time-to-market and lower barrier to implementation -
especially since the alternatives being proposed are hierarchical DHCPv6 PD
and NPT66. The risk is that we make the perfect the enemy of the good and
we end up with NPT66, which means that we will have thrown away the chance
for end-to-end IPv6 connectivity and will have to build apps in IPv6 just
as we did in IPv4 - forever trying to guess what their addresses are, which
magic packet incancation will work, and which third-party server is the
best to relay packets through.

On the OSPF vs. IS-IS choice... well, if we had an implementation of ISIS
that could run on home networking devices, or if there was at least one on
the horizon, things would be very different.

---

From: David Lamparter <[email-masked]>
Date: Fri, 22 Feb 2013 04:04:49 +0100

> routing protocol passes around source+destination routing pairs.

+1

> best to relay packets through.

I have the fear that this will come around and do some ass-biting.  This
is a very subjective opinion of course, but I think it's reasonable to
assume that if this ships, it will stick around for years to come.  Lots
of people never update their CPEs (which is obviously bad and leads to
security problems, but we can't will that away...)  So, even if we later
go the "full-blown" way, we'll have to be interoperable with those
will-be Simple SADR relicts.

> the horizon, things would be very different.

There are in fact 2 implementations of IS-IS that may run on home
networking devices, in different states.

- BIRD seems to be interested in adding IS-IS due to interest from SPs.
  A branch exists, but not much progress has been made:
  [https://redmine.labs.nic.cz/projects/bird/repository?utf8=%E2%9C%93&rev=isis]

- (Disclaimer: I'm the Quagga maintainer)
  Quagga has had bad IS-IS support for a long time.  It has been
  overhauled and that overhaul was integrated in April 2012.  I've had
  the pleasure of declaring it "beta" in the last release, although
  we're still squashing bugs here and there.
  [http://savannah.nongnu.org/forum/forum.php?forum_id=7501]

Both BIRD and Quagga are readily available on OpenWRT derivatives and
should run reasonably fine on limited-resources CPE devices.  Both are
released under the GNU GPL (v2+).

-David

---

From: Ray Bellis <[email-masked]>
Date: Fri, 22 Feb 2013 08:48:52 +0000

>  [https://redmine.labs.nic.cz/projects/bird/repository?utf8=%E2%9C%93&rev=isis]

Ondrej Filip tells me that this is being worked on again, targeted for release in 2013Q2

Ray

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2013 08:56:13 +0000

On 21/02/2013 19:23, Fred Baker (fred) wrote:
...
>>  "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 17-Feb-13

To get this on the record, I have serious doubts whether the use
of the flow label suggested in these drafts is compatible with
the current flow label standard (RFC6437). I think this is
separable from the general approach, so I'd rather defer
discussion until the general approach has been debated.

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Fri, 22 Feb 2013 10:52:40 +0100

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 22 Feb 2013 19:17:04 +0900

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

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

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

> dumb hosts should not be connected to dual routers from competing

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

---

From: David Lamparter <[email-masked]>
Date: Fri, 22 Feb 2013 12:48:22 +0100

> loops. We should document that clearly and find out how to avoid it.

[quoting the earler loop sketch for convenience]
| If 4. is not given, this scenario will lead to a loop:
| All links assumed at equal cost, r2 does not support simplified SADR,
| R1,R3,R4 do.
|
| ISP_A, pfx_A ::/0             ISP_B, pfx_B, ::/0
|  |                            |
| R1 ------ r2 ------ R3 ------ R4
|  |
| Host
|
| Host now selects an address from pfx_B to reach some site on the
| internet.  R1 forwards to r2 because the ::/0 from R4 is more specific
| on the source.  r2 forwards back to R1 because it didn't consider source
| specific-ness and just went by lower cost...
[/quote]

Since I complained about this earlier, I feel obliged to throw possible
approaches around.  I'm excluding the prefix-assignment-integrated
approach to distributing SADR routing information since that would
supposedly by design require all participants to support SADR.

For both "simple" and "full-blown" OSPFv3 the following loop/interop
mechnisms come to my mind:

1. refusing adjacencies between SADR and non-SADR routers.
   Easily implemented with a Hello bit, this is the crowbar solution.
   Quite sufficient for homenet I guess, but probably less acceptable
   for anything else.

2. flagging SADR support in router LSAs/LSPs.
   Provides enough information to avoid loops.  Three things can be done
   with this information:

 2a. install null/reject routes for paths that cross non-SADR routers.
     Provides adequate failure semantics, instead of looping packets
     around we get an ICMP unreachable.  Easy to implement.
     Downside: if there really is a non-SADR router, "not working" is
     now a state that is part of the result set of the dynamic route
     calculations.  Users (and admins) probably do not expect this.

 2b. calculate SPF around non-SADR routers
     Gets us a working network, but at a cost: there may now be 2
     different paths to reach some faraway router, one for SADR-routed
     packets and a different one for non-SADR packets.  Depending on how
     the router performs its SPF calculations, this can be hard to
     implement correctly - it's essentially a very narrowly and exactly
     specified case of multitopology routing.

 2c. on encountering non-SADR routers, figure whether they'll do the
     right thing with the packet.
     ... complicated and of questionable use IMHO.  Just listing this
     for completeness.

2a and 2b can be mixed with each other; packets will get passed along by
2a-type routers until they get discarded at a 2b-type router.

My personal opinion at this point is that 2a and 2b should both be
specified, with a requirement to indicate support level in the router
documentation.  We're unlikely to encounter normal OSPFv3 speakers in a
plain "production/final" homenet, so they could take the easy way.  If
this gets implemented on routers for enterprise use, I'd expect 2b
behaviour.

(With the Baker OSPF/ISIS SADR specs quite independent from homenet as
they are right now, I think getting homenet-only solutions in those is
an unwise idea;  homenet optimisation possibilities like allowing
fallback to 2a on the other hand should be acceptable.)

-David

---

From: Ray Hunter <[email-masked]>
Date: Fri, 22 Feb 2013 13:53:20 +0100

> Lorenzo Colitti <mailto:[email-masked]>
> 22 February 2013 11:17
> On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> 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.
> 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.
>
> 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.
>
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.
> 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:[email-masked]>
> 22 February 2013 10:52
> ------------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Fri, 22 Feb 2013 14:06:41 +0100

Ray,

[...]

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

if there is no interconnect between R1 and R2, then the host has two
interfaces connected to two separate connections. then I can't see how
that can be solved in the network. my assumption is that all homenet routers
must be connected (I see I haven't stated that anywhere, but that should be added).

> provider2 with router2 for off link destinations e.g. to a Provider2/56

in your case it will RFC6724, rule 5.5

> If not, then wait for an ICMPv6 redirect to be told to use the other router.

you would only get that if the routers were connected of course.
whichever came first, you'd either get a unreachable code 5 (wrong source)
or ICMP redirect, or the router would just forward the packet to second router.

> each provider, with the correct 1st hop router dependent purely on the

I agree, there is nothing useful the host learns from an ICMP redirect here.

> with RA PIO & default router selection?

for directly connected hosts, we have that already. note that only applies when
hosts are connected to the border router.

> information options at all AFAIK.

again, that's rule 5.5 (which is somewhat weak) in 6724.

> ICMPv6 redirect? [Assuming R1 is managed by Provider 1 and R2 is managed

yes, I think we probably would want to say that.

>           routing protocol on its WAN interface.

but 6204 does support more specific routes in RAs (RFC4191?)

>> If I have other detailed comments on the individual drafts, I'll come

cheers,
Ole

---

From: Ray Hunter <[email-masked]>
Date: Fri, 22 Feb 2013 14:46:43 +0100

> Ole Troan <mailto:[email-masked]>
> 22 February 2013 14:06
> Ray,
>
> [...]
>
Doh! Thanks. Agree it'll work, but possibly not for all current
implementations.
> <snip>

Yes, on the LAN interface in requirement L3, purely for advertising ULA
and delegated prefixes.

RFC4191 isn't excluded on the WAN for learning upstream prefixes (from a
walled garden), but it's also not explicitly required either.
Perhaps it should be. I'm not 100% convinced of the use case though.
Currently only default route(s) are mentioned on the WAN interface.
 
<snip>

---

From: Chris Donley <[email-masked]>
Date: Fri, 22 Feb 2013 15:21:52 +0000

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 21, 2013 5:41 PM
To: Fred Baker <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> Group" <[email-masked]<mailto:[email-masked]>>, "Abhay Roy (akr)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [homenet] Egress Routing Discussion: Baker model

Extending the routing protocols will be a long and possibly hard road, and we feel that the group should at least consider the possibility of an approach with better time-to-market and lower barrier to implementation - especially since the alternatives being proposed are hierarchical DHCPv6 PD and NPT66. The risk is that we make the perfect the enemy of the good and we end up with NPT66,

[CD] There's another alternative we've added to eRouter (see draft-grundemann-homenet-hipnet) - hierarchical DHCPv6 without NPT66.  For multihoming, you can do source/dest routing at the CER(s), if necessary, not every router.  No routing protocol required, and no v6 NAT.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Feb 2013 17:41:43 +0000

inline 

> this gets implemented on routers for enterprise use, I'd expect 2b

So you want the non-SADR routers to implement a null route, and the SADR routers to route around the non-SADR routers.

I'm scratching my head on how the un-updated routers would know to install a null route if they don't understand the information. 

I do think it would be straightforward to add a flag to the Hello indicating that they understand such updates, and refusing to neighbor with a router that doesn't. We have done that for other features. That does mean that adding a router to an area that understands the updates forces an update to all of the routers in an area, which could be a pain when upgrading. 

Setting a flag in the Router LSA indicating willingness to handle these routes is possible, but takes us in the direction of topological routing. My problem with approaching it as a topology is the implied management overhead; we need to know whether to include any given router or link in a given topology, and where we might have advertised topology-specific metrics in RFC 4915, we now want to infer that from a capability flag. ick.

---

From: David Lamparter <[email-masked]>
Date: Sat, 23 Feb 2013 04:04:34 +0100

also inline

On Fri, Feb 22, 2013 at 05:41:43PM +0000, Fred Baker (fred) wrote:
> So you want the non-SADR routers to implement a null route, and the
> SADR routers to route around the non-SADR routers.

No - sorry for not wording this clearly enough.

I want SADR routers to notice that they've hit a non-SADR router in
their SPF calculation.  And if they do, the SADR routers can either
install a null route (and keep topological sanity, flagging the route
under consideration down as "sorry no can do"), or go the alternate
topology way.

> I'm scratching my head on how the un-updated routers would know to
> install a null route if they don't understand the information.

They don't, indeed.

> I do think it would be straightforward to add a flag to the Hello
> indicating that they understand such updates, and refusing to neighbor
> with a router that doesn't. We have done that for other features. That
> does mean that adding a router to an area that understands the updates
> forces an update to all of the routers in an area, which could be a
> pain when upgrading. 

I think moving this flag to the router LSA is under all circumstances
preferable over this.  With the null route variant, it gives a painless
upgrading path that keeps plain-old destination routing working; SADR
can then be put into use when the relevant routers have the support.

> Setting a flag in the Router LSA indicating willingness to handle
> these routes is possible, but takes us in the direction of topological
> routing. My problem with approaching it as a topology is the implied
> management overhead; we need to know whether to include any given
> router or link in a given topology, and where we might have advertised
> topology-specific metrics in RFC 4915, we now want to infer that from
> a capability flag. ick. 

This is exactly why the SADR routers can instead go install a null
route, the only thing needed there is checking whether any router on the
calculated path doesn't support SADR.

FWIW, I think the double topology idea is not completely out of whack,
though admittedly complicated and complex.  The semantics are reasonably
well-defined, it boils down to bifurcating into exactly two topologies,
one normal and one SADR.  I'm not particularly keen or tacked down on it
though.

-David

P.S.: I can write this up in spec form if desired, I'm relatively new to
IETF and have no idea how this works and all.  Shall I put some text
together for the null route variant and throw it in here?  That would
as a side effect make it easier to evaluate the idea, I think.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 23 Feb 2013 06:36:24 +0100 (CET)

> must be connected (I see I haven't stated that anywhere, but that should be added).

But CE1 and CE2 share an interface in this case (the LAN). Shouldn't they 
be able to observe each others RA packets and from them discern what 
source addresses should go where? If CE1 receives packets from sources 
that is not from any address that CE1 has sent out RAs or DHCPv6-PD 
subdelegated from, then it's pretty obvious that these packets should not 
go out its default route because they're going to get dropped by ISP1 uRPF 
anyway. If it sees another router advertising those addresses on the LAN 
(or actually any addresses in case there are only two routers), then it 
should send the packets there.

I know this doesn't solve other topologies, but in this perticular case it 
should be doable (but requires new functionality in the routers, but the 
hosts do not need any new functionality).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Feb 2013 09:50:50 +0900

On Fri, Feb 22, 2013 at 10:06 PM, Ole Troan <[email-masked]> wrote:

> that can be solved in the network. my assumption is that all homenet
> routers must be connected (I see I haven't stated that anywhere, but that
> should be added).
>

Do we really need this?

When I originally put together the strawman it seemed to me that there are
only two cases: either the two border routers have a path to each other, or
they don't. If they do not have a path to each other, then the host cannot
be connected to both routers using the same interface - because if it is,
it's a broadcast interface and those two routers are also connected to each
other.

Should we write this in the draft?

> in your case it will RFC6724, rule 5.5

You don't need to invoke RFC 6724 for this. RFC 3484 (prefer outgoing
interface) is enough. We should put this in the draft though.

> or ICMP redirect, or the router would just forward the packet to second

Please let's not design something that requires ICMP redirects to work. It
will be slow and unreliable.

> again, that's rule 5.5 (which is somewhat weak) in 6724.

3484 rule 5 too, right? Or not?

---

From: Ray Hunter <[email-masked]>
Date: Mon, 25 Feb 2013 09:25:42 +0100

> 25 February 2013 01:50
> On Fri, Feb 22, 2013 at 10:06 PM, Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     that can be solved in the network. my assumption is that all
>     homenet routers must be connected (I see I haven't stated that
>     anywhere, but that should be added).
>
>
> Do we really need this?
>
Actually I meant a connection between 2 routers higher up the topology
i.e. not one where the only common connection between CER1 and CER2 is
also shared with (local) end hosts on the same LAN. But the discussion
has gone the right way anyway.
> When I originally put together the strawman it seemed to me that there
> are only two cases: either the two border routers have a path to each
> other, or they don't. If they do not have a path to each other, then
> the host cannot be connected to both routers using the same interface
> - because if it is, it's a broadcast interface and those two routers
> are also connected to each other.
>
Figure 2 of the architecture is the problematic one, where there are end
hosts that share the only connection between 2 CERs (from competing ISPs).

The end hosts do not share the same information as the 2 routers
(the end hosts ignore routing, and the PIO sent by the 2 CERs are
non-overlapping, as they are configured by 2 independent ASs).
> interface) is enough. We should put this in the draft though.
No. From the hosts perspective, SA & SB are on the same interface.
> Please let's not design something that requires ICMP redirects to
> work. It will be slow and unreliable.
>  
Agreed.
> 3484 rule 5 too, right? Or not?
Nope. You'd need the updated version of address selection (RFC6724) rule
5.5. which binds SA to next hop, rather than outbound physical interface.
So this might be an issue with existing implementations, and those which
do not track which prefix assignment was learned from which next hop.

An alternative would be that CER1 learns prefixes from CER2, and
configures up addresses from the competitor ISP on its own router,
(potentially accepting a candidate default route too if its own WAN link
goes down), which might be problematic from a management and operations
perspective e.g. if CER1 is also providing ISP1 specific services like
TV or telephony.

Which is why I've raised concerns about the definition of the Homenet
border in the architecture document.
This never came into play in 6204 (single router, single AS)
> 22 February 2013 13:53
> 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.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 25 Feb 2013 17:47:57 +0900

> non-overlapping, as they are configured by 2 independent ASs).

Maybe I don't understand the problem.

You're talking about the figure in
http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.2.2.2 ,
right? And your concern is: "what happens if H1 sends a packet with source
address SA (assigned from ISP A) to CER2"?

The answer is that at CER2, the packet will not match the default route to
ISP B because the source address doesn't match. However, it matches the
default route to ISP A announced by CER1. So CER2 forwards the packet to
CER1, and CER1 sends it out to ISP A. Yes, it's an extra IP hop, but the
packet gets to where it needs to go. No?

---

From: Ray Hunter <[email-masked]>
Date: Mon, 25 Feb 2013 10:49:56 +0100

> 25 February 2013 09:47
> On Mon, Feb 25, 2013 at 5:25 PM, Ray Hunter <[email-masked]
> http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-3.2.2.2
> , right? And your concern is: "what happens if H1 sends a packet with
> source address SA (assigned from ISP A) to CER2"?
yes. Bigger concern is that the borders of Homenet seem fuzzy, but I've
expressed that elsewhere.
>
> The answer is that at CER2, the packet will not match the default
> route to ISP B because the source address doesn't match. However, it
> matches the default route to ISP A announced by CER1. So CER2 forwards
> the packet to CER1, and CER1 sends it out to ISP A. Yes, it's an extra
> IP hop, but the packet gets to where it needs to go. No?

Thanks.

That'd work (provided your draft updates/clarifies RFC2461 Section 8.2
to cover SADR so an ICMP redirect is not sent in this case, and provided
BCP38 filters of RFC6204 requirement S-2 have been applied to the WAN
interface, not the LAN).

It would also seem to suggest that if CER1 and CER2 LAN interfaces are
within the homenet boundary, that if the WAN link to CER2 failed, then
CER2 would also learn a default route from CER1 (and vice versa), and
any telephony traffic or management traffic generated by CER2 would also
be sent to CER1 and ISP1 if it had a source address of ISP1?

Suggesting ISP specific services and applications should only bind to
source addresses native to their own ISP?

<snip>