RE: multi-homing for provider-assigned IPv6 addresses

[Chris Bowers <[e-mail]>]

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.  R for ISP2 would originate a route for D2.  This route for D2 will be used throughout the customer network instead of the default destination route originated by R for ISP1, due the longest prefix match rule.  The counter-example assumes that the host is smart enough to use the source prefix S2 when sending packets to D2, so it will meet the requirement that packets using the special service MUST use the special service's source and destination addresses.



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.



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.



Thanks,

Chris



-----Original Message-----

From: Fred Baker (fred) [mailto:[e-mail]]

Sent: Thursday, March 24, 2016 11:37 PM

To: Chris Bowers <[e-mail]>

Cc: [e-mail]

Subject: Re: multi-homing for provider-assigned IPv6 addresses





> On Mar 24, 2016, at 9:32 PM, Fred Baker (fred) <[e-mail]> wrote:

>

>

>> On Mar 24, 2016, at 4:34 PM, Chris Bowers <[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...