Jie mentioned the same and are are in sync. Thanks
<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 Fri, Jan 26, 2024 at 1:07 AM Alexander Vainshtein < alexander.vainsht...@rbbn.com> wrote: > Gyan, > Lots of thanks for your email. > > Looks as we are now in sync. > > As explained in my other mail > <https://mailarchive.ietf.org/arch/msg/spring/K4-yldPkaKOMiChxf3CrvwCrHko/>, > I see this draft as a framework document to be augmented by specific > Standards Track documents defining specific solutions. > > Regards, > Sasha > > > > Regards, > Sasha > > Get Outlook for Android <https://aka.ms/AAb9ysg> > > ------------------------------ > *From:* Gyan Mishra <hayabusa...@gmail.com> > *Sent:* Friday, January 26, 2024 2:44:55 AM > *To:* Alexander Vainshtein <alexander.vainsht...@rbbn.com> > *Cc:* Acee Lindem <acee.i...@gmail.com>; Dongjie (Jimmy) <jie.dong= > 40huawei....@dmarc.ietf.org>; > draft-ietf-spring-resource-aware-segme...@ietf.org < > draft-ietf-spring-resource-aware-segme...@ietf.org>; spring@ietf.org < > spring@ietf.org> > *Subject:* Re: [EXTERNAL] Re: [spring] Intended status of > draft-ietf-spring-resource-aware-segments > > > Hi Sasha > > Agreed with everything you stated that the draft does not propose any > extension to existing topological SIDs and no IANA requests. > > So what I stated below was referring to maybe a future draft TBD to be > developed in LSR that would have an OSPF and ISIS TLV encoding for the > resource segment information discussed in this daft and that possible new > draft would have IANA code point and would 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. > > > 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 Tue, Jan 23, 2024 at 4:00 AM 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 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> >> *Sent:* Tuesday, January 23, 2024 8:02 AM >> *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:* [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: Image removed by sender.] <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
