From hayabusagsm@gmail.com Thu Jan 25 16:44:40 2024 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3FC14F6F4; Thu, 25 Jan 2024 16:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.102 X-Spam-Level: X-Spam-Status: No, score=-7.102 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2STA7LQYtwNQ; Thu, 25 Jan 2024 16:44:36 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344EFC14F60D; Thu, 25 Jan 2024 16:44:36 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-290b9f83037so1011029a91.1; Thu, 25 Jan 2024 16:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706229875; x=1706834675; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=stmPij2fGnTv/V5ZbMqcmBGYnIent1kJOBw48KXd2D4=; b=Q9c8Q8mqF4wIS5Ngc0Krk92jTJhe3Zr5bjOs7Lx/9YeLnL3xu71cGnJAsNfwjshG2U gy9twsnaDn3Cml7zdVnp77nUOfreMxld+TZiMr+RAWIjSkNZ8T8Gi9F76W9L6SmwiHJo akx7deDTUaXaucEqOmZBUxaoypiYaq0IXiiIAGu2dvwYBwXhIis2QXvJ48KW4Tp83UvU vcOO3VW6saSrhN56AOYt5Uya6nwVSt0+B9VIGlFZQGgG9KmukqXQGjbvolwPHTyqMWu/ Bh6Pki3ftSNCOLTUE8a/a91TgOMiWjJs4xlp82L5WxcsiNud86ZGyAq6L4l+NIyCwpfl MAkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706229875; x=1706834675; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=stmPij2fGnTv/V5ZbMqcmBGYnIent1kJOBw48KXd2D4=; b=Q+AqCX+h1hsqX+G+ANrrd1hT75PXcrnZySq5eMle8clJwsYeNVlJnP/S7Uqyo/5dLG 6D/EeQEnW0L3K6WtJcrs8qR3n/7CX43V83p9zIgoGzjJG9jaXS4GPq/3g6URcqGseu1P 0/b53E5+/lCdMIlTFS0PjaOb7LddVM1ZXFHp6cPUNGcCexCZPrCT+qx4h5TEFO2aBHGq plktwRUvtzHSUOjd1eIS9zbPkrWL7QO88RWuv9RtlpI9UxJoUgkQVGA6FsUAIYLYhK/H jVis0ompDarBOju2vC7H/vOLZWbRtOqkL+O5h1bG1FwRROl3Tg0jeSYp6gshl2kRyf1w FKZA== X-Gm-Message-State: AOJu0Yz3oM4P4QNOstPiy8XjcDvNDc+D3W+6Ze4n3pov4c517kohVOQa j2xH13KLxqEXXd2FZyEY+aRZk4SSkoe4W/98pWiIN6sh4cwc+AvoDZOR2pYHimV2Yo+sQTNVDOS MB5oWGKI8Ri6bykmLOj87rhWQfK8= X-Google-Smtp-Source: AGHT+IGrxN4BxLjfClNLOsF9o42C9/oORu4MdLH6+Izax1Rwg1dIO8CxFf7zaIXpLoMRoNIYfSM3Asv0ZdSVT1asVvg= X-Received: by 2002:a17:90a:f317:b0:28e:75bd:45c2 with SMTP id ca23-20020a17090af31700b0028e75bd45c2mr196244pjb.6.1706229875336; Thu, 25 Jan 2024 16:44:35 -0800 (PST) MIME-Version: 1.0 References: <2e572c01c2b94a738dc86b8c8f9e8305@huawei.com> In-Reply-To: From: Gyan Mishra Date: Thu, 25 Jan 2024 19:44:22 -0500 Message-ID: To: Alexander Vainshtein Cc: Acee Lindem , "Dongjie (Jimmy)" , "draft-ietf-spring-resource-aware-segments@ietf.org" , "spring@ietf.org" Content-Type: multipart/related; boundary="000000000000a0a407060fce990e" Archived-At: Subject: Re: [spring] [EXTERNAL] Re: Intended status of draft-ietf-spring-resource-aware-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2024 00:44:40 -0000 --000000000000a0a407060fce990e Content-Type: multipart/alternative; boundary="000000000000a0a405060fce990d" --000000000000a0a405060fce990d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* On Tue, Jan 23, 2024 at 4:00 AM Alexander Vainshtein < Alexander.Vainshtein@rbbn.com> wrote: > Gyan, and all, > > I have re-read the draft > , > but I did not find any proposals for =E2=80=9C*a new resource attributes > extension encoding to existing topological SIDs*=E2=80=9D. The draft exp= licitly > 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 algorithm> tuple, in this case different 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 tuple, then an addition= al > control plane distinguisher needs to be introduced to distinguish differe= nt > resource-aware prefix-SIDs associated with the same > 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 > > 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 > *Sent:* Tuesday, January 23, 2024 8:02 AM > *To:* Dongjie (Jimmy) > *Cc:* Alexander Vainshtein ; > draft-ietf-spring-resource-aware-segments@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 an= d > 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 associate= d > 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, OSP= F > 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 suc= h > as latency and jitter for NRP network slice. > > > > Kind Regards > > > [image: Image removed by sender.] > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > > > > > On Mon, Jan 22, 2024 at 3:39 AM Dongjie (Jimmy) 40huawei.com@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, an= d > follow the decision of the WG. > > > > Best regards, > > Jie > > > > *From:* spring [mailto:spring-bounces@ietf.org ]= *On > Behalf Of *Alexander Vainshtein > *Sent:* Sunday, January 21, 2024 2:16 PM > *To:* draft-ietf-spring-resource-aware-segments@ietf.org > *Cc:* spring@ietf.org > *Subject:* [spring] Intended status of > draft-ietf-spring-resource-aware-segments > > > > Hello, > > I have read the draft > , > and I do not have any technical comments on it. > > At the same time, I wonder why its intended status appears as =E2=80=9CSt= andard > Track=E2=80=9D: > > 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 =E2=80=9CInformational=E2=80=9D? > > > > 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 copie= s, > including any attachments. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --000000000000a0a405060fce990d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Sasha=C2=A0

