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

" 徐小虎(义先) " <> Wed, 16 October 2019 12:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7B6C120910; Wed, 16 Oct 2019 05:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aZ-rsEp4gEoX; Wed, 16 Oct 2019 05:12:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E44E12090F; Wed, 16 Oct 2019 05:12:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1571227974; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=3DmnyW8fiuPfCiCh2Swptw4pt9jUddK7vd0OD81Pw4U=; b=fsFUC5TyTAix7QbR+Ri4Yw1Ih+rCeO0w7W9/RP7zs2DHyoPyn0lynt3b3XyVSrSUBxphx/otiJgi+jFthZbGFYTkxKtse7QbbWB7Gjfsj/vpixEtsXa7m4/8f+W/Nss4BH5wW6GQtwqBnR4ywlvVRcP4P6yBq0gO0IrlYeFOs6w=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03302;; NM=1; PH=DW; RN=3; SR=0; TI=W4_5657687_v5ForWebDing_0A932313_1571224406244_o7001c1736c;
Received: from WS-web ([W4_5657687_v5ForWebDing_0A932313_1571224406244_o7001c1736c]) by e01l07406.eu6 at Wed, 16 Oct 2019 20:12:53 +0800
Date: Wed, 16 Oct 2019 20:12:53 +0800
From: "徐小虎(义先)" <>
To: "徐小虎(义先)" <>, SPRING WG List <>
Cc: idr <>
Reply-To: "徐小虎(义先)" <>
Message-ID: <>
X-Mailer: [Alimail-Mailagent revision 2765257][W4_5657687][v5ForWebDing][Safari]
MIME-Version: 1.0
References: <>, <eaac2838-0c1d-400f-9913-b30ac9cfdbf0.>, <>
x-aliyun-mail-creator: W4_5657687_v5ForWebDing_NjATW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA1LjEuMTUgKEtIVE1MLCBsaWtlIEdlY2tvKSBWZXJzaW9uLzEyLjAuMyBTYWZhcmkvNjA1LjEuMTU=XQ
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_12452_52a4a940_5da70945_a76ec"
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-performance-routing-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2019 12:13:01 -0000

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,

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

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,

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

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

   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:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

Idr mailing list