Re: [spring] WG AdoptionCallfordraft-dong-spring-sr-for-enhanced-vpn

peng.shaofu@zte.com.cn Thu, 23 July 2020 01:25 UTC

Return-Path: <peng.shaofu@zte.com.cn>
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 E3FEB3A0982; Wed, 22 Jul 2020 18:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 9lGFq28zyzp4; Wed, 22 Jul 2020 18:25:30 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 64FCB3A095A; Wed, 22 Jul 2020 18:25:30 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 2781E85B4E7FDA9AC1E6; Thu, 23 Jul 2020 09:25:28 +0800 (CST)
Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl2.zte.com.cn with SMTP id 06N1PQk2038503; Thu, 23 Jul 2020 09:25:26 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Thu, 23 Jul 2020 09:25:26 +0800 (CST)
Date: Thu, 23 Jul 2020 09:25:26 +0800
X-Zmail-TransId: 2af95f18e706f256d1d4
X-Mailer: Zmail v1.0
Message-ID: <202007230925261203011@zte.com.cn>
In-Reply-To: <HK0PR03MB40662AE3B05C5A9DE140F8C0FC780@HK0PR03MB4066.apcprd03.prod.outlook.com>
References: 202007161719327112195@zte.com.cn, d37cd591d1864972b17b225f41cab4bc@huawei.com, 202007201711070262824@zte.com.cn, HK0PR03MB40662AE3B05C5A9DE140F8C0FC780@HK0PR03MB4066.apcprd03.prod.outlook.com
Mime-Version: 1.0
From: peng.shaofu@zte.com.cn
To: li_zhenqiang@hotmail.com
Cc: chen.ran@zte.com.cn, jie.dong@huawei.com, james.n.guichard@futurewei.com, spring@ietf.org, spring-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 06N1PQk2038503
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/SnzKw3wmBxaBbrT3IQnY8Cm42aQ>
Subject: Re: [spring] WG AdoptionCallfordraft-dong-spring-sr-for-enhanced-vpn
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: Thu, 23 Jul 2020 01:25:34 -0000

Hi zhenqiang,





Resource is a big, all encompassing concept. Similarly, service concept, application concept, intent concept, etc, you can find more. 

IMO, we can't ignore the fact that the current SR architecture already cover resource related SID allocation, but to surmise that it lacks resource meaning, then to submit an unnecessary and redundant framework. 

 

AFAIK, there have already been several documents that defined the allocation of SID for specific resouce, for example:

draft-ietf-lsr-flex-algo described topology related resource partition and algorithm based SID allocation, 

L2-bundles(rfc8668) described the allocation of member adjacency SIDs for subdivided link resources

draft-peng-teas-network-slicing described slice related resource partition and corresponding SID allocation.

All of these solutions follow the existing SR architecture. Thus it is not the truth that we all think that the existing SR architecture does not cover allocating resource-awareness SID and explicitly resource capability or semantic need to be defined.

I believe there will be more SR based solution in the future. For simplicity and refinement, we can not paint the lily to change the existing architecture at will, ignoring the fact that it can work and perfect support for every solutions. Otherwise, for some purpose, someone can also persist that the SR architecture lacks service meanning, application meaning, intent meanning, etc, then more and more unnecessary X-awareness framework appear. 

 

So let us focus on specific solutions, i.e, just like what is done in flex-algo or other documents, detailed control extension and forwarding mechanism for virtual network (yes ,you can say this doc is not only for virtual network, but this is exactly what makes me confused. It is not clear for other purpose) . A new X-awareness framework is really unnecessary, except for standard strategy.






Regards,


PSF

















原始邮件



发件人:li_zhenqiang@hotmail.com <li_zhenqiang@hotmail.com>
收件人:陈然00080434;Dongjie (Jimmy) <jie.dong@huawei.com>;
抄送人:James Guichard <james.n.guichard@futurewei.com>;spring@ietf.org <spring@ietf.org>;spring-chairs@ietf.org <spring-chairs@ietf.org>;
日 期 :2020年07月21日 12:48
主 题 :Re: [spring] WG AdoptionCallfordraft-dong-spring-sr-for-enhanced-vpn


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


Hi Ran,


 


Thank you very much for your interests in and comments on this draft.






Yes, you are right that SR architecture supports resource related SIDs. So we can specify the resource related framework under SR architecture.  This is the main purpose of this doc. RFC8402 supports resource related SIDs, but doesn't  define them, which are defined in this doc.






However, I am afraid I can not agree with you that this doc is mainly to manage and maintain virtual network resources.  The concept and mechanism of resource-awareness SID is introduced in this doc to enrich the semantics of SR SID and to enhance the SR architecture. Thanks to its flexibility and extensibility.


Resource related SIDs introduced in this doc can be used to construct virtual networks, resource isolated pathes, dedicated queques in one node and so on, which depends on the application scenarios. 






Since this draft belongs to SPRING WG, IMO it is correct that it focuses the semantics and functions associated with SR SIDs. The identifier and mechanisms in control plane could be discussed in the corresponding protocol WGs as next step. Please pay attention to our related work in the protocol WGs and you are welcome to present your comments there... Thanks alot.


 


Best regards,


Zhenqiang Li




--------------------------------------------------------------------------------