Agreed with everything you stated that the = draft does not propose any extension to existing topological SIDs and no IA= NA requests.

So what I s= tated below was referring to maybe a future draft TBD to be developed =C2= =A0in LSR that would have an OSPF and ISIS TLV encoding for the resource se= gment information discussed in this daft and that possible new draft would = have IANA code point and would be standards track.

S= ince the topological segments are advertised by IGP OSPF or ISIS, I am gues= sing you=C2=A0would have a standards track draft= in LSR=C2=A0that encodes the resource segments and cou= ld update the existing SR-MPLS and SRv6, OSPF and ISIS RFCs / drafts.


Kind Regards=C2=A0
=

<= a href=3D"http://www.verizon.com/" style=3D"padding-bottom:1em;display:inli= ne-block;color:rgb(17,85,204)" target=3D"_blank">

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com=

M 301= 502-1347




On Tue, Jan 23, 2024 at= 4:00 AM Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> wrote:
<= /div>

Gyan, and all,=

I have re-read the draft, but I did not find any proposals for =E2=80=9Ca new re= source attributes extension encoding to existing topological SIDs=E2=80= =9D.=C2=A0 The draft explicitly states that it does not involve any request= s to IANA.

=C2=A0

The quoted fragment in Section 2.1 suggests that suc= h attributes may be used (the relevant text is highlighted):<= /p>

=C2=A0

For one IGP prefix, multiple reso= urce-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 us= ed to distinguish the resource-aware prefix-SIDs of the same prefix. In another case, for one IGP prefix, multiple resource-aware prefix-SIDs m= ay be associated with the same <topology, algorithm> tuple, then an a= dditional control plane distinguisher needs to be introduced to distinguish different resource-aware prefix-SIDs associated with the sa= me <topology, algorithm> but different groups of network resources.

=C2=A0<= u style=3D"font-family:"Courier New"">

But I doubt this rath= er vague statement justifies the draft going for =C2=A0Standards Track.<= /u>

=C2=A0<= /span>

Not have I found any = references to the drafts with intended status Standards Track that define a= ny protocol extensions you mention.=C2=A0 You may also ta= ke a look at this email from Acee (in the TEAS WG =C2=A0mailing list) .

=C2=A0<= /span>

What, if anything, di= d I miss?

=C2=A0<= /span>

Regards, and lots of = thanks in advance,

Sasha

=C2=A0<= /span>

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Tuesday, January 23, = 2024 8:02 AM
To: Dongjie (Jimmy) <jie= .dong=3D40huawei.com@dmarc.ietf.org><= br> Cc: Alexander Vainshtein &l= t;Alexander.Vainshtein@rbbn.com>; <= a href=3D"mailto:draft-ietf-spring-resource-aware-segments@ietf.org" style= =3D"font-family:Calibri,sans-serif" target=3D"_blank">draft-ietf-spring-res= ource-aware-segments@ietf.org; spring@ietf.org Subject: [EXTERNAL] Re: [sp= ring] Intended status of draft-ietf-spring-resource-aware-segments

