Subject: Re: [Idr] [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case

From: Mach Chen <[email-masked]>
Date: Wed, 17 Jul 2013 09:59:48 +0000

Hi Russ,

Thanks for bringing up this discussion!

Please see my reply inline...

Best regards,
Mach

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
> White
> Sent: Monday, July 15, 2013 8:45 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an
> I2RS Use Case
> 
> Y'all:
> 
> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase might
> provide a solid use case to add to one of our use case drafts in I2RS. The
> basic idea is this:
> 
> Rather than advertising multiple routes using something like add-paths to
> optimize traffic flow between eBGP edges, why not just have the RR advertise
> only the route that's best from each eBGP speaker's perspective? Now, I have
> a long standing desire to see it implemented. OTOH, even if add-paths is
> implemented, there is the issue of which set of paths to send to the RR
> clients in any given situation. So I don't see
> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to
> add-paths, but rather a complimentary idea.

I agree if the RR wants to advertise more than one routes to the clients. 

> 
> But how is the RR to know which path to send to which RR client? This is
> where i2rs seems to fit. If the RR was attached to a controller that had
> visibility into the layer 3 routing table at each RR client, that
> information could be used to determine which path to send where. The RR
> could also calculate the best path from the perspective of each RR client

Yes, this is one possible way to achieve it. Alternate way is that the RR is the "controller" or part of a controller, it has not only the visibility into the layer 3 routing table at each client, but the topology and other related information of the network. Then the RR can compute a path for a specific source and destination pair, just like the traffic engineering, and then it advertises the relevant routes to clients though the existing route reflection mechanisms. 

> --but even though SPF is trivial to run, there are still problems with this
> solution. First, you can't run SPF for a router that's not in your flooding
> domain. Second, you can't take into account any local policies configured on
> the router you're running SPF from the perspective of.

The RR and the routers/clients do not have to be in the same flooding domain, the RR can establish IGP multiple adjacencies with domains (per adjacency per domain) or use BGP-LS to collect the topology information.
 
Regarding to the local policies, if want the RR the consider the local policies, there have to be some mechanisms to collect the local policies and just configure it on the RR. 

> 
> Hence --just use i2rs to peek into the RR clients local routing table, and
> send the client the right BGP route(s) as indicated (using add-paths to
> include more than one path if needed, for load sharing or the like).
> 
> This would probably fit better into the BGP use cases draft, rather than the
> one I'm co-authoring --OTOH, I thought we were merging these two into a
> single use cases draft covering all the "first line" use cases i2rs would
> like to cover.
> 
> Thoughts?
> 
> :-)
> 
> Russ
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Jul 2013 15:56:16 +0200

Hi Mach,

I have read your draft. I find nothing there which is not already
solved by IDR WG document
http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-05

The status of this WG document is pending two implementations.

If you see anything technically missing in this draft possibly along
with draft-varlashkin-bgp-nh-cost-02 let's discuss.

Best regards,
R.

---

From: Mach Chen <[email-masked]>
Date: Mon, 22 Jul 2013 06:20:36 +0000

Hi Robert,

Many thanks for spending time to read the draft and your comments!

