Hi Sasha, Gyan, I agree with Sasha. I’d add that I don’t think any information related to the resources associated with the SID should be encoded in the IGPs.
Thanks, Acee > On Jan 23, 2024, at 04:00, Alexander Vainshtein > <alexander.vainsht...@rbbn.com> wrote: > > 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 ishighlighted): > > 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 > > <~WRD0666.jpg> <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