=C2=A0

=C2=A0

Hi Jie

=C2=A0

I understand the draft pr= oposes an extension to existing topological SIDs to carry the resource attr= ibutes.

=C2=A0

However since this draft = proposes a new resource attributes extension encoding to existing topologic= al SIDs I agree this should be standards track.

=C2=A0

Since the topological seg= ments 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 existin= g SR-MPLS and SRv6, OSPF and ISIS RFCs / drafts.

=C2=A0

You could possibly mentio= n the proposed encoding scheme and fields and that detail would be integrat= ed into the IGP draft.

=C2=A0

Another option would be t= o introduce new resource aware SIDs that is NRP centric =C2=A0that would be= applicable to both =C2=A0SR-MPLS and SRv6 but would be independent of topo= logical or service SID so not at that layer.=C2=A0 The resource SID would be associated with the BSID that binds the single o= r multiple candidate path to the forwarding plane and instantiates the path= .=C2=A0 So for SR-MPLS it would be the entire label stack pushed onto the p= acket when the BSID is popped.=C2=A0 For SRv6 it would be SRH segment list associated with the candidate paths.

=C2=A0

In this option=C2=A0you would hav= e a standards track draft in LSR that encodes the resource segments and cou= ld update the existing SR-MPLS and SRv6, OSPF and ISIS RFCs / drafts.

=C2=A0

The contents of the resource SID = would now apply to the NRP and would be as you described, buffers, queues, = bandwidth, SLO and SLE =C2=A0parameters such as latency and jitter for NRP network slice.

=C2=A0

Kind Regards=C2=A0=


3D"Image

Gyan Mishra

Network Solutions = Architect=C2=A0

Ema= il gyan.s.mishra@verizon.com

M 301 502-1347

=C2=A0

=C2=A0

=C2=A0

On Mon, Jan 22, 2024 at 3= :39 AM Dongjie (Jimmy) <jie.dong=3D40huawei.com@dmarc.ietf.org> wrote:

Hi Sasha,

=C2=A0

Thanks for the review and comment on this document.

=C2=A0

Although this draft does not introduce new SR segment type/SRv6 b= ehavior, there is change in the semantics and forwarding behavior of the re= source-aware segments, as each resource-aware SIDs identifies a subset of the network r= esources used for packet processing.

=C2=A0

Thus the authors consider this document belong to standard track.= That said, the usage of IETF keywords in current version needs to be revis= ited and adjusted if needed.

=C2=A0

Of course we would like to hear the opinions from the WG particip= ants, and follow the decision of the WG.

=C2=A0

Best regards,

Jie

=C2=A0

From: spring [m= ailto:spring-bounces@ietf.org] On Behalf Of Alexander Vain= shtein
Sent: Sunday, January 21, 2= 024 2:16 PM
To: draft-ietf-spring-resource-aware-segments@ietf.org
Cc: spri= ng@ietf.org
Subject: [spring] Intended = status of draft-ietf-spring-resource-aware-segments<= /u>

=C2=A0

Hello,

I have read the draft, =C2=A0and I do not have any technical comments on it.<= /u>

At the same time, I wonder why its intended status appears as =E2=80=9CStandard Track=E2= =80=9D:

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The draft does n= ot define any new mechanisms in the data plane or control plane

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Usage of the IET= F keywords denoting requirement levels looks too vague/generic to me, e.g.<= u>

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The details of t= he underlay network MUST NOT be exposed to third parties, to prevent attack= s aimed at exploiting shared network resources

b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If there are rel= ated link advertisements, then consistency MUST be assured across that set = of advertisements

=C2=A0

IMHO and FWIW the draft describes how resource-aware forwarding can b= e achieved using various already-defined SR mechanisms.

=C2=A0

Have the authors and/or the WG considered changing the intended statu= s of the draft to =E2=80=9CInformational=E2= =80=9D?

=C2=A0

Regards,

Sasha

=C2=A0

=C2=A0=

Disclaimer

This e-mail together with any attach= ments may contain information of Ribbon Communications Inc. and its Affilia= tes 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 inten= ded 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

--000000000000a0a405060fce990d-- --000000000000a0a407060fce990e Content-Type: image/jpeg; name="~WRD0666.jpg" Content-Disposition: inline; filename="~WRD0666.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_18d433116c246cb2db81 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --000000000000a0a407060fce990e--