li_zhenqiang@hotmail.com


 

From: chen.ran@zte.com.cn
Date: 2020-07-20 17:11
To: jie.dong@huawei.com
CC: james.n.guichard; spring; spring-chairs
Subject: Re: [spring]WG Adoption Callfordraft-dong-spring-sr-for-enhanced-vpn





Hi Jie,


IMO, the essence of the problem is that an identifier should be introduced to manage and maintain virtual network resources,  not whether it is necessary to allocate resource related SIDs , because the current SR architecture already supports resource related SIDs allocation, there is no limit to that. For example, service SID (compuated resource related), Node/Adjacency SID(topological resource related), etc. Especially, SRv6 SID encourages programming anything. Can we say that these SIDs have no resource meaning?


Thus, draft-dong-spring-sr-for-enhanced-vpn does not introduce any new content on the existing SR architecture.






For identifier to manage and maintain virtual network resources, draft-peng-teas-network-slicing firstly to introduce a new identifier (AII) in the network to unifiedly identify the topology, computing and storage resource. Before that, other existing identities only focus on topology resources.






Just for topology related resource, Segment Routing with MTR/Flex-algo/AII all support the division of multiple topological resource, and already support allocatoin of SID per MT-ID/algorithm/AII. Especially for link resource, the bandwidth of the same link can be subdivided into multiple resources. 


If these subdivided resources exist in the form of sub-interface resources, L2-bundles(rfc8668) provides the method to assign adjacency-SID for members, In other words, the allocation of member adjacency SID has already been aware of these subdivided resources, each sub-interface has its own link attributes (bandwidth, delay, etc.). 


If there are no sub-interface, the link can also be shared by multiple virtual networks to allocate multiple adjacency SIDs. Under the existing SR architecture, draft-peng-teas-network-slicing and draft-peng-lsr-algorithm-related-adjacency-sid have already described the allocation of adjacency SID per AII and algorithm.






Obviously, the above SR with MTR/Flex-algo/AII are all complete solutions, including control plane extensions and forwarding mechanisms, and they need not make any changes to the SR architecture.


I wonder according to draft-dong-spring-sr-for-enhanced-vpn, what can we do under its guidance, or what we can't do without this draft? 






Regards,


Ran
















发件人:Dongjie(Jimmy) <jie.dong@huawei.com>
收件人:陈然00080434;james.n.guichard@futurewei.com <james.n.guichard@futurewei.com>;spring@ietf.org <spring@ietf.org>;
抄送人:spring-chairs@ietf.org <spring-chairs@ietf.org>;
日 期 :2020年07月16日 19:50
主 题 :RE: [spring] WG Adoption Callfordraft-dong-spring-sr-for-enhanced-vpn




Hi Ran,


 


Thanks for your comments. While I don’t quite get your point of objection.  Perhaps you have some misunderstanding about the relationship of the
 drafts mentioned.


 


RFC 8402 introduced the topology and service semantics of SR SID, this document proposed to add resource semantics to SIDs. Then MT or Flex-Algo
 are control plane mechanism for the distribution of topology-specific SIDs... The relationship with these documents are described in this draft.


        


My reading of draft-peng in LSR and TEAS is that they may provide an option of control plane extensions for the resource-aware SIDs defined in this
 document, which just proves that the enhancement in this document is in the right direction, and more work based on it could be done in relevant WGs.


 


Thus my suggestion would be to have the SR enhancement adopted in SPRING first, then more discussion about its control plane could happen in other
 WGs as the next step.  


 


Hope this helps.


 


Best regards,


Jie


 




From: spring [mailto:spring-bounces@ietf.org]On Behalf Of chen.ran@zte.com.cn
Sent: Thursday, July 16, 2020 5:20 PM
To: james.n.guichard@futurewei.com; spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption Call fordraft-dong-spring-sr-for-enhanced-vpn




 

Dear WG,


I don't support WG adoption.


It is not a new idea for each Virtual Network to have its own SIDs.


e.g. The earlist description of the SID be allocated per flex-algorithm and related metric


 information was in draft-hegdeppsenak-isis-sr-flex-algo-00(2017.7.17) (now is draft-ietf-isis-sr-flex-algo) . 


The earlist description of the SID be allocated per MT was in draft-filsfils-spring-segment-routing-04(2014.7...3)


(now is RFC8402 ), and draft-peng-lsr-network-slicing-00(2019.2.25) describe the


SID be allocated per AII(alias alice).  For slice resources,https://tools.ietf.org/html/draft-peng-teas-network-slicing-03  


induced slice-id(AII) for slice resources management, and can differentiate them (e.g. L2 link or L3 interface,


section 7 ), and how to compute SR-BE or SR-TE path according to AII combined with other criteria.


 


Regards,


Ran

 


-----Original Message-----
From: spring <spring-bounces@ietf.org> On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 8:17 PM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

  

This email begins a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ <https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/>  ending Wednesday 29th July 2020.  

  

Please speak up if you support or oppose adopting this document into the WG. Please also provide comments/reasons for that support (or lack thereof). Silence will not be considered consent.

  

Thanks!

  

Jim, Joel & Bruno

  

  

  


_______________________________________________
spring mailing list
spring@ietf.org