Subject: [Idr] fwd: New Version Notification for draft-xu-idr-performce-routing-00.txt

From: Xuxiaohu <[email-masked]>
Date: Tue, 10 Dec 2013 07:48:58 +0000

Hi all,

Any comments are welcome.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2013年12月10日 15:42
> 收件人: Yongbing Fan; Nihui (nihui, VRPDesign); Xuxiaohu; Xuxiaohu; Fan
> Yongbing
> 主题: New Version Notification for draft-xu-idr-performce-routing-00.txt
> 
> 
> A new version of I-D, draft-xu-idr-performce-routing-00.txt
> has been successfully submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Filename:	 draft-xu-idr-performce-routing
> Revision:	 00
> Title:		 Performance-based BGP Routing Mechanism
> Creation date:	 2013-12-10
> Group:		 Individual Submission
> Number of pages: 7
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-idr-performce-routing-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-xu-idr-performce-routing
> Htmlized:        http://tools.ietf.org/html/draft-xu-idr-performce-routing-00
> 
> 
> Abstract:
>    Network performance, especially network latency is widely recognized
>    as one of major obstacles in adopting public cloud services (e.g.,
>    cloud desktop service), especially in the scenario where the network
>    paths between cloud end-users and cloud data centers traverse more
>    than one Autonomous System (AS). However, the current Border Gateway
>    Protocol (BGP) specification [RFC4271] doesn't use network
>    performance metrics (e.g., network latency) in the route selection
>    decisions. This document describes a performance-based BGP routing
>    mechanism in which network latency metric is taken as one of the
>    route selection criteria.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Jared Mauch <[email-masked]>
Date: Tue, 10 Dec 2013 17:53:58 -0500

> Any comments are welcome.

There are a number of problems I see here.

Performance is not well defined.  Latency is mostly irrelevant to the performance of the higher layer functions necessary to execute the premise outlined in your draft (cloud computing).

There would be a great deal of BGP "noise" as UPDATES are sent due to networks shifting topology.  (eg: take a MPLS-TE network with auto-bandwidth enabled and varying demands following localized traffic shifts on a global network due to daylight/peak hours).

in an iBGP environment, the two devices at and edge speak directly to each other.  No knowledge of the mid-points is available to BGP.  This is carried within some other IGP, such as OSPFv3, ISIS.

One can already signal this information through the MED attribute as well.  Any changes nodes with the path selected would also impact traffic patterns and require new measurements resulting in better/worse  results to be signaled with possibly cascading signaling ongoing.  See RFC3345 for an example of a possible resulting outcome.

Most networks are constrained at the edge as well and are not BGP speaking, so measurement data doesn't signal within an aggregated NLRI.  To properly signal you would need to flood a significant amount of data.  This also excludes the return-path problem, as something may change outside your view and you need to re-measure the outcomes.

Folks have tried doing this for many years with appliances and devices (eg: Internap, Branch.net w/ gated on BSDI) and the background change requires significant ongoing *active* measurements to calculate the best results to optimize delivery.

Hope this input helps.

- Jared

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 13 Dec 2013 09:00:32 +0000

<Skip>

> It also doesn't exactly answer why the application can't be dealing with the
> problem.

The following blog and the linked webinar might be helpful for you to understand the motivation for performance-based routing mechanism:
http://blog.level3.com/level-3-network/network-performance-app-performance/

Best regards,
Xiaohu

<skip>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 13 Dec 2013 11:12:14 +0000

Xiaohu,

	How is this different than the AIGP draft? The AIGP draft defines a new attribute which is used to capture the IGP metric, which in a low latency set of networks is latency. I would suggest that you look at that draft as its main purpose in life is to capture latency ( IGP Metric ) in a BGP attribute and propagate between AS domains.. 

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Friday, December 13, 2013 4:01 AM
To: Christopher Morrow
Cc: [email-masked]
Subject: Re: [Idr] fwd: New Version Notification for draft-xu-idr-performce-routing-00.txt

<Skip>

Best regards,
Xiaohu

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Dec 2013 19:45:05 +0100

Hi Jim,

I proposed to Xu exactly the same during last IETF. But his response was
that interface metrics may be subject to modifications to influence traffic
paths (for example using automation tools like Cariden).