If I understand the ORR and draft-varlashkin correctly, they both try to calculate (from the client's perspective) the best route that is from the client to destination/nexthop. 

But, just as Russ summarized, the use cases introduced in this draft (use case 1 and 2) require to calculate the route from the eBGP peer's perspective, hence to optimize the traffic flow between eBGP peers (between MANs). This seems not be solved by the ORR and draft-varlashkin. 

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> Raszuk
> Sent: Friday, July 19, 2013 9:56 PM
> To: Mach Chen
> Cc: Russ White; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase
> as an I2RS Use Case
> 
> Hi Mach,
> 
> > Yes, this is one possible way to achieve it. Alternate way is that the RR is the
> "controller" or part of a controller, it has not only the visibility into the layer 3
> routing table at each client, but the topology and other related information of the
> network. Then the RR can compute a path for a specific source and destination
> pair, just like the traffic engineering, and then it advertises the relevant routes to
> clients though the existing route reflection mechanisms.
> >
> > The RR and the routers/clients do not have to be in the same flooding domain,
> the RR can establish IGP multiple adjacencies with domains (per adjacency per
> domain) or use BGP-LS to collect the topology information.
> >
> > Regarding to the local policies, if want the RR the consider the local policies,
> there have to be some mechanisms to collect the local policies and just configure
> it on the RR.
> >
> >>

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 Jul 2013 12:35:26 +0200

Hello Mach,

> But, just as Russ summarized, the use cases introduced in this draft (use case 1 and 2) require to
> calculate the route from the eBGP peer's perspective, hence to optimize the traffic flow between
> eBGP peers (between MANs). This seems not be solved by the ORR and draft-varlashkin.

In the route reflection based networks eBGP peers are also RR clients.
The ORR draft allows you to choose the correct exit path for given
prefix based on set of criteria. Such criteria can be IGP metric based
or any other set of constrain as determined by the operator.

Now if your requirement is:

   The requirement
   would like this: the traffic between MAN1 and MAN2 is required to
   follow the path: E-A-B; and the traffic between MAN1 and MAN3 is
   required to follow the path: E-D-C.

then the correct way to solve it is to use either IGP Segment Routing,
MPLS-TE or BGP Vector Routing proposals.

I am of the strong opinion that the solution proposed in your draft to
steer traffic via customized IBGP P router's programming with hop by
hop different next hop setting is very problematic. BGP is not a right
protocol for IGP traffic steering. In your example:

   For example, for a path from Source 1 (S1) to Destination 1 (D1), if
   the computed path is: S1-A-B-C-D1, then the RR will distribute a
   route (D1) to C with the nexthop set to D1; a route (D1) to B with
   the nexthop set to C, and a route (D1) to A with the nexthop set to
   B, and finally the route (D1) will be distributed to S1 by A.

you only list steady state. At any IGP P node failure case you are to
again depend on your RR reprogramming selective nodes to stop traffic
drops and repair the intra-domain path.

Btw the difference of the above as compared with BGP Vector Routing
proposal http://goo.gl/qutBU is that upon the failure of any Vector
Node (signaled via the IGP) such node would not be considered and next
Vector Node (or final next hop) would be used as the next
encapsulation point. Your proposal does not seem to have such local
path repair ability.

Btw this is typical illustration where number of "SDN" folks who push
for massive centralization of everything do not realize a benefit of
having in each domain robust IGP transport and a BGP used as an
service overlay on top of it.

Best regards,
R.

> On Mon, Jul 22, 2013 at 8:20 AM, Mach Chen <[email-masked]> wrote:
>
> Hi Robert,
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 23 Jul 2013 09:12:22 +0000

Hi Robert,

> Sent: Monday, July 22, 2013 6:35 PM
> To: Mach Chen
> Cc: Russ White; [email-masked]; [email-masked]; [email-masked]; wangsb

Here the eBGP peers that I referred to are the eBGP speakers residing in other AS (for example, the eBGP speakers in the MANs other than in the Core network). So, these eBGP speaker should not be the clients of the RR. 

> MPLS-TE or BGP Vector Routing proposals.

You listed solutions are alternative ways to satisfy the above requirement, we had considered and discussed these potential solutions with some customers. Since these solutions will require either large network update(e.g., SR) or to totally change to a new deployment solution (e.g, MPLS-TE). To deploy these solutions to solve the above issue is not practice, at least for now or in near term. 

The idea of the RRTS proposed in the draft is try to avoid large network update or bringing significant new solution to the product network, with the idea of RRTS, most of the devices are not necessary to be updated. 

> drops and repair the intra-domain path.

The concept of RRTS is similar to MPLS-TE, the path is an End-2-End path, the RR is responsible for path calculation and distribute the routes to relevant routers. The different is that MPLS-TE uses MPLS label to direct forwarding, RRTS uses IP routes to direct forwarding. We just leverage the BGP route reflection mechanism to achieve this.

So, for the failure case, RRTS also needs to calculate and "install" backup path/routes, it also need do RR or FRR as well if needed. 

> encapsulation point. Your proposal does not seem to have such local

Thanks for pointing out this, I have not read it and will read it later.

> service overlay on top of it.

I know what you mean, and I also agree with you that it's not necessary to centralize everything. 

The RRTS idea does not intend to control everything, and it is not designed for any networks, it tries to solve the use cases introduced in the draft without large network updates. 

Since the existing tools are limited, especially for the pure IP forwarding network, it seems this may be the only way to control the forwarding path in an explicit way. 

In some customer's network, the IP Core network is not so dynamical as imagined. And furthermore, they may think it's better that the core network should be relatively static and controllable, hence they could conduct the traffic easier.
 
Best regards,
Mach
> > If I understand the ORR and draft-varlashkin correctly, they both try to calculate
> (from the client's perspective) the best route that is from the client to
> destination/nexthop.
> >
> > But, just as Russ summarized, the use cases introduced in this draft (use case 1
> and 2) require to calculate the route from the eBGP peer's perspective, hence to
> optimize the traffic flow between eBGP peers (between MANs). This seems not
> be solved by the ORR and draft-varlashkin.
> >
> > Best regards,
> > Mach
> >
> >> Subject: Re: [i2rs] Thoughts on
> draft-chen-idr-rr-based-traffic-steering-usecase
> >> as an I2RS Use Case
> >>
> >> Hi Mach,
> >>
> >> >> Subject: [i2rs] Thoughts on
> draft-chen-idr-rr-based-traffic-steering-usecase as
> >> an
> >> >> I2RS Use Case
> >> >>
> >> >> Y'all:
> >> >>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 23 Jul 2013 13:28:33 +0200

Hi Mach,

> So, for the failure case, RRTS also needs to calculate and "install" backup path/routes, it also need do RR or FRR as well if needed.

I am afraid that maybe I was not clear.

I would like to observe that there is fundamental difference between
RRTS and MPLS-TE or any other IGP centric traffic steering solutions.
The former works on the basis of all BGP routes (could be millions)
while the latter works on the basis of just proper steering via IGP to
BGP next hops. Hence the latter allows indirection while the former
does not.

For me this is the most significant difference of both paradigms.

Best regards,
R.