From acee.ietf@gmail.com Fri Jan 26 05:02:41 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 5D85DC14F5E0; Fri, 26 Jan 2024 05:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, 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 b400KtyYqnBw; Fri, 26 Jan 2024 05:02:37 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 13DB2C14EB19; Fri, 26 Jan 2024 05:02:37 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id d75a77b69052e-42993124fa1so2087221cf.3; Fri, 26 Jan 2024 05:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706274156; x=1706878956; darn=ietf.org; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=4EQ4v9rlSxg+4rjBCjXrh2aC7CtNsf1iVoBQv81B13Y=; b=ZauVWKZKGW2eDPP4Ud7fGQfM37cgU1zW4ZP38jMyua3zELhNBL5UX05AS5IH8bmup8 EW6JYC+gDfH22sx3+vRNZfa4iZeMl9B8shO4go165I/I4xsTE/3ErVIZFO9E15Bx1Nep TBM7UYRPcnhug5xNBFkX6kSWt1JZMcC6yCDM5M+kL6wO5qhHoybzzPj66hJzCaIjVodk ocCc60YcUJq4hsbjH1z8had2MTeDdr8UYd99g30oKTaNhPKtWCn63GOVWcyn36P/LswZ oqkeRXmBs/UcgHhlGVogHMI3M09KkF8g/tc71CEZNTbiAACPuwR9q0fkYHMJcZ6Ok0VG ad1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706274156; x=1706878956; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=4EQ4v9rlSxg+4rjBCjXrh2aC7CtNsf1iVoBQv81B13Y=; b=biBJu3BDcPMMvF3nLygcS+rxSuIX65kqhTEYEa0t2lBPlv5R7YTYFkXkWHjfdpZTjL paX5eufhavsEOh1lCbCvnBrfOybxSmyLXAktAQ2K8UZ/9GMEAAZL1VE/VjAaZK6yC34P JksB1wkxdC4tBCyEqRR0kpnVKEd067eCNX9dArUDndYoYIzd26Rnz5VVy/1ZTomfiVXv EWnUV9fRbR7kUH9dre3kLXG+OmuJ5FPOEbRJW6FhV8njpCxPZqNRFg803Dm25fFp8Uz7 0fI7/tO5htLoJm+ZW51RmK7QsSjwDEwVIPEiq8gka3VLKcG/uj7hxak/04CV252/mZj6 BFOw== X-Gm-Message-State: AOJu0YxKgbSt/sqjs3+wVgRD0D4Fo/D5VMvLiubguUl3WLw/FQkUgoPF V3/QecClO1iRIKahWs2eQwQf4ihEfzoGChbNS5PmBQsxmVuLiorX X-Google-Smtp-Source: AGHT+IElG2nH9J9EkqqE6YbHygPg0DNgE1wYjCrRlQN8NPU/m2dEUgxD2zE4KrR99S4k85aJRyebtw== X-Received: by 2002:ac8:5991:0:b0:42a:3658:5841 with SMTP id e17-20020ac85991000000b0042a36585841mr1634401qte.117.1706274155819; Fri, 26 Jan 2024 05:02:35 -0800 (PST) Received: from smtpclient.apple ([136.54.28.118]) by smtp.gmail.com with ESMTPSA id o21-20020ac86d15000000b00429d03916b3sm495155qtt.76.2024.01.26.05.02.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Jan 2024 05:02:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DCD125EC-79A4-49DB-BDB4-5D3C9D95C364" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) From: Acee Lindem X-Priority: 3 In-Reply-To: <2b0365b30cf9c8d-002fa.Richmail.00006002758990503077@chinamobile.com> Date: Fri, 26 Jan 2024 08:02:24 -0500 Cc: Gyan Mishra , "Dongjie (Jimmy)" , Alexander Vainshtein , draft-ietf-spring-re , spring , lsr Message-Id: <7221B457-258C-4B15-AC69-148632C1C81E@gmail.com> References: <2e572c01c2b94a738dc86b8c8f9e8305@huawei.com> <2b0365b30cf9c8d-002fa.Richmail.00006002758990503077@chinamobile.com> To: Liyan Gong X-Mailer: Apple Mail (2.3774.300.61.1.2) Archived-At: Subject: Re: [spring] [Lsr] Intended status ofdraft-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 13:02:41 -0000 --Apple-Mail=_DCD125EC-79A4-49DB-BDB4-5D3C9D95C364 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Liyan,=20 > On Jan 26, 2024, at 01:05, Liyan Gong = wrote: >=20 > Hi All=EF=BC=8C >=20 > Thank you for all your sharing. I have read the discussion carefully = and I agree the following opinions------"the resource-aware SIDs would = be associated with a set of network resource", and "the control plane = mechanisms is necessary to advertise the resource-aware SIDs and their = associated resource attributes".=20 >=20 I disagree with this and would discourage writing drafts based on a = single statement. I view NRP resources as being provisioned per node and = not something that should be advertised in the IGPs to be shared with = all the nodes in the IGP routing domain.This draft is, at best, = premature.=20 Thanks, Acee > But, it is indeed difficult and unreasonable to advertise huge amount = of informations in current IGP protocol since it will introduce = tremendous system burden. >=20 > To resolve this problem, we proposed a solution [1] to advertise SIDs = and attributes as a resource group in IGP protocol. >=20 > We are still working on it and hope to get feedbacks and comments from = LSR and SPRING WG. Thanks a lot.=20 >=20 >=20 >=20 > [1]: = https://www.ietf.org/archive/id/draft-cheng-lsr-advertise-nrp-group-extens= ions-01.txt >=20 >=20 >=20 >=20 >=20 > ----=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87---- > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AGyan Mishra = > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A"Dongjie (Jimmy)" = > =E6=8A=84=E3=80=80=E9=80=81: Alexander Vainshtein = ,"draft-ietf-spring-resource-aware-segments= @ietf.org" = ,"spring@ietf.org" = > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2024-01-26 08:49:36 > =E4=B8=BB=E9=A2=98=EF=BC=9ARe: [spring] Intended status = ofdraft-ietf-spring-resource-aware-segments >=20 >=20 > Hi Jie=20 >=20 > Responses in-line Gyan> > > Gyan Mishra > Network Solutions Architect=20 > Email gyan.s.mishra@verizon.com > M 301 502-1347 >=20 >=20 >=20 >=20 > On Wed, Jan 24, 2024 at 2:57 AM Dongjie (Jimmy) > wrote: >> Hi Gyan, >>=20 >> =20 >> Thanks for sharing your thoughts on this document. >>=20 >> Gyan> Welcome=20 >>=20 >> I agree with you that in this document the semantics of the existing = SR SIDs (the topological SIDs in your text) are extended to = =E2=80=9Ctopology/function + resource=E2=80=9D, 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. >>=20 >> 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. >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> Hope this helps to align our understanding on this document. >>=20 >> Gyan> Yes Thank you =20 >>=20 >> Best regards, >>=20 >> Jie >>=20 >> =20 >> From: Gyan Mishra [mailto:hayabusagsm@gmail.com = ]=20 >> Sent: Tuesday, January 23, 2024 2:02 PM >> To: Dongjie (Jimmy) > >> Cc: Alexander Vainshtein >; = draft-ietf-spring-resource-aware-segments@ietf.org = ; = spring@ietf.org >> Subject: Re: [spring] Intended status of = draft-ietf-spring-resource-aware-segments >>=20 >> =20 >> =20 >> Hi Jie >>=20 >> =20 >> I understand the draft proposes an extension to existing topological = SIDs to carry the resource attributes. >>=20 >> =20 >> However since this draft proposes a new resource attributes extension = encoding to existing topological SIDs I agree this should be standards = track. >>=20 >> =20 >> 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. >>=20 >> =20 >> You could possibly mention the proposed encoding scheme and fields = and that detail would be integrated into the IGP draft. >>=20 >> =20 >> 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. >>=20 >> =20 >> 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. >>=20 >> =20 >> 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. >>=20 >> =20 >> Kind Regards=20 >>=20 >>=20 >>=20 >> >> Gyan Mishra >> Network Solutions Architect=20 >> Email gyan.s.mishra@verizon.com >> M 301 502-1347 >>=20 >> =20 >> =20 >> =20 >> On Mon, Jan 22, 2024 at 3:39 AM Dongjie (Jimmy) = > wrote: >>=20 >> Hi Sasha, >>=20 >> =20 >> Thanks for the review and comment on this document. >>=20 >> =20 >> 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. >>=20 >> =20 >> 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. >>=20 >> =20 >> Of course we would like to hear the opinions from the WG = participants, and follow the decision of the WG. >>=20 >> =20 >> Best regards, >>=20 >> Jie >>=20 >> =20 >> 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 >>=20 >> =20 >> Hello, >>=20 >> I have read the draft = , and I do not have any technical comments on it. >>=20 >> At the same time, I wonder why its intended status appears as = =E2=80=9CStandard Track=E2=80=9D: >>=20 >> 1. The draft does not define any new mechanisms in the data plane or = control plane >>=20 >> 2. Usage of the IETF keywords denoting requirement levels looks too = vague/generic to me, e.g. >>=20 >> a. The details of the underlay network MUST NOT be exposed to third = parties, to prevent attacks aimed at exploiting shared network resources >>=20 >> b. If there are related link advertisements, then consistency MUST = be assured across that set of advertisements >>=20 >> =20 >> IMHO and FWIW the draft describes how resource-aware forwarding can = be achieved using various already-defined SR mechanisms. >>=20 >> =20 >> Have the authors and/or the WG considered changing the intended = status of the draft to =E2=80=9CInformational=E2=80=9D? >>=20 >> =20 >> Regards, >>=20 >> Sasha >>=20 >> =20 >> =20 >> Disclaimer >>=20 >> 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. >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >>=20 >=20 >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --Apple-Mail=_DCD125EC-79A4-49DB-BDB4-5D3C9D95C364 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Liyan, 

