Subject: [Idr] Comparison between performance-based BGP routing and AIGP

From: Xuxiaohu <[email-masked]>
Date: Thu, 6 Mar 2014 17:18:35 +0000

Hi all,

Since somebody has raised the question about the difference between the above approaches, I will try to make a brief comparison between them in this email.

Sameness: 

1) Both approaches are intended to be deployed within ASes belonging to a single administrative domain.

2) Both approaches require the same change to the tie-breaking procedures of the BGP route selection decision (phase 2, [RFC4271]).

Difference: 

1) The design goal of the former is to allow the performance routing paradigm to coexist with the vanilla routing paradig. In this way, service providers could thus provide low-latency routing services while still offering the vanilla routing services depending on customers’ requirements;

2) The former allows the BGP speaker to use the Capabilities Optional Parameter [RFC5492] to inform its peers about the performance route computation capability.

3) The former recommends to use the latency metric carried in Unidirectional Link Delay Sub-TLV [draft-ietf-ospf-te-metric-extensions] [draft-previdi-isis-te-metric-extensions], rather than the IGP metric to calculate the cumulative link latency associated with the TE LSP between BGP peers.

Best regards,
Xiaohu

---

From: Zhuangshunwan <[email-masked]>
Date: Thu, 6 Mar 2014 18:04:22 +0000

My opinion:
AIGP provides a static measurement of the network, performance-based BGP routing can provide a dynamic measurement.
The latter can reflect the running state of network and tuning the traffic path automatically.

-----邮件原件-----
发件人: Idr [mailto:[email-masked]] 代表 Xuxiaohu
发送时间: 2014年3月7日 1:19
收件人: [email-masked]
主题: [Idr] Comparison between performance-based BGP routing and AIGP

Hi all,

Sameness: 

Difference: 

Best regards,
Xiaohu
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Eric Rosen <[email-masked]>
Date: Mon, 10 Mar 2014 12:12:35 -0400

Xiaohu> 1) The design goal of the former [draft-xu-idr-performce-routing] is
Xiaohu> to allow the performance routing paradigm to coexist with the
Xiaohu> vanilla routing paradigm. In this way, service providers could thus
Xiaohu> provide low-latency routing services while still offering the
Xiaohu> vanilla routing services depending on customers' requirements;

This may suggest that you want to use a different SAFI for the performance
routes than for the vanilla routes.  However, it doesn't imply that you
can't achieve your goal by attaching the AIGP attribute to the routes of
that SAFI.

Xiaohu> 2) The former allows the BGP speaker to use the Capabilities
Xiaohu> Optional Parameter [RFC5492] to inform its peers about the
Xiaohu> performance route computation capability.

You get that automatically if you use a different AFI/SAFI, independent of
whether you use the AIGP attribute to carry your metric.

Xiaohu> 3) The former recommends to use the latency metric carried in
Xiaohu> Unidirectional Link Delay Sub-TLV, rather than the IGP metric

That suggests the use of a new TLV of the AIGP attribute.

I suspect that one of the intentions of using a new attribute is to make it
illegal for that attribute to be carried by Updates of any SAFI other than
the "performance route" SAFI.  But I think that would require the attribute
to be "optional non-transitive" rather than (as the draft states) "mandatory
well-known".  In any event, you need to specify the error-handling
behavior.  It seems like you want "discard attribute" if it appears on a
vanilla route, but "treat as withdraw" if a malformed attribute appears on a
performance route.  

Note that once you invent a new SAFI, you have to deal with such issues as:

- does the next hop have to be of the same AFI as the NLRI?

- if the best route to the next hop is itself a BGP route (recursive route
  resolution), and if there is both a performance route and a vanilla route
  to the next hop, which do you use?

You should also deal with the question of what you want to do in the case
where a "vanilla" route has a next hop, the route to the next hop is a BGP
route, and you have both a vanilla route and a performance route to the next
hop.

In fact, even if the route to the next hop is not a BGP route, there might
be both a "vanilla" IGP route to the next hop and a traffic engineered IGP
route to the next hop.  Does that need to be taken into account?

