RE: multi-homing for provider-assigned IPv6 addresses

[Chris Bowers <[e-mail]>]

Fred,

I don't follow the argument made in the previous email against the proposal to use a simplified form of dest/src routing.  The argument seems to assume that the destination prefix is completely ignored, which is not the case.  With this proposal, a packet is first routed based on longest match for destination prefix.  The source prefix is only considered when the destination route lookup reaches ::/0.  Therefore, communication within the customer network works as expected since there will be destination prefix matches corresponding to the customer network.

In order to understand all of the details, I created an example topology below that I believe covers most of the relevant PA multi-homing scenarios.  The customer site connects using four different ISPs.  ISP1 just offers Internet connectivity.  ISP2 just offers a service corresponding to destination address B2.  ISP3 offers both Internet connectivity and a service corresponding to B3.  ISP4 offers internet connectivity and a service corresponding to B4.  The customer site has a provider-assigned subnet from each of the ISPs (A1, A2, A3, and A4).  The customer site has two LANs.  LAN-Y (with hosts H21 and H22) is directly connected to R1, R2, and R3.  LAN-X (with hosts H31 and H32) has to go through a routed hop (R7 or R8) to reach R1, R2, or R3.  The only way for any of the hosts to reach R4 (and ISP4) is through R8.  The hosts on LAN-X have addresses from a subnet of each of the provider assigned block ( subnets A1x, A2x, A3x, and A4x), while the hosts on LAN-Y have addresses from a subnet of each of the provider assigned block ( subnets A1y, A2y, A3y, and A4y).  B0 represents a destination address somewhere on the Internet unrelated to any of the ISPs.

                                             -----------------
   LAN-X        LAN-Y          ,-----.      /                 \
          +--+         +--+  ,'       `.   :                   :
       +--+R7+-----+---+R1+-+   ISP 1   ---+--                 :
       |  +--+     |   +--+  `.       ,'   :                   :
   H31-+       H21-+           `-----'     :   The Internet    :
       |           |           ,-----.     :                   :
   H32-+  +--+ H22-+   +--+  ,'       `.   :                   :
       +--+R8+-----+---+R2+-+   ISP 2   )  :                   :
          ++-+     |   +- +  `.       ,'   :                   :--B0
           |       |           `--+--'     :                   :
           |       |              |        :                   :
           |       |              B2       :                   :
           |       |                       :                   :
           |       |           ,-----.     :                   :
           |       |   +--+  ,'       `.   :                   :
           |       +---+R3+-+   ISP 3   ---+---                :
           |           +--+  `.       ,'   :                   :
           |                   `--+--'     :                   :
           |                      |        :                   :
           |                      B3       :                   :
           |                               :                   :
           |                   ,-----.     :                   :
           |           +--+  ,'       `.   :                   :
           +-----------+R4|-+   ISP 4   ---+---                :
                       +--+  `.       ,'   :                   :
                               `--+--'     :                   :
                                  |         \                 /
                                  B4         -----------------

We consider how H31 and H21 reach various destinations.  The destinations to consider are B0, B2, B3, B4, H32 and H22.

First, we look at the information that the routers distribute among themselves using an IGP.

R1 originates a route for (D=::/0, S=A1).

R2 originates a route for (D=B2).

R3 originates routes for (D=::/0, S=A3) and (D=B3).

R4 originates routes for (D=::/0, S=A4) and (D=B4).

R7 and R8 originates routes for (D=A1x), (D=A2x), (D=A3x), and (D=A4x), and (D=A1y), (D=A2y), (D=A3y), and (D=A4y).

Next, we look at the information that the routers distribute to hosts on the LAN using the Neighbor Discovery protocol.  From Prefix information Options (PIOs) in Router Advertisements, hosts on LAN-X learn that A1x, A2x, A3x, and A4x are on-link, while hosts on LAN-Y learn that A1y, A2y, A3y, and A4 are on-link.