His link latency on the other hand would be pretty static .. read more
static then metric of the link which influences SPF.

If that's the case I would tend to agree with him.

Also said this my second suggestion was to extend AIGP with new TLV type 2.

But obviously authors of cost community draft (now also officially
proposing to include cumulative metrics) may have their own preferences ;)

Best,
R.

On Fri, Dec 13, 2013 at 12:12 PM, UTTARO, JAMES <[email-masked]> wrote:

> Xiaohu,
>
>         How is this different than the AIGP draft? The AIGP draft defines
> a new attribute which is used to capture the IGP metric, which in a low
> latency set of networks is latency. I would suggest that you look at that
> draft as its main purpose in life is to capture latency ( IGP Metric ) in a
> BGP attribute and propagate between AS domains..
>
> Jim Uttaro
>
> The following blog and the linked webinar might be helpful for you to
> understand the motivation for performance-based routing mechanism:

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 16 Dec 2013 03:52:25 +0000

Hi Jim,

I'm glad to hear that you are in favor of using network latency in the BGP path selection as well.

As Robert has pointed out in a response to your email, I hope the performance-based BGP path selection has no special requirement on the existing IGP path selection. That's to say, it doesn't require the IGP to use the latency as a metric for the best path calculation. Besides, I hope the performance-based BGP path selection paradigm could co-exisit with the vanilla BGP routing paradigm.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: UTTARO, JAMES [mailto:[email-masked]]
> 发送时间: 2013年12月13日 19:12
> 收件人: Xuxiaohu; Christopher Morrow
> 抄送: [email-masked]
> 主题: RE: [Idr] fwd: New Version Notification for
> draft-xu-idr-performce-routing-00.txt
> 
> Xiaohu,
> 
> 	How is this different than the AIGP draft? The AIGP draft defines a new
> attribute which is used to capture the IGP metric, which in a low latency set of
> networks is latency. I would suggest that you look at that draft as its main
> purpose in life is to capture latency ( IGP Metric ) in a BGP attribute and
> propagate between AS domains..
> 
> Jim Uttaro
> 
> > It also doesn't exactly answer why the application can't be dealing
> > with the problem.
>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 16 Dec 2013 13:03:28 +0000

Robert,

                The AIGP draft can be extended to accommodate another TLV, and  it already has a configurable threshold to avoid thrashing  etc... At the end of the day I do not understand how across a set of disparate AS domains that are described as public the consistency of network measured latency is done. I purposefully stayed away from the discussion about AS domains belonging to multiple administrative authorities as it is not possible to enforce the needed consistency of metric evaluation..

Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, December 13, 2013 1:45 PM
To: UTTARO, JAMES
Cc: Xuxiaohu; Christopher Morrow; [email-masked]
Subject: Re: [Idr] fwd: New Version Notification for draft-xu-idr-performce-routing-00.txt

Hi Jim,

I proposed to Xu exactly the same during last IETF. But his response was that interface metrics may be subject to modifications to influence traffic paths (for example using automation tools like Cariden).

His link latency on the other hand would be pretty static .. read more static then metric of the link which influences SPF.

But obviously authors of cost community draft (now also officially proposing to include cumulative metrics) may have their own preferences ;)

Best,
R.

On Fri, Dec 13, 2013 at 12:12 PM, UTTARO, JAMES <[email-masked]<mailto:[email-masked]>> wrote:
Xiaohu,

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xuxiaohu
Sent: Friday, December 13, 2013 4:01 AM
To: Christopher Morrow
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] fwd: New Version Notification for draft-xu-idr-performce-routing-00.txt

<Skip>

Best regards,
Xiaohu

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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 16 Dec 2013 13:05:16 +0000

Xu,

	Could you describe the use case you are addressing with this draft, the mechanisms to describe latency and how it works across AS domains belonging to different administrative authorities.. I am a bit lost as to what you are trying to accomplish that the AIGP technology cannot do.

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Sunday, December 15, 2013 10:52 PM
To: UTTARO, JAMES; Christopher Morrow
Cc: [email-masked]
Subject: Re: [Idr] fwd: New Version Notification for draft-xu-idr-performce-routing-00.txt

