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
