Subject: [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

From: [email-masked]
Date: Sun, 13 Oct 2019 22:09:27 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : Performance-based BGP Routing Mechanism
        Authors         : Xiaohu Xu
                          Shraddha Hegde
                          Ketan Talaulikar
                          Mohamed Boucadair
                          Christian Jacquenet
	Filename        : draft-ietf-idr-performance-routing-02.txt
	Pages           : 10
	Date            : 2019-10-13

Abstract:
   The current BGP specification doesn't use network performance metrics
   (e.g., network latency) in the route selection decision process.
   This document describes a performance-based BGP routing mechanism in
   which network latency metric is taken as one of the route selection
   criteria.  This routing mechanism is useful for those server
   providers with global reach to deliver low-latency network
   connectivity services to their customers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-performance-routing/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-performance-routing-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-performance-routing-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-performance-routing-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "徐小虎(义先)" <[email-masked]>
Date: Tue, 15 Oct 2019 17:57:24 +0800

Hi all,

I just recently realized that the performance routing mechanism as described in this draft could facilitate the deployment of segment routing across multiple ASes of an administrative entity where low-latency SR paths across ASes are needed for carrying latency-sensitive and high-priority traffic. In this way, there is no need to resort to centralized TE controllers for calculating low-latency paths across ASes. 

Any comments and suggestions are welcome.

Best regards,
Xiaohu

------------------------------------------------------------------
From:internet-drafts <[email-masked]>
Send Time:2019年10月14日(星期一) 13:09
To:i-d-announce <[email-masked]>
Cc:idr <[email-masked]>
Subject:[Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Abstract:

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

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 15 Oct 2019 15:49:42 +0200

Xiaohu,

few comments:

RFC7311 is very specific about containing routes with AIGP attribute within AIGP administrative domain, while not well defined in RFC7311, perhaps worth saying something?
The value field of the AIGP TLV in RFC7311 is 8 octets long - draft defines 4 octet value, I assume you are following RFC8570 and RFC7471 encoding?
Rather that making AIGP TLV and NETWORK_LATENCY TLV  mutually exclusive, perhaps defining how they interact, if both are present would be a better choice?
Capability Advertisement - 3rd para doesn’t parse, be clear if it applies to labelled routes only (RFC7311 is vague here - "tunneling of some sort”)
Manipulation of the Unidirectional Link delay sub-TLV in IGP’s could natively be done by using  Unidirectional Link Delay TLV in RFC8571.

3107 has been obsoleted by 8277

Cheers,
Jeff

---

From: Ondrej Zajicek <[email-masked]>
Date: Wed, 16 Oct 2019 11:37:20 +0200

Hi

My main objection to the draft is it uses separate SAFI to signal that
latency based routing is used. I don't think that is a good idea. Latency
based routing is a general concept, which makes sense to use with several
existing SAFIs (at least 1, 4 and 128). Whether or not announce and
use NETWORK_LATENCY TLV should be an independent session property, like
using AIGP TLV or e.g. ADD-PATH extension.

This is an issue that was underspecified in RFC 7311, just kept by
configuration of both sides. Perhaps we need a new capability to specify
which AIGP TLVs (if any) are supposed to be used on the session, so it
can be negotiated automatically like ADD-PATH.

-- 
Ondrej 'Santiago' Zajicek (email: [email-masked])

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 16 Oct 2019 19:09:38 +0800

Hi Jeff,

Thanks for your comments. Please see my response inline.

------------------------------------------------------------------
From:Jeff Tantsura <[email-masked]>
Send Time:2019年10月15日(星期二) 21:50
To:SPRING WG List <[email-masked]>; 徐小虎(义先) <[email-masked]>
Cc:idr <[email-masked]>
Subject:Re: [spring] [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Xiaohu, 

few comments:

[Xiaohu] In fact, the performance routing mechanism as described in this draft is targeted to be deployed across multiple domains which are under the control of the same administrative entity.

[Xiaohu] Your observation is correct.

[Xiaohu] I would consider it later.

[Xiaohu]???

[Xiaohu] Sure.

[Xiaohu] will update it, thanks again for your comments.

Best regards,
Xiaohu

Cheers, 
Jeff
On Oct 15, 2019, 11:57 AM +0200, 徐小虎(义先) <xiaohu.xxh@alibaba-inc..com>, wrote:

Hi all,

Best regards,
Xiaohu

 Abstract:

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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 16 Oct 2019 11:59:02 +0000

At the time the notion was that one could define addl TLVs to suit one's routing design.. The use case I had and still do in mind is a BGP 3107 topology to carry NHs across a set of stripped IGPs, this seems to deviate from that model.

Thanks,
	Jim Uttaro

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Ondrej Zajicek
Sent: Wednesday, October 16, 2019 5:37 AM
To: 徐小虎(义先) <[email-masked]>
Cc: idr <[email-masked]>; SPRING WG List <[email-masked]>
Subject: Re: [spring] [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Hi

_______________________________________________
spring mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_spring&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=nTDIog7BhaHv2SH9PKmzhZAYEnJisvMqEfHsCyZoQ2E&s=fzT3zdTC_W3QtjsM2DSzNWzm3QE36Ug8Vc6zI1Mjwbo&e=

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 16 Oct 2019 12:02:44 +0000

Comments In-Line..

Thanks,
              Jim Uttaro

From: Idr <[email-masked]> On Behalf Of ???(??)
Sent: Wednesday, October 16, 2019 7:10 AM
To: spring <[email-masked]>; SPRING WG List <[email-masked]>
Cc: idr <[email-masked]>
Subject: Re: [Idr] [spring] I-D Action: draft-ietf-idr-performance-routing-02.txt

Hi Jeff,

------------------------------------------------------------------
From:Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Send Time:2019年10月15日(星期二) 21:50
To:SPRING WG List <[email-masked]<mailto:[email-masked]>>; 徐小虎(义先) <[email-masked]<mailto:[email-masked]>>
Cc:idr <[email-masked]<mailto:[email-masked]>>
Subject:Re: [spring] [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Xiaohu,

few comments:

RFC7311 is very specific about containing routes with AIGP attribute within AIGP administrative domain, while not well defined in RFC7311, perhaps worth saying something?
[Jim U>] Yes.. The intention was to keep it loose as the use of BGP 3107 between AS domains should only require that administration of both is under the same entity. TBH I am not sure on that one either, I think it should be coordinating as AIGP metric needs to reflect the same metric upon evaluation in either domain.

Rather that making AIGP TLV and NETWORK_LATENCY TLV  mutually exclusive, perhaps defining how they interact, if both are present would be a better choice?
[Jim U>] Not sure why you need more that AIGP here.

[Xiaohu]???

[Xiaohu] Sure.

Best regards,
Xiaohu

Cheers,
Jeff
On Oct 15, 2019, 11:57 AM +0200, 徐小虎(义先) <xiaohu.xxh@alibaba-inc..com<mailto:xiaohu.xxh@alibaba-inc..com>>, wrote:

Hi all,

Best regards,
Xiaohu

------------------------------------------------------------------
From:internet-drafts <[email-masked]<mailto:[email-masked]>>
Send Time:2019年10月14日(星期一) 13:09
To:i-d-announce <[email-masked]<mailto:[email-masked]>>
Cc:idr <[email-masked]<mailto:[email-masked]>>
Subject:[Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-performance-routing/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Didr-2Dperformance-2Drouting_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=2D17KseO9-3MwxG0bv51v8h3paX_npCaWrx_HU63slQ&s=uJI2FdshAGO3ifqSHpNU-ok5RFr0KQDwMuSbiFmOhUs&e=>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-performance-routing-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Didr-2Dperformance-2Drouting-2D02&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=2D17KseO9-3MwxG0bv51v8h3paX_npCaWrx_HU63slQ&s=afoF9gCu3QLd-qWFaJAGJ-RycA5YktGfx-h7tI2fWKY&e=>
https://datatracker.ietf.org/doc/html/draft-ietf-idr-performance-routing-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Didr-2Dperformance-2Drouting-2D02&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=2D17KseO9-3MwxG0bv51v8h3paX_npCaWrx_HU63slQ&s=vu8ATfoOlOvueUw1znE78W0Q-elANw9PXralfRWtfk0&e=>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-performance-routing-02<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Didr-2Dperformance-2Drouting-2D02&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=2D17KseO9-3MwxG0bv51v8h3paX_npCaWrx_HU63slQ&s=8j_-oOuKcjeBJQrTxgTZKOgUKEIiYCwBv38J7dN6DfY&e=>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=2D17KseO9-3MwxG0bv51v8h3paX_npCaWrx_HU63slQ&s=sWe9TOfNtkRfbU2QTObpTbhJvG9DKJqtXDz9PsTKADA&e=>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=2D17KseO9-3MwxG0bv51v8h3paX_npCaWrx_HU63slQ&s=i0EmqXkMVaF_AGwRneLdIWtw_T6SBdIVH9xwnYYYYys&e=>
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=2D17KseO9-3MwxG0bv51v8h3paX_npCaWrx_HU63slQ&s=i0EmqXkMVaF_AGwRneLdIWtw_T6SBdIVH9xwnYYYYys&e=>

---

From: "徐小虎(义先)" <[email-masked]>
Date: Wed, 16 Oct 2019 20:12:53 +0800

In addition, the performance routing paradigm could actually be deployed in the EPE scenario as well where both capacity-aware TE capability and performance-aware TE capability are desired. More specifically, since there are two routing tables, one contains vanilla routes which are used for capacity-aware routing purpose and the other contains performance routes which are used for performance-aware routing purpose, which are manipulated by the EPE controller via the BGP-LU and the performance routing SAFIs respectively, traffic with different QoS class but designated for the same destination could be forwarded to different ISP peers according to different routing tables. 

In this way, it allows cloud providers to provide differentiated Internet connectivity service to their tenants. For example, high-priority traffic originated from gold tenants could be forwarded according to the performance routing table while the remaining traffic would be forwarded according to the vanilla routing table, as a result, the former is forwarded along a low-latency path while the latter is forwarded along a high-latency path. 

Best regards,
Xiaohu

------------------------------------------------------------------
From:徐小虎(义先) <[email-masked]>
Send Time:2019年10月15日(星期二) 17:57
To:SPRING WG List <[email-masked]>
Cc:idr <[email-masked]>
Subject:Re: [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt

Hi all,

Best regards,
Xiaohu

Abstract: