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). 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. 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. 1. 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? 1. 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. 1. 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. 1. 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. 1. 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. I look forward to responses from the authors and updates to the document to address these comments. Thanks, Ketan From: spring <spring-boun...@ietf.org> On Behalf Of James Guichard Sent: 15 July 2020 16:47 To: spring@ietf.org Cc: spring-cha...@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/ 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 https://www.ietf.org/mailman/listinfo/spring
