Re: [Teas] [spring] FW: New Version Notification fordraft-dong-spring-sr-for-enhanced-vpn-07.txt Wed, 11 March 2020 04:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B10283A10DC; Tue, 10 Mar 2020 21:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KaBnQDbN6GTD; Tue, 10 Mar 2020 21:08:55 -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 BC72A3A10D9; Tue, 10 Mar 2020 21:08:53 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id F2551C9A7C14953539E9; Wed, 11 Mar 2020 12:08:50 +0800 (CST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id D19871F1F4D263EAC86C; Wed, 11 Mar 2020 12:08:50 +0800 (CST)
Received: from ([]) by with SMTP id 02B47oX6093660; Wed, 11 Mar 2020 12:07:50 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 11 Mar 2020 12:07:49 +0800 (CST)
Date: Wed, 11 Mar 2020 12:07:49 +0800 (CST)
X-Zmail-TransId: 2afb5e6864156ebe4715
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>, <>, <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 02B47oX6093660
Archived-At: <>
Subject: Re: [Teas] =?utf-8?q?=5Bspring=5D_FW=3A_New_Version_Notification_for?= =?utf-8?q?draft-dong-spring-sr-for-enhanced-vpn-07=2Etxt?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Mar 2020 04:09:01 -0000

Hi Jie,

I don’t think it’s time to call for adoption. Teas Slice DT is still working on the definition and the framework of the transport slice,which has not been accepted by the teas working group. 

For the draft, I have some comments:

1.Compared with the ietf-teas-enhanced-vpn, It seems like that there is no more new technology. What's the meaning of this draft as standard track? 

2.Control plane extensions that you referred in this draft is ietf-dong-lsr-sr-enhanced-vpn, and ietf-dong-idr-bgpls-sr-enhanced-vpn, and we also have a series of control plane drafts:, , satisfying the same requirement. So Control plane extensions are still an open question, and needing further discussing. 

3. For slice resources, our draft:  induced slice-id(AII) for slice resources management, and our solution can differentiate them (e.g. L2 link or L3 interface), how to compute SR-BE or SR-TE path according to AII combined with other criteria. This isnot very clear in your draft.




发件人:Dongjie(Jimmy) <>
收件人:'SPRING WG List' <>rg>;
抄送人 <>rg>;
日 期 :2020年03月10日 18:00
主 题 :[spring] FW: New Version Notification fordraft-dong-spring-sr-for-enhanced-vpn-07.txt

Hi all, 

We've submitted a new revision of draft-dong-spring-sr-for-enhanced-vpn. 

This version includes some editorial changes based on the previous -06 version, which have solved the comments received before and during IETF 106 meeting. 

The authors believe this document is ready for WG adoption, and thus solicit the WG to consider initiating the adoption poll on it. Thanks.

Best regards,

-----Original Message-----
From: [] 
Sent: Monday, March 9, 2020 4:33 PM
To: Takuya Miyasaka <>om>; Dongjie (Jimmy) <>om>; Stewart Bryant <>om>; Yongqing Zhu <>cn>; Fengwei Qin <>om>; Zhenqiang Li <>
Subject: New Version Notification for draft-dong-spring-sr-for-enhanced-vpn-07.txt

A new version of I-D, draft-dong-spring-sr-for-enhanced-vpn-07.txt
has been successfully submitted by Jie Dong and posted to the IETF repository.

Name:        draft-dong-spring-sr-for-enhanced-vpn
Revision:    07
Title:        Segment Routing for Resource Guaranteed Virtual Networks
Document date:    2020-03-09
Group:        Individual Submission
Pages:        18

   This document describes the mechanism to associate Segment Routing
   Identifiers (SIDs) with network resource attributes.  The resource-
   aware SIDs retain their original functionality, with the additional
   semantics of identifying the set of network resources available for
   the packet processing action.  These SIDs can be used to build SR
   paths with reserved network resources.  In addition, these SID can
   also be used to build SR based virtual networks, which provide the
   network topology and resource attributes required by particular
   services.  The proposed mechanism is applicable to both segment
   routing with MPLS data plane (SR-MPLS) and segment routing with IPv6
   data plane (SRv6).


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

The IETF Secretariat

spring mailing list