Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

["Dongjie (Jimmy)" <[e-mail]>]

Hi Ketan,

Thanks for your comment and support. Please see some replies inline:

From: spring [mailto:[e-mail]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Friday, July 24, 2020 2:27 AM
To: James Guichard <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn


Hi All,



This document seems to talk of "resource group" SIDs that is something interesting - specifically for SR-MPLS (I don't see the same relevance for SRv6).



[Jie] SR-MPLS is used in the example described in this document, while the concept of resource-aware SID is generic to SR, and can be applicable to both SR-MPLS and SRv6.



I support the adoption of (what is coming across to me as) this concept of a new "resource group" scope for SR SIDs as a work item for the Spring WG. Rest should be moved into a separate informational document since all of that seem unrelated, nothing new and not suitable for a standards track document.



[Jie] Thanks for supporting the introduction of resource semantics to SR SIDs.



A group of SR SIDs with such semantics can be used to build resource guaranteed SR paths or virtual networks. The mechanism and procedure for resource guaranteed virtual network is highlighted because the advantage of SR (no per-path state) can be utilized in per-virtual network resource allocation, which is more scalable than the per-path resource reservation in RSVP-TE. Thus it is an important and integral part of this document, as is reflected in the document title.



Therefore, the draft needs more work before it is ready for adoption.



Following are my more specific comments on this draft:



1)      SR SIDs that are scoped to a MT or Algo or MT+Algo combination can already be associated with some "resources" on routers today. There is nothing new here to be standardized. If there is interest in the WG for documenting how resources are carved out and assigned to say a Flex-Algo and/or MT scoped SIDs, it should be in an independent informational document. There seems to be a lot of overlap of this with work in the TEAS WG. Much of Section 2 seems to be of this nature.



[Jie] In this document resource refers to the data plane resource for packet processing and forwarding, which is not covered in the existing MT/Algo mechanism. As stated in this document, MT/Algo or the combination can be used as the control plane for advertising the topology and the resource attributes of the virtual network, the details of the control plane mechanism and extensions are specified in separate documents.



2)      IGP SR SIDs are today scoped to an MT and Algo. This draft seems to be introducing another "resource group" type of scoping within an MT+Algo context for Prefix and Adjacency SIDs. When packets using SID labels belonging to a "resource group" arrive at a router, it helps the router associate those service flows to the QoS profile provisioned for that "resource group" on that specific link/router. This is what it seems is the whole essence of the proposal - but this is not clear in the document.  The routing of these SIDs is going to follow whatever MT and/or FlexAlgo computation provides - therefore, I am not sure I understand how these "resource group" SIDs are creating some new "Virtual Network Topology". Isn't this just a "network slice" of resources?



[Jie] As defined in section 1, the resource semantic is one additional dimension represented by SIDs, which means the SID can be used to represent topology or function, together with the set of resources used to process the packet according to the function. The forwarding behavior of SIDs with both topology and resource semantics are described in section 2. In summary, the topology and resource are two aspects of the virtual network described in this document.



3)      I am not sure how the discussion in Section 3 is bringing in anything new and again it is purely informational in nature.. Perhaps I am not able to follow the point.



[Jie] It provides an overview of the associated control plane mechanisms, which is useful information to correlate this document and the control plane mechanisms needed. The details are provided in the control plane drafts in corresponding WGs.



4)      Much of Section 4 is also similarly informational in nature and about how some vendor/operator may want to use "resource group" SIDs. However, it does not formally and normatively define this new concept of "resource group" SIDs.  Other implementations and operators may choose to do this differently - so why standardize this one way? Discussion like assigning/allocation of SIDs, distribution of their information and setting up paths through the network using these SIDs are basic concepts of SR - not sure if they need description and repetition in a standards track document.



[Jie] This section provides the procedures of using resource-aware SIDs to build resource guaranteed virtual networks. These are based on the existing SR mechanism with procedures related to the allocation of resource-aware SIDs and the generation of corresponding forwarding entries. The procedure and example in this section is helpful for understanding the relationship and difference from the existing SR mechanism.



5)      Section 5, Scalability is not giving the right picture. The proposal ends replicating each SID label forwarding entry (e..g. for prefix SID) multiplied by each "resource group" on each router simply for the sake of identifying QoS resources for it. That is not really scalable and will end up consuming a large set of label forwarding entries on the routers depending on the network scale and now many of these "slices" are instantiated.



[Jie] It is stated in section 2 that additional SR SIDs are needed to identify the topology and resource associated with different virtual networks. The scalability discussion in section 5 compares the SR based approach with the existing RSVP-TE approach, and shows the benefit of using SR for building resource guaranteed virtual networks. For further scalability considerations about the number of virtual networks and its impact, please refer to draft-dong-teas-enhanced-vpn-vtn-scalability.



6)      Finally, I have an objection to the use of terms like "enhanced VPN" and "VPN+" in the document that sound more like marketing terms than technical terminologies.. There was a similar comment made by one of the Spring chairs for a previous version, but I don't see it being addressed. VPNs might be but one of the services that can leverage the resource aware SIDs in their underlay.



[Jie] The enhanced VPN (VPN+) framework is developed and adopted in TEAS, which aims to provide enhanced VPN service based on VPN and TE technologies with possible enhancements. Thus enhanced VPN is IETF work in progress,  Providing enhanced VPN service is the motivation of this draft, while as commented by chairs and agreed by coauthors, we have been working to make this document focusing on the enhancement to SR.



The comments from SPRING chair has been resolved in recent updates of the draft. In current version enhanced VPN is just mentioned as one service of the SR virtual network.



I look forward to responses from the authors and updates to the document to address these comments.



[Jie] Hope my above replies help to solve your comments. And as this document is just in WG adoption, it could be polished further after the adoption.



Best regards,

Jie



Thanks,

Ketan


From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of James Guichard
Sent: 15 July 2020 16:47
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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/ 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