Hi Jie Responses in-line Gyan>
<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 Wed, Jan 24, 2024 at 2:57 AM Dongjie (Jimmy) <jie.d...@huawei.com> wrote: > Hi Gyan, > > > > Thanks for sharing your thoughts on this document. > > Gyan> Welcome > > I agree with you that in this document the semantics of the existing SR > SIDs (the topological SIDs in your text) are extended to “topology/function > + resource”, thus the forwarding behavior of the resource-aware SIDs will > be a little bit different from the normal SID. While the encoding of the SR > SIDs are still unchanged. This may be a subtle change/update to SR, while > it would be good if this could be reflected by the document type. > > Gyan> So with that subtle change/update to SR control plane in my email > was referring to maybe an LSR draft for the resource sid extension TLV > encoding of the resource information. > As for the control plane mechanisms to advertise the resource-aware SIDs > and their associated resource attributes, there can be either solutions > which reuse existing protocol mechanisms, or protocol extensions may be > introduced for the enhancements of capability for some scenarios. That has > been discussed in TEAS and the corresponding control protocol WGs, and > hopefully that discussion will continue there. > > Gyan> Understood. So one way would be an IGP extension however due to > the subtle change their could be other methods to accomplish how to encode > the resource sid extension information. > > Hope this helps to align our understanding on this document. > > Gyan> Yes Thank you > > Best regards, > > Jie > > > > *From:* Gyan Mishra [mailto:hayabusa...@gmail.com] > *Sent:* Tuesday, January 23, 2024 2:02 PM > *To:* Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> > *Cc:* Alexander Vainshtein <alexander.vainsht...@rbbn.com>; > draft-ietf-spring-resource-aware-segme...@ietf.org; spring@ietf.org > *Subject:* 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: 图像已被发件人删除。] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *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. > > 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 > https://www.ietf.org/mailman/listinfo/spring > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
