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) <[email protected]>
收件人:陈然00080434;[email protected] 
<[email protected]>;[email protected] <[email protected]>;
抄送人:[email protected] <[email protected]>;
日 期 :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:[email protected]]On Behalf Of [email protected]
Sent: Thursday, July 16, 2020 5:20 PM
To: [email protected]; [email protected]
Cc: [email protected]
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 <[email protected]> On Behalf Of James Guichard
Sent: Wednesday, July 15, 2020 8:17 PM
To: [email protected]
Cc: [email protected]
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
[email protected]
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to