Re: [spring] Conclusion of WG adoption call for draft-dong-spring-sr-for-enhanced-vpn

"Dongjie (Jimmy)" <> Fri, 31 July 2020 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B49063A0903; Fri, 31 Jul 2020 09:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NPX-9tZavKEH; Fri, 31 Jul 2020 09:04:48 -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 879313A08C6; Fri, 31 Jul 2020 09:04:48 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 81065FD07438C4DD043; Fri, 31 Jul 2020 17:04:46 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1913.5; Fri, 31 Jul 2020 17:04:40 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sat, 1 Aug 2020 00:04:37 +0800
Received: from ([]) by ([]) with mapi id 15.01.1913.007; Sat, 1 Aug 2020 00:04:37 +0800
From: "Dongjie (Jimmy)" <>
To: James Guichard <>, "" <>
CC: "" <>
Thread-Topic: Conclusion of WG adoption call for draft-dong-spring-sr-for-enhanced-vpn
Thread-Index: AdZlqGq7aALK5FziSxC9xAgKG8w/4wBqSYtw
Date: Fri, 31 Jul 2020 16:04:37 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_fd9490bd36c84820abbb14920e2707f5huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [spring] Conclusion of WG adoption call for draft-dong-spring-sr-for-enhanced-vpn
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Jul 2020 16:04:51 -0000

Hi Chairs,

Thanks a lot for your guidance in moving forward with this document. We have submitted the first part as standard track, and will continue to work on the rest as informational.

And I am unaware of any undisclosed relevant IPR.

Best regards,

From: spring [] On Behalf Of James Guichard
Sent: Wednesday, July 29, 2020 11:32 PM
Subject: [spring] Conclusion of WG adoption call for draft-dong-spring-sr-for-enhanced-vpn


This email concludes the WG adoption call for draft-dong-spring-sr-for-enhanced-vpn.

The chairs noted that although the document received a lot of support, evaluation of consensus to adopt should primarily be driven by substantive comments (technical or otherwise) of which there were several on differing parts of the document.

The text of the current document covers two main parts that may be categorized into standards track and informational track.

The first part is related to the association of resources to Segment Routing Identifiers (SIDs) that:

  *   is specifically referenced in the SPRING charter for mapping segments to forwarding behaviors
  *   received strong support, including from technical reviewers
  *   is the main goal of the draft, stating nearly the full draft abstract:

   " This document describes the mechanism to associate network resource attributes to Segment Routing Identifiers (SIDs).  Such SIDs are referred to as resource-aware SIDs in this document.  The resource-aware SIDs retain their original forwarding semantics, but with the additional semantics to identify the set of network resources available for the packet processing action.  The resource-aware SIDs can therefore be used to build SR paths with a set of reserved network resources."

While this part of the specification still requires some work in order to specify resource-aware semantics for all or a subset of existing SIDs, the chairs feel that consensus to adopt this part of the document was reached and that this should form the basis of a standards track document. Therefore, authors can you please publish a WG document covering only this first part; the document should:

  *   avoid the use of VPN related terms in the filename, title, abstract, page headers etc.
  *   only cover the normative specification of "resource-aware SIDs"
  *   have a filename that reflects the core idea of "resource-aware SIDs" and start with draft-ietf-spring... (suggestion draft-ietf-spring-resource-aware-segments-00)

In addition, please indicate on the mailing list whether you are aware of any undisclosed relevant IPR.

Macroscopically, the above will involve removing sections 4 and 5 of the current document, and maybe the penultimate sentence in the abstract. In addition, the current section 3 (control plane) will need to be significantly re-scoped although this may happen as part of the normal WG document process. In the future, it will also need to precisely define the new information/parameters that would need to be advertised in the control plane; only leaving the encoding to the corresponding protocol specific documents. Now would be better, but it may be done in the future given the agreement on the scope of this document.

The second part is related to the building of virtual networks (e.g. VPN, VPN+, VNT, enhanced VPN...). This part is not primarily an extension to segment/SID, and seems less mature, informational in nature, and one way of building an end-to-end service using a set of building blocks, while other methods are possible and may be equally valid. Therefore, this part may be described in an informational document independent from the standards track document. Depending on the direction that authors choose to follow, this subject may have adherence with the BESS and TEAS WGs, which would need to be considered. Alternatively, the document could follow the direction of an applicability statement or recipe on how to provide, in an SR network, dedicated resources for some services (e.g .VPN, IP TV replication service...).

Authors, you are encouraged to publish a second informational document (individual-ID) covering the non-resource-aware-SIDs parts (with pointers to the standard track document used as a building block) and then have the WG review and then reevaluate that part of the adoption call.


Jim, Joel, & Bruno