From acee.ietf@gmail.com Thu Jan 25 08:16:31 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 F1627C14F697; Thu, 25 Jan 2024 08:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 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_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 2Lmur8rTlRoj; Thu, 25 Jan 2024 08:16:28 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 4AB3EC14F5F9; Thu, 25 Jan 2024 08:16:28 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id d75a77b69052e-42989a64713so52083661cf.2; Thu, 25 Jan 2024 08:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706199387; x=1706804187; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=4cPNaN6iD3Sb58W8U0uj+u7EqwDHyPpPnATD/CbfWJw=; b=igB9PLIwdOibGVLvTkISXDjkE+ouxQgsxSfizx/3c2PTXNUK00QlW9+loGux+K1pFy qsyPovsGuaTVh2SBJW/vrOfL6Tx6r/3VT6/jnnnvISiwh4ck8UzdYDQPtlt0y3SLR8t4 XcaJo7Ui6B49/dBb9/QX4DsAoVp0yrQx0TMyzIQk3FkdQ3Xlu0fAh/pL3O3WRVOzrYt9 EbBR6eFNmZ/2CoRS7pDlk6ZcLsTWhdVMOsxcw3ySwVuQjER0h8+1ziFOow/f5KI/NIho vSMosKE4vLTWYlzxbc6HhEP6mA/vnW/fEQ7GNGb8zARVBqz/DiRItusT5GCisj+DhOZM rxeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706199387; x=1706804187; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4cPNaN6iD3Sb58W8U0uj+u7EqwDHyPpPnATD/CbfWJw=; b=XE2hbCPxOx/cGRfiD5AaAH2maoLo+FURsRM1oqxOnVP2KdPfVrMrQ8iG6s+ZibK7Zg 0bW7ZU4aX7IkyR8ppxdZKMwvAaaSnVLVp6i8lBQSG5/UnzQKWCye2uMsmUBooXSzfOVz WFxujRUMNuKIHgZv8Z6grKQManwF+pr5riPGgR43J99jKEUwtv7AAORYDzWgYbrWcRln JeBnSmTNRlm55YfTsyjjqgECD10LEP2qlIorifTeK0HoaLePEqFW2eHfXiYgkKT7JY8Z xas4wCIMy+2Nv620NnMPLau9OdnSJYhchtHjixCgeDsOWJnJWFhhSRKoncEs/gzLlMoq U4+g== X-Gm-Message-State: AOJu0YzukS1+kmTnhTIr4pSKPw5GWMQIL4ZkOgQjjYho+nhXjiHviRqH NDRxm//C1E+Dg20I7zqd6x+Yaf/5UEVa3E7FbiIzPErlsXnKDXx3 X-Google-Smtp-Source: AGHT+IG8d4EMVOH3wBW9h6TLzE3UwCei3Xo2/lws9c8bUnBt/iCGFacac1GVw2hIn08dc9+x15UQug== X-Received: by 2002:a05:622a:188b:b0:42a:5f4b:173c with SMTP id v11-20020a05622a188b00b0042a5f4b173cmr1496285qtc.20.1706199387104; Thu, 25 Jan 2024 08:16:27 -0800 (PST) Received: from smtpclient.apple ([136.54.28.118]) by smtp.gmail.com with ESMTPSA id fk27-20020a05622a559b00b0042a3fdeea9asm3940360qtb.7.2024.01.25.08.16.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2024 08:16:26 -0800 (PST) From: Acee Lindem Message-Id: <9F6AA08A-5B29-4483-AD44-19B9D58909C8@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_50810B92-3114-4404-A96B-A4EF1B1D13E6" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Date: Thu, 25 Jan 2024 11:16:16 -0500 In-Reply-To: Cc: Gyan Mishra , "draft-ietf-spring-resource-aware-segments@ietf.org" , spring , "Dongjie (Jimmy)" To: Alexander Vainshtein References: <2e572c01c2b94a738dc86b8c8f9e8305@huawei.com> X-Mailer: Apple Mail (2.3774.300.61.1.2) Archived-At: Subject: Re: [spring] [EXTERNAL] 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: Thu, 25 Jan 2024 16:16:32 -0000 --Apple-Mail=_50810B92-3114-4404-A96B-A4EF1B1D13E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sasha, Gyan,=20 I agree with Sasha. I=E2=80=99d add that I don=E2=80=99t think any = information related to the resources associated with the SID should be = encoded in the IGPs.=20 Thanks, Acee > On Jan 23, 2024, at 04:00, Alexander Vainshtein = wrote: >=20 > Gyan, and all, > I have re-read the draft = , but I did not find any proposals for =E2=80=9Ca new resource = attributes extension encoding to existing topological SIDs=E2=80=9D. = The draft explicitly states that it does not involve any requests to = IANA. > =20 > The quoted fragment in Section 2.1 suggests that such attributes may = be used (the relevant text ishighlighted): > =20 > For one IGP prefix, multiple resource-aware prefix-SIDs can be = allocated. Each resource-aware prefix-SID may be associated with a = unique 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 additional control plane = distinguisher needs to be introduced to distinguish different = resource-aware prefix-SIDs associated with the same but different groups of network resources. > =20 > But I doubt this rather vague statement justifies the draft going for = Standards Track. > =20 > 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) . > =20 > What, if anything, did I miss? > =20 > Regards, and lots of thanks in advance, > Sasha > =20 > 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 > =20 > =20 > Hi Jie > =20 > I understand the draft proposes an extension to existing topological = SIDs to carry the resource attributes. > =20 > However since this draft proposes a new resource attributes extension = encoding to existing topological SIDs I agree this should be standards = track. > =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 > You could possibly mention the proposed encoding scheme and fields and = that detail would be integrated into the IGP draft. > =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 > 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 > 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 > Kind Regards=20 >=20 > <~WRD0666.jpg> > 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: > Hi Sasha, > =20 > Thanks for the review and comment on this document. > =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 > 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 > Best regards, > Jie > =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 > 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:=20 > 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 > =20 > IMHO and FWIW the draft describes how resource-aware forwarding can be = achieved using various already-defined SR mechanisms. > =20 > Have the authors and/or the WG considered changing the intended status = of the draft to=E2=80=9CInformational=E2=80=9D? > =20 > Regards, > 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 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_50810B92-3114-4404-A96B-A4EF1B1D13E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Sasha, = Gyan, 

I agree with Sasha. I=E2=80=99d add that = I don=E2=80=99t 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.Vainshtein@rbbn.com> wrote:

Gyan, = and all,
I have re-read the draft, but I did not find any proposals for = =E2=80=9Ca new resource attributes extension encoding to = existing topological SIDs=E2=80=9D.  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 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 <hayabusagsm@gmail.com>
Sent: Tuesday, January 23, 2024 = 8:02 AM
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: [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>

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) <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
C= c: 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
 
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

= --Apple-Mail=_50810B92-3114-4404-A96B-A4EF1B1D13E6--