On Jan 26, 2024, at 01:05, Liyan Gong = <gongliyan@chinamobile.com> wrote:

Hi All=EF=BC=8C

Thank you for all your sharing.  I have read the discussion = carefully and I agree the following opinions------"the resource-aware SIDs would be associated with a set of = network resource", and "the control plane mechanisms = is necessary to advertise the resource-aware SIDs and their associated = resource attributes". 

I disagree = with this and would discourage writing drafts based on a single = statement. I view NRP resources as being provisioned per node and not = something that should be advertised in the IGPs to be shared with all = the nodes in the IGP routing domain.This draft is, at best, = premature. 

Thanks,
Acee




But, it is indeed difficult and unreasonable to = advertise huge amount of informations in current IGP protocol since it = will introduce tremendous system burden.

To resolve this problem, we = proposed a solution [1] to advertise SIDs and attributes as a resource = group in IGP protocol.

We are still working on it and hope to get feedbacks and comments = from LSR and SPRING WG. Thanks a lot. 


[1]: https://www.ietf.org/archive/id/draft-cheng-lsr-advertise-nrp-group= -extensions-01.txt



=E6=8A=84=E3=80= =80=E9=80=81: = Alexander Vainshtein  <Alexander.Vainshtein@rbb= n.com>,"draft-ietf-spring-resource-aware-segments@ietf.org" <dr= aft-ietf-spring-resource-aware-segments@ietf.org>,"spring@ietf.org"&nbs= p;<spring@ietf.org>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF= =BC=9A2024-01-26 = 08:49:36
=E4=B8=BB=E9=A2=98=EF=BC=9ARe: [spring]&= nbsp;Intended status ofdraft-ietf-spring-resource-aware-segments=


Hi Jie 

Responses in-line = Gyan>


Gyan Mishra
Network Solutions = Architect 
M 301 = 502-1347


=


On Wed, Jan 24, 2024 at 2:57 AM Dongjie (Jimmy) = <jie.dong@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 =E2=80=9Ctopology/function  + = resource=E2=80=9D, 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:hayabusagsm@gmail.com]
Sent: = Tuesday, January 23, 2024 2:02 PM
To: Dongjie = (Jimmy) <jie.dong=3D40huawei.com@dmarc.ietf.org>
= Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; draft-ietf-spring-resource-aware-segments@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 


=

<image001.jpg><= /p>

Gyan Mishra
Network Solutions = Architect 

M 301 502-1347

 
 
 

On Mon, Jan 22, 2024 at 3:39 AM Dongjie (Jimmy) = <jie.dong=3D40huawei.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, and 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=9CStandard = 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

<= /div>
 

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 copies,  including any attachments. =

_______________________________________________
= spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


_________________________________= ______________
Lsr mailing = list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

= --Apple-Mail=_DCD125EC-79A4-49DB-BDB4-5D3C9D95C364--