Re: [spring] [EXTERNAL] Re: Intended status of draft-ietf-spring-resource-aware-segments

[Gyan Mishra <[e-mail]>]

Jie mentioned the same and are are in sync.

Thanks

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*



On Fri, Jan 26, 2024 at 1:07 AM Alexander Vainshtein <
[e-mail]> 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 <[e-mail]>
> *Sent:* Friday, January 26, 2024 2:44:55 AM
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* Acee Lindem <[e-mail]>; Dongjie (Jimmy) <jie.dong=
> [e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>
> *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 [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347 *
>
>
>
> On Tue, Jan 23, 2024 at 4:00 AM Alexander Vainshtein <
> [e-mail]> 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 <[e-mail]>
>> *Sent:* Tuesday, January 23, 2024 8:02 AM
>> *To:* Dongjie (Jimmy) <jie.dong=[e-mail]>
>> *Cc:* Alexander Vainshtein <[e-mail]>;
>> [e-mail]; [e-mail]
>> *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 [e-mail] <[e-mail]>*
>>
>> *M 301 502-1347*
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jan 22, 2024 at 3:39 AM Dongjie (Jimmy) <jie.dong=
>> [e-mail]> 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:[e-mail] <[e-mail]>]
>> *On Behalf Of *Alexander Vainshtein
>> *Sent:* Sunday, January 21, 2024 2:16 PM
>> *To:* [e-mail]
>> *Cc:* [e-mail]
>> *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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>>
>