There's also the issue of whether the performance routes are comparable to
the vanilla routes, and if so, which would be preferred under what
conditions.  (Failure to think this out in advance for SAFI 1 vs. SAFI 4,
e.g., has caused a number of problems.)

Without seeing a few detailed use cases, it's difficult to see whether the
draft is really a good solution to a real problem.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Mar 2014 01:48:25 +0100

Eric, Xu,

How about using ls-bgp SAFI with TE metrics extension ?

As I have spoke about it offline with Hannes it seems to at least be a good
candidate here to consider.

While this can become non congruent this should not be an issue as BGP be
design is not congruent to the actual data path anyway ...

Best,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 11 Mar 2014 02:47:51 +0000

Hi Eric,

Thanks a lot for your valuable comments. Please see my response inline.

> -----邮件原件-----
> 发件人: Eric Rosen [mailto:[email-masked]]
> 发送时间: 2014年3月11日 0:13
> 收件人: Xuxiaohu
> 抄送: [email-masked]; [email-masked]
> 主题: Re: [Idr] Comparison between performance-based BGP routing and AIGP
> 
> 
> 
> Xiaohu> 1) The design goal of the former
> Xiaohu> [draft-xu-idr-performce-routing] is to allow the performance
> Xiaohu> routing paradigm to coexist with the vanilla routing paradigm.
> Xiaohu> In this way, service providers could thus provide low-latency
> Xiaohu> routing services while still offering the vanilla routing
> Xiaohu> services depending on customers' requirements;
> 
> routes than for the vanilla routes.  However, it doesn't imply that you can't
> achieve your goal by attaching the AIGP attribute to the routes of that SAFI.

We co-authors would consider the possibility of using the AIGP attribute or the Cost community attribute to carry the network latency metric. We would like to hear any suggestions on how to use any of the above attributes from IDR WG, especially the co-authors of AIGP and Cost-community drafts.  

> whether you use the AIGP attribute to carry your metric.

Exactly.

> That suggests the use of a new TLV of the AIGP attribute.

Good suggestion and we will consider it.

> I suspect that one of the intentions of using a new attribute is to make it illegal
> for that attribute to be carried by Updates of any SAFI other than the
> "performance route" SAFI.  But I think that would require the attribute to be
> "optional non-transitive" rather than (as the draft states) "mandatory
> well-known".  In any event, you need to specify the error-handling behavior.

Good suggestion and we will consider it.

> It seems like you want "discard attribute" if it appears on a vanilla route, but
> "treat as withdraw" if a malformed attribute appears on a performance route.
> 

> You should also deal with the question of what you want to do in the case where
> a "vanilla" route has a next hop, the route to the next hop is a BGP route, and
> you have both a vanilla route and a performance route to the next hop.
> 
> In fact, even if the route to the next hop is not a BGP route, there might be both
> a "vanilla" IGP route to the next hop and a traffic engineered IGP route to the
> next hop.  Does that need to be taken into account?
> 
> There's also the issue of whether the performance routes are comparable to the
> vanilla routes, and if so, which would be preferred under what conditions.
> (Failure to think this out in advance for SAFI 1 vs. SAFI 4, e.g., has caused a
> number of problems.)

> Without seeing a few detailed use cases, it's difficult to see whether the draft is
> really a good solution to a real problem.

Thanks a lot for the above suggestions and comments, we will try to clarify them in the next version.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 11 Mar 2014 03:13:02 +0000

Hi Robert,

Thanks a lot for your proposal and we co-authors will consider it seriously.

Best regards,
Xiaohu

发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年3月11日 8:48
收件人: [email-masked]
抄送: Xuxiaohu; [email-masked]
主题: Re: [Idr] Comparison between performance-based BGP routing and AIGP

Eric, Xu,

As I have spoke about it offline with Hannes it seems to at least be a good candidate here to consider.

While this can become non congruent this should not be an issue as BGP be design is not congruent to the actual data path anyway ...

Best,
R.

On Mon, Mar 10, 2014 at 5:12 PM, Eric Rosen <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr