Hi Sasha, Thanks for sharing your view and position on this draft. I think we are aligned on the concept and content of the resource-aware segments draft.
As coauthor we are open to the WG’s decision on the document type of the resource-aware segments draft. While there is another document which is about using resource-aware segments for realizing NRP/VTN (draft-ietf-spring-sr-for-enhanced-vpn), following this discussion, to my understanding that draft defines a specific solution and may be better positioned as standard track. What do you think? Best regards, Jie From: Alexander Vainshtein [mailto:alexander.vainsht...@rbbn.com] Sent: Wednesday, January 24, 2024 5:04 PM To: Dongjie (Jimmy) <jie.d...@huawei.com> Cc: draft-ietf-spring-resource-aware-segme...@ietf.org; spring@ietf.org; Acee Lindem <acee.i...@gmail.com>; Gyan Mishra <hayabusa...@gmail.com> Subject: RE: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments Jie, Lots of thanks for your mail. I would like to clarify my position regarding the draft: 1. I think that the concept of resource aware SIDs is a very useful construct that can be used in network slicing and, probably, in other ways. 2. My perception of the draft is that it is a kind of a very useful framework document: it does not define any specific solution but provides common architectural ground for development of such solutions. E.g., a centralized controller mentioned in the draft that would be responsible for associating specific topological DIDs with specific resources would require appropriate protocol extensions, encoding etc. Therefore, I think that Informational would be the most appropriate status for this draft (and for the RFC to which it hopefully will be progressed), while the documents defining specific solutions should, of course, be on the Standards Track. 3. In any case, I have simply been trying to present my position to the authors and to the WG. It is up to the WG (and, eventually, to the IESG when the draft is submitted for publication) to decide whether the Standards Track or Informational status is more appropriate. Regards, Sasha From: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>> Sent: Wednesday, January 24, 2024 10:37 AM To: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> Cc: draft-ietf-spring-resource-aware-segme...@ietf.org<mailto:draft-ietf-spring-resource-aware-segme...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; Acee Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> Subject: RE: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments Hi Sasha, Please see my reply to Gyan about his point on the “extension encoding”. This document does not change the encoding of SR SIDs, the change is in the semantics of the SIDs, and consequently the forwarding behavior of the resource-aware SIDs will be a little bit different from the normal SID, as the SID also identifies a specific set of resources used to execute the packet processing action. This may be a subtle change/update to SR, while it would be good if this could be reflected by the document type. The text you quoted below shows that the resource-aware SIDs may be allocated per <topology, algorithm> tuple, and it is also possible that multiple resource-aware SIDs are associated with the same <topology, algorithm> tuple, in which case a new distinguisher in the control plane is needed. In both cases, the resource-aware SIDs would be associated with a set of network resource. The difference is the scalability implication and the control plane mechanisms used. For some network scenarios, existing control protocol mechanisms can be reused, while for some other network scenarios (e.g. for better scalability), some control plane extensions may be needed. The resource-aware segments concept is generic, and realization of NRP/VTN is just one application of it. As an example, you can find it is referenced by drafts such as draft-dong-lsr-sr-enhanced-vpn. Hope this helps. Best regards, Jie From: Alexander Vainshtein [mailto:alexander.vainsht...@rbbn.com] Sent: Tuesday, January 23, 2024 5:00 PM To: Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> Cc: draft-ietf-spring-resource-aware-segme...@ietf.org<mailto:draft-ietf-spring-resource-aware-segme...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; Acee Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> Subject: RE: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments Gyan, and all, I have re-read the draft<https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-08>, but I did not find any proposals for “a new resource attributes extension encoding to existing topological SIDs”. The draft explicitly states that it does not involve any requests to IANA. The quoted fragment in Section 2.1 suggests that such attributes may be used (the relevant text is highlighted): For one IGP prefix, multiple resource-aware prefix-SIDs can be allocated. Each resource-aware prefix-SID may be associated with a unique <topology, algorithm> tuple, in this case different <topology, algorithm> tuples can be used to distinguish the resource-aware prefix-SIDs of the same prefix. In another case, for one IGP prefix, multiple resource-aware prefix-SIDs may be associated with the same <topology, algorithm> tuple, then an additional control plane distinguisher needs to be introduced to distinguish different resource-aware prefix-SIDs associated with the same <topology, algorithm> but different groups of network resources. But I doubt this rather vague statement justifies the draft going for Standards Track. Not have I found any references to the drafts with intended status Standards Track that define any protocol extensions you mention. You may also take a look at this email<https://mailarchive.ietf.org/arch/msg/teas/jvKe3cmJzgC8rtdXLB3xU9Yax5E> from Acee (in the TEAS WG mailing list) . What, if anything, did I miss? Regards, and lots of thanks in advance, Sasha From: Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> Sent: Tuesday, January 23, 2024 8:02 AM To: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org<mailto:jie.dong=40huawei....@dmarc.ietf.org>> Cc: Alexander Vainshtein <alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>; draft-ietf-spring-resource-aware-segme...@ietf.org<mailto:draft-ietf-spring-resource-aware-segme...@ietf.org>; spring@ietf.org<mailto:spring@ietf.org> Subject: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments Hi Jie I understand the draft proposes an extension to existing topological SIDs to carry the resource attributes. However since this draft proposes a new resource attributes extension encoding to existing topological SIDs I agree this should be standards track. Since the topological segments are advertised by IGP OSPF or ISIS, I am guessing you would have a standards track draft in LSR that encodes the resource segments and could update the existing SR-MPLS and SRv6, OSPF and ISIS RFCs / drafts. You could possibly mention the proposed encoding scheme and fields and that detail would be integrated into the IGP draft. Another option would be to introduce new resource aware SIDs that is NRP centric that would be applicable to both SR-MPLS and SRv6 but would be independent of topological or service SID so not at that layer. The resource SID would be associated with the BSID that binds the single or multiple candidate path to the forwarding plane and instantiates the path. So for SR-MPLS it would be the entire label stack pushed onto the packet when the BSID is popped. For SRv6 it would be SRH segment list associated with the candidate paths. In this option you would have a standards track draft in LSR that encodes the resource segments and could update the existing SR-MPLS and SRv6, OSPF and ISIS RFCs / drafts. The contents of the resource SID would now apply to the NRP and would be as you described, buffers, queues, bandwidth, SLO and SLE parameters such as latency and jitter for NRP network slice. Kind Regards [Image removed by sender.]<http://www.verizon.com> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347 On Mon, Jan 22, 2024 at 3:39 AM Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi Sasha, Thanks for the review and comment on this document. Although this draft does not introduce new SR segment type/SRv6 behavior, there is change in the semantics and forwarding behavior of the resource-aware segments, as each resource-aware SIDs identifies a subset of the network resources used for packet processing. Thus the authors consider this document belong to standard track. That said, the usage of IETF keywords in current version needs to be revisited and adjusted if needed. Of course we would like to hear the opinions from the WG participants, and follow the decision of the WG. Best regards, Jie From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein Sent: Sunday, January 21, 2024 2:16 PM To: draft-ietf-spring-resource-aware-segme...@ietf.org<mailto:draft-ietf-spring-resource-aware-segme...@ietf.org> Cc: spring@ietf.org<mailto:spring@ietf.org> Subject: [spring] Intended status of draft-ietf-spring-resource-aware-segments Hello, I have read the draft<https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-08>, and I do not have any technical comments on it. At the same time, I wonder why its intended status appears as “Standard Track”: 1. The draft does not define any new mechanisms in the data plane or control plane 2. Usage of the IETF keywords denoting requirement levels looks too vague/generic to me, e.g. a. The details of the underlay network MUST NOT be exposed to third parties, to prevent attacks aimed at exploiting shared network resources b. If there are related link advertisements, then consistency MUST be assured across that set of advertisements IMHO and FWIW the draft describes how resource-aware forwarding can be achieved using various already-defined SR mechanisms. Have the authors and/or the WG considered changing the intended status of the draft to “Informational”? Regards, Sasha Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments. _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