Hi Jim,

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Dec 2013 01:11:58 +0000

> 发送时间: 2013年12月16日 21:05
> 	Could you describe the use case you are addressing with this draft, the
> mechanisms to describe latency and how it works across AS domains belonging
> to different administrative authorities.. I am a bit lost as to what you are trying

Jim,

As stated in Section 6 "Deployment Considerations", "...It's RECOMMENDED to deploy this performance-based BGP routing
   mechanism across multiple ASs which are within a single
   administrative domain. "

> to accomplish that the AIGP technology cannot do.

See my response in the previous email (as below)

Xiaohu

> As Robert has pointed out in a response to your email, I hope the
> performance-based BGP path selection has no special requirement on the
> existing IGP path selection. That's to say, it doesn't require the IGP to use the
> latency as a metric for the best path calculation. Besides, I hope the
> performance-based BGP path selection paradigm could co-exisit with the vanilla
> BGP routing paradigm.
> 
> Best regards,
> Xiaohu
> 
> > -----邮件原件-----
> > 	How is this different than the AIGP draft? The AIGP draft defines a
> > new attribute which is used to capture the IGP metric, which in a low
> > latency set of networks is latency. I would suggest that you look at
> > that draft as its main purpose in life is to capture latency ( IGP
> > Metric ) in a BGP attribute and propagate between AS domains..
> >
> > Jim Uttaro
> >
> > http://blog.level3.com/level-3-network/network-performance-app-perform
> > ance
> > /
> >
> > Best regards,
> > Xiaohu
> >
> > <skip>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 17 Dec 2013 01:29:31 +0000

Your responses do not seem to jive with your draft.

The AIGP draft provides mechanisms that you require to accomplish your goals at least as I understand them.

Jim Uttaro

Comments In -Line..

-----Original Message-----
From: Xuxiaohu [mailto:[email-masked]] 
Sent: Monday, December 16, 2013 8:12 PM
To: UTTARO, JAMES; Christopher Morrow
Cc: [email-masked]
Subject: re: [Idr] fwd: New Version Notification for draft-xu-idr-performce-routing-00.txt

Jim,

As stated in Section 6 "Deployment Considerations", "...It's RECOMMENDED to deploy this performance-based BGP routing
   mechanism across multiple ASs which are within a single
   administrative domain. "
[Jim U>] Your words..
"Network performance, especially network latency is widely recognized
   as one of major obstacles in adopting public cloud services (e.g.,
   cloud desktop service), especially in the scenario where the network
   paths between cloud end-users and cloud data centers traverse more
   than one Autonomous System (AS)."

More Words..

"It's RECOMMENDED to deploy this performance-based BGP routing
   mechanism across multiple ASs which are within a single
   administrative domain. Whether it is practical to deploy such
   mechanism across AS's of different administrative domains as well is
   a matter of trust and/or policy, which is outside of the scope of
   this document.
"

So is this intended for SPs that are creating an end to-to-end path between two disparate cloud service providers?? Most SPs do not have a global presence and require partnerships with other providers.. A good example of this is China Telecom's partnerships...

By definition public AS domains that are traversed may belong to different SPs in fact that would seem to be a reality.

Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 17 Dec 2013 02:05:00 +0000

> 发送时间: 2013年12月17日 9:30

My intention is: It's clearly RECOMMENDED to deploy this performance-based BGP routing mechanism across multiple ASs which are within a single administrative domain. However, if two or more adjacent SPs are willing to trust each other and deploy such technology in their Ass, it's their own business and there is no necessity to exclude that.

> at least as I understand them.

The following are two of my goals:

1) Don't require any dependency on the IGP metric;
2) Keep performance routing and vanilla routing coexist.

Could you please explain how the existing AIGP mechanism accomplish the above two goals?

Xiaohu

> As stated in Section 6 "Deployment Considerations", "...It's RECOMMENDED to
> deploy this performance-based BGP routing
> So is this intended for SPs that are creating an end to-to-end path between two
> disparate cloud service providers?? Most SPs do not have a global presence and
> require partnerships with other providers.. A good example of this is China
> Telecom's partnerships...
>