A router indicates that it acts as a default router by advertising a non-zero Router Lifetime in a Router Advertisement. Or that it doesn't act as a default router by advertising a Router Lifetime value of zero.  A reasonable choice in this network would be to have R1 and R3 advertise that they are default routers on LAN-Y and have R7 and R8 advertise that they are default routers on LAN-X.

It appears to me that with just the information described above (that is, destination routes and simplified dest/source routes distributed among the routers, and the Router Advertisements on the LANs indicated default routers),  packets from H31 and H21 can reach all six destinations, assuming the host uses an acceptable source address for the given destination.  However, the next-hop chosen by the host may not be optimal.

For example, for a packet to get from H21 to H32, it may take the path H21->R1->R7->H32, instead of the more direct path H21->R7->H32.  However, this situation can be improved using existing mechanisms by having R7 advertise Route information Options (RIOs) for prefixes A1x, A2x, A3x, and A4x into LAN-Y so that H21 can choose R7 as its next-hop to directly reach H32.

draft-ietf-6man-multi-homed-host-06 points out an example of a host making a sub-optimal choice of next-hop related to multi-homing.  In the topology above, when H21 sends a packet with src in A1y and dest = B0, it could choose next-hop R3.  This would require R3 to forward the packet to R1 based on the fact that R1 originated an IGP route for (D=::/0, S=A1).  draft-ietf-6man-multi-homed-host-06 proposes to have hosts use the PIOs in Router Advertisements to make better choices of next-hops.  Assuming that only R1 advertises a PIO for A1y, then H21 can use that information to send a packet with src in A1y to R1 as its default next-hop.  This seems like a reasonable optimization.

I would like to make two observations about the analysis above.  First, the solution proposed in draft-ietf-6man-multi-homed-host-06 is consistent with the proposed simplified form of dest/source routing.  draft-ietf-6man-multi-homed-host-06 only allows one to choose a default router based on source prefix.  It doesn't provide a way to pair an arbitrary RIO with a source prefix.

Second, in the solution described above, which would seem to cover most multi-homing scenarios, the routes exchanged between routers using the IGP do not require source addresses to be paired with arbitrary destination prefixes.  The simplified form of dest/source routing (only pairing a source prefix with the default destination route) is sufficient for the routing done by the routers.

At this point, I have not seen a PA multi-homing scenario that I believe would benefit from using arbitrary dest/source routing.  Instead, I think that PA multi-homing scenarios can be efficiently addressed by simplified dest/source routing.  To be clear, this is not an argument against the mechanism in draft-ietf-6man-multi-homed-host-06. Instead, it is an argument against the mechanism in draft-baker-ipv6-isis-dst-src-routing-04, which specifies a general mechanism for pairing arbitrary destination prefixes with arbitrary source prefixes. I think that a simplified mechanism that only pairs source prefixes with the default destination route in the IGP would work just as well for PA multi-homing scenarios.

If there is an error in the above analysis or there is a useful PA multi-homing scenario not covered by the above example, then I look forward to discussing it.

Thanks,
Chris


From: Fred Baker (fred) [mailto:[e-mail]]
Sent: Monday, March 28, 2016 2:47 PM
To: Chris Bowers <[e-mail]>
Cc: [e-mail]
Subject: Re: multi-homing for provider-assigned IPv6 addresses


On Mar 27, 2016, at 9:03 AM, Chris Bowers <[e-mail]<mailto:[e-mail]>> wrote:

Fred,

I would like to better understand the particular use case offered as a counter-example.  One version of this counter-example is described in Section 2.3 of draft-baker-rtgwg-src-dst-routing-use-cases-01 (Specialized Egress Routing).  I have copied figure 3 from that draft below.

                                                ,-------.
                                             ,-'         `-.
             ,---.            ,-----.      ,'               `.
            /     \    +-+  ,'       `.   /                   \
           /       +---+R+-+   ISP 1   --+---                  \
          /         \  +-+  `.       ,' ;                       :
         ; Customer  :        `-----'   |       The Internet    |
         | Network   |        ,-----.   :                       ;
         :           ; +-+  ,'       `.  \                     /
          \         +--+R+-+   ISP 2   )  \                   /
           \       /   +-+  `.       ,'    `.               ,'
            \     /           `--+--'        '-.         ,-'
             `---'               |              `-------'
                           Some specialized
                              Service

       Figure 3: Egress Routing with a specialized upstream network


If a customer network homed to ISP1 and ISP2 (with PA prefixes S1 and S2) needs to reach a destination prefix (D2) associated with a service offered by ISP2, then the customer network can route all traffic with destination address in D2 to ISP2 using existing destination-based routing.

Yes, if the packet first goes through a router that is not depicted in the diagram (I didn't describe the interior of the customer network, which could be as simple as a LAN and as complex as you care to imagine). If the only routing is done by the host itself, the packet will go to the router the host considers to be its default router, which is pretty likely to be the other router in this example. That is the subject of draft-ietf-6man-multi-homed-host. Note, BTW, that the picture is essentially NTT's BFLETS configuration, with the exception that (as I understand it) the two ISPs are served by the same managed router, deployed by NTT and configured to route appropriately.


Therefore, it seems to me that pairing a source prefix with an arbitrary destination prefix is not required to support the Specialized Egress Routing use case in draft-baker-rtgwg-src-dst-routing-use-cases-01. In any case, it would be useful to come to agreement about what is required to address the Specialized Egress Routing use case described in draft-baker-rtgwg-src-dst-routing-use-cases-01.

I'm happy to discuss that. I think it misses the point, however. If the use case described isn't a good one, let's think of a better use case, perhaps one that doesn't involve a PA prefix from an ISP. Perhaps the biggest issue with your proposal, which was to take all traffic using a given source prefix to an appropriate egress router, is that it precludes the use of the address to communicate within the customer network. All traffic would dogleg through the egress router, and I'm not sure I see how packets get from that router to a point inside without looping. There has to be a way to prefer to destination-address route some traffic and source-address route some other traffic. The simplest way I can think of is to use both addresses in every route lookup, interpreting a traditional destination route as a source/destination route from ::/0 to the stated destination, or (if there are multiple route tables by source prefix) duplicate the destination route table in each.

If instead the counter-example use case described below is different from Specialized Egress Routing use case in draft-baker-rtgwg-src-dst-routing-use-cases-01, it would be useful to describe that use case in more detail so that we can evaluate it more thoroughly.

I'll take a look at that. Of course, I can't update the draft until next week.

Thanks,
Chris

-----Original Message-----
From: Fred Baker (fred) [mailto:[e-mail]]
Sent: Thursday, March 24, 2016 11:37 PM
To: Chris Bowers <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: multi-homing for provider-assigned IPv6 addresses


> On Mar 24, 2016, at 9:32 PM, Fred Baker (fred) <[e-mail]<mailto:[e-mail]>> wrote:
>
>
>> On Mar 24, 2016, at 4:34 PM, Chris Bowers <[e-mail]<mailto:[e-mail]>> wrote:
>>
>> It seems to me that most use cases for ipv6 multi-homing with provider-assigned addresses only need to route based on source address when the destination prefix is the default route.  So why not require that source prefixes can only be paired up with the default destination prefix ::/0?
>
> When what one has in mind is an egress route, that probably makes sense. However, it precludes an entire class of use cases mentioned in the use case draft. Why do that?

Let me give you an obvious variant. Imagine, if you will, that I have a PA prefix from each of N ISPs, and therefore a default route to each of N ISPs. Imagine also that I have a particular prefix that I would like to route through via a given one of those N ISPs, in the special case that I happen to have been smart enough to use that source prefix. So now I have N+1 source/destination routes - unless you tie it to default routes.

A premature optimization usually breaks things...