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:[email protected]]
Sent: Monday, March 28, 2016 2:47 PM
To: Chris Bowers <[email protected]>
Cc: [email protected]
Subject: Re: multi-homing for provider-assigned IPv6 addresses
On Mar 27, 2016, at 9:03 AM, Chris Bowers
<[email protected]<mailto:[email protected]>> 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:[email protected]]
Sent: Thursday, March 24, 2016 11:37 PM
To: Chris Bowers <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: multi-homing for provider-assigned IPv6 addresses
> On Mar 24, 2016, at 9:32 PM, Fred Baker (fred)
> <[email protected]<mailto:[email protected]>> wrote:
>
>
>> On Mar 24, 2016, at 4:34 PM, Chris Bowers
>> <[email protected]<mailto:[email protected]>> 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...
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
