[spring] A SRv6 Data Plane TE/QoS Mechanism
"Liubing (Leo)" <leo.liubing@huawei.com> Wed, 10 July 2019 09:52 UTC
Return-Path: <leo.liubing@huawei.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBE61202B7 for <spring@ietfa.amsl.com>; Wed, 10 Jul 2019 02:52:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmsd_NJAEF2Z for <spring@ietfa.amsl.com>; Wed, 10 Jul 2019 02:52:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8990D1202AD for <spring@ietf.org>; Wed, 10 Jul 2019 02:52:23 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id DF6B2157650020B98009 for <spring@ietf.org>; Wed, 10 Jul 2019 10:52:20 +0100 (IST)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Jul 2019 10:52:12 +0100
Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.81]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Wed, 10 Jul 2019 17:49:12 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: "spring@ietf.org" <spring@ietf.org>
Thread-Topic: A SRv6 Data Plane TE/QoS Mechanism
Thread-Index: AdU3BKGAYIy6E5DnTsyjKPkCof2Y/w==
Date: Wed, 10 Jul 2019 09:49:11 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45DA480A11@dggeml512-mbx.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.191.175]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45DA480A11dggeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/-m3SWVfAp5e03_yovPyOVnuyj6Q>
Subject: [spring] A SRv6 Data Plane TE/QoS Mechanism
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 09:52:31 -0000
Hi Dear all, I've uploaded a new draft (as below), which introduces a mechanism to allow the devices to switch flows among multiple paths between a pairs of Ingress/Egress routers. The flow switch is based on real-time measurement of congestion situation of the paths. Such mechanism could be used to do load balancing, SLA assurance and reliability etc. For load balancing use case, we've had a commercial router hardware based prototype in our lab. Although it is not a Spring specific document, the major targeted scenario is SRv6 (our prototype is also based on SRv6), so opinions from you people here in Spring would be very valuable. And if such mechanism is benefit to SR scenarios, we'd be glad to initiate some work in our WG. Your comments would be appreciated very much! Best regards, Bing *************************************Draft Info************************************* Name: draft-liu-ican Revision: 00 Title: Instant Congestion Assessment Network (iCAN) for Data Plane Traffic Engineering Document date: 2019-07-08 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-liu-ican-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-ican/ Htmlized: https://tools.ietf.org/html/draft-liu-ican-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-liu-ican Abstract: iCAN (instant Congestion Assessment Network) is a set of mechanisms running directly on network nodes: o To adjust the flows paths based on real-time measurement of the candidate paths. o The measurement is to reflect the congestion situation of each path, so that the ingress nodes could decide which flows need to be switched from a path to another. This is something that current SDN and TE technologies can hardly achieve: o SDN Controller is slow and far from the data plane, it is neither able to assess the real-time congestion situation of each path, nor able to assure the data plane always go as expected (especially in SRv6 scenarios). However, iCAN can work with SDN perfectly: controller planning multi-path transmission, and iCAN does the flow optimization automatically. o Traditional TE is not able to adjust the flow paths in real-time.
- [spring] A SRv6 Data Plane TE/QoS Mechanism Liubing (Leo)