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 <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <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> 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 <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 > *Cc:* 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. > > > 1. The details of the underlay network MUST NOT be exposed to third > parties, to prevent attacks aimed at exploiting shared network resources > 2. 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 > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
