From alexander.vainshtein@rbbn.com Thu Jan 25 22:09:07 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 9B455C14F714 for ; Thu, 25 Jan 2024 22:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.101 X-Spam-Level: X-Spam-Status: No, score=-7.101 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 DhloMYn-25EN for ; Thu, 25 Jan 2024 22:09:03 -0800 (PST) Received: from usb-smtp-delivery-110.mimecast.com (usb-smtp-delivery-110.mimecast.com [170.10.153.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 0B118C14F711 for ; Thu, 25 Jan 2024 22:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20230413; t=1706249341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RmD4AwxMmEVRFQebVFbF/cv863muGAYXyqgTJLMR1pc=; b=RpENFTTX+hhTSNi0gjlI2GTSeaU8d72cPQrqZWl46zHxmaCT13AWsYkvGrZkMX/tnVi4du kwPZusZmKVqRlmxgQjSTRBfd2hXywyaY1/HVlc4z7WApY63wsl12CtdBb8lnEUhAof2V6F 0iIkFdtDKOSMId09aQ8zHb5mMou+d1o= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id usb-mta-27-kLvGjbgmNNmhACRI5jI7CQ-1; Thu, 25 Jan 2024 22:06:49 -0800 X-MC-Unique: kLvGjbgmNNmhACRI5jI7CQ-1 Received: from PH0PR03MB6300.namprd03.prod.outlook.com (2603:10b6:510:e2::5) by CO6PR03MB6211.namprd03.prod.outlook.com (2603:10b6:303:13b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.22; Fri, 26 Jan 2024 06:06:47 +0000 Received: from PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::c771:5454:2384:e312]) by PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::c771:5454:2384:e312%5]) with mapi id 15.20.7228.023; Fri, 26 Jan 2024 06:06:46 +0000 From: Alexander Vainshtein To: Gyan Mishra CC: Acee Lindem , "Dongjie (Jimmy)" , "draft-ietf-spring-resource-aware-segments@ietf.org" , "spring@ietf.org" Thread-Topic: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-resource-aware-segments Thread-Index: AdpMMVLY8V7EZVEdRlSrLyJJPcozbgAsKXXQADfqJIAABTVnwACGlawAAAr0eXc= Date: Fri, 26 Jan 2024 06:06:46 +0000 Message-ID: References: <2e572c01c2b94a738dc86b8c8f9e8305@huawei.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: PH0PR03MB6300:EE_|CO6PR03MB6211:EE_ x-ms-office365-filtering-correlation-id: 3baec6f3-cd07-4b9b-e511-08dc1e34fa68 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: X/g2NZedBo/0FoDcZp9DOAIKZRH6nIBHtQN8XF9adfJ8AJYj6qr11M2pmF5QYyUSQmyeUyziL86+ZQtip+9mkqXdRRqbZyrgI83VWU3ZD4OdODgDgzW0LDeF9Xfc5m/aQ6Bn7g/QwPLhAZvMReVlltp2DW1iT9pm3Ecwkoe8BYQf0fQa92QtyX3KdSBE4dll/OD/l9b2prEtwwQrQcZGRwkLZOgX8Ms4ptE8Ib9c5R6IwSmGurwx+6rgNldCbzZbyw0qDZnZjQRqHxXpum4sW6XLNzOXn94OH3ihU2djLUSIDlhCU884s16hW0ew6AQ9LjAr+xgLPwZqkFGHIzTAkvwn8hN+B/Kui3Ij6UNQBOROXoV9RdfeTFicc7eVPV9L1FnS1IrIqzrX9xPt2l2ungLJ5qLphbWiUJ5KQSC+KamdzM3hf8PQMB6qiQVWOqQEj0Q0tio9gLVhvtwzjT3h+bTri+2kGN6ifdZwW9atzVUyJcjp2d3o4z0oG+KDEdUsXYuZ66OwpQSrYDfrDjG77C4IoBTMGlrDmTwdt/L5sAkk3hr/C765kPEtlE6j25FXtXaHdqKjRq00dRmgpThX+Ph4jEJIXHWFUVjcVUl6zTR6bq00SvqICTITOgZoIr9fz392MMbKYxU9mEyz1cyA252Nnk1yu6SG1R0TmsJSe7UXNBVJNGH3xTAovnR6Ztus x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR03MB6300.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(396003)(39860400002)(136003)(376002)(346002)(230922051799003)(230473577357003)(230273577357003)(230373577357003)(230173577357003)(1690799017)(64100799003)(1800799012)(451199024)(186009)(9686003)(76116006)(7696005)(6506007)(53546011)(6916009)(66446008)(316002)(64756008)(54906003)(66946007)(66556008)(55016003)(38100700002)(91956017)(52536014)(966005)(45080400002)(8676002)(4326008)(8936002)(478600001)(83380400001)(71200400001)(26005)(2906002)(5660300002)(66476007)(122000001)(99936003)(38070700009)(166002)(86362001)(41300700001)(33656002)(40140700001); DIR:OUT; SFP:1101 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?4A+tcK2l6QBdYvfmPc4A3UiMd+pm197n/qlnFKNTe6RVsWONWTHoe41k?= =?Windows-1252?Q?Bq9bGNx12xRHSgreks4qkHk0QJPw5RC1Tq9ueyfoNXIQWIJN7pCVlIx5?= =?Windows-1252?Q?ZieMq390cUkDgEtS+W29MwjRspOAnaArtICvdtm4GLJ02/teLvuTBD0u?= =?Windows-1252?Q?kKUcTVOOtomt0DwATbtuLlE32ayPUE5GhD4vOJ6+y5gH0neXoDBeNNfs?= =?Windows-1252?Q?xcNRRIeLhkMOEHZMfbUlPK4kZ0199aLFFc3/uinrlmXeA3TZ7VH+Deej?= =?Windows-1252?Q?oWKa2A0kwHPoVOG3Jm3w7ZBmZjgU0uXZujfQWBQseEWIQ1sa3+1lfErv?= =?Windows-1252?Q?M9PErUT0FmZTl33dbBWpcbTDc6dj1XqJQ1oWIx1HCOPuqIL0te9mIfkg?= =?Windows-1252?Q?V3+AOW6bGJrizxgAKZ757THlS0wBXrzR/bdQ9ikYv9mitvpdoLorbwhw?= =?Windows-1252?Q?utnIywX1gcU5OFKJxg8Gs449GBbWu+avnMB+q/H3anQ44Mt20lKF/iBD?= =?Windows-1252?Q?j6zexdtSk15K8+sEa3zkWiLHZc2IEJXUNGzlBFAHENzuubnKeh4xcOXB?= =?Windows-1252?Q?3xQhtgEE923NDQ/P61Xfp8SJMKbPCT/dplE5o2U2qyZcx543dL2ejv56?= =?Windows-1252?Q?4T5dqy9W6nsjdmVyyfN5yh1icIPZpSJciOjilu8m46N/6pM1fKGHYMKD?= =?Windows-1252?Q?8hUVy2wd0YZXeY0RFNhYZLgNXIdtPYXZOIwQaHBtSJvbymEFUrcLCcZY?= =?Windows-1252?Q?zOPEI3FiW14w2FZPHs75RqPWv3kl9kteqhQ2uyGuDbA/YBY51u0YWPnZ?= =?Windows-1252?Q?udGcWunA8VzE0ylUmGhlWS1KXctKP+eqjf6bjWLcoDhanqsgBKR5bTEj?= =?Windows-1252?Q?xj8sVl0H4AgZBQ/G0x93ZqhgUf8ggu0F41Nd1nXcd6s2BoktvaKUBMbA?= =?Windows-1252?Q?kcIXXo+QNDPW4ps2hU8vkKjN2eSEC0ysS1a18rIhzaCCKBYHrPjhN7KC?= =?Windows-1252?Q?15BdV8vEngYX3OEioMIU0K+PI24zbK2iE0YMK1BRwpPKFZb+4T1ymFPG?= =?Windows-1252?Q?itjqOmDJR+cLMfpDZcyVNd0ydhi5vBmwt1kHndrtVzMnVtbN5Ckj4eHe?= =?Windows-1252?Q?xC+WYheX3LCKmVGMGW6u078qZxqUJpagp4JD9YfVH8tP6euSTQoBb4Jh?= =?Windows-1252?Q?xkgzjZtO/tH2x3jxIP8W2Z/q4ZeetOwWgzDt27uUwyYGTmUM+6SYbuM4?= =?Windows-1252?Q?kEYU+XW55h8/SQSPeOMazHHWSBIf3Ubo4QhQaSc1pzlPliYskgv1Qq+4?= =?Windows-1252?Q?5QydUwHFQT4/xmMLhwbDAOejN9cyJLjbcRNhNgwpV0WrG+irvp4ZfbQ4?= =?Windows-1252?Q?/Or8YxTOR15RWunle31SyEc4aAPG4WyPH4IeTNFbVWxcSnLIG8feMWfo?= =?Windows-1252?Q?6T+/YMaA+jGVHZ4rmEt1hjz13QWKUa5OLzCBoXirEP9eQEW87dSxRdni?= =?Windows-1252?Q?jz8rUxI3XBDXXUASJ/rliTQoUlM0I9dOGqXOMkzZyedcsxnkjVYrD1rN?= =?Windows-1252?Q?KzPBbihNP2jfUtzOPUnHLqsHA3APTtVvTJJPJxvcV9hd/Yabh0ZR/imu?= =?Windows-1252?Q?KhoS0lN7VGKduYOrdHbA+olWxlzi2rc+otGZlSIcZxdGApwKMcUeGcdi?= =?Windows-1252?Q?kG+f5cSTc2x405+jAdes9Gqx9CgrkpKwfLZotfOa2Kgiqe8MmAlnJw?= =?Windows-1252?Q?=3D=3D?= MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6300.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3baec6f3-cd07-4b9b-e511-08dc1e34fa68 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2024 06:06:46.7444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MrcU084HDt7AZV8xYgLMI5rncUWCoPXZfgl14pKxX3D7j7HESITU6eHjjyt00vzxYjJQKPE24JomOUGR5NySuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR03MB6211 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: rbbn.com Content-Language: en-US Content-Type: multipart/related; boundary="_004_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_"; type="multipart/alternative" 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 06:09:07 -0000 --_004_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_ Content-Type: multipart/alternative; boundary="_000_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_" --_000_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Gyan, Lots of thanks for your email. Looks as we are now in sync. As explained in my other mail, I see this draft as a framework document to = be augmented by specific Standards Track documents defining specific soluti= ons. Regards, Sasha Regards, Sasha Get Outlook for Android ________________________________ From: Gyan Mishra Sent: Friday, January 26, 2024 2:44:55 AM To: Alexander Vainshtein Cc: Acee Lindem ; Dongjie (Jimmy) ; draft-ietf-spring-resource-aware-segments@ietf.org ; spring@ietf.org Subject: Re: [EXTERNAL] Re: [spring] Intended status of draft-ietf-spring-r= esource-aware-segments Hi Sasha Agreed with everything you stated that the draft does not propose any exten= sion to existing topological SIDs and no IANA requests. So what I stated below was referring to maybe a future draft TBD to be deve= loped in LSR that would have an OSPF and ISIS TLV encoding for the resourc= e segment information discussed in this daft and that possible new draft wo= uld have IANA code point and would be standards track. Since the topological segments are advertised by IGP OSPF or ISIS, I am gue= ssing you would have a standards track draft in LSR that encodes the resour= ce segments and could update the existing SR-MPLS and SRv6, OSPF and ISIS R= FCs / drafts. Kind Regards [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 On Tue, Jan 23, 2024 at 4:00 AM Alexander Vainshtein > wrote: Gyan, and all, I have re-read the draft, but I did not find any proposals for =93= a new resource attributes extension encoding to existing topological SIDs= =94. 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 use= d (the relevant text is highlighted): For one IGP prefix, multiple resource-aware prefix-SIDs can be allocated. E= ach 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 a= nother case, for one IGP prefix, multiple resource-aware prefix-SIDs may be= associated with the same tuple, then an additional c= ontrol plane distinguisher needs to be introduced to distinguish different = resource-aware prefix-SIDs associated with the same b= ut different groups of network resources. But I doubt this rather vague statement justifies the draft going for Stan= dards Track. Not have I found any references to the drafts with intended status Standard= s 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-resou= rce-aware-segments Hi Jie I understand the draft proposes an extension to existing topological SIDs t= o carry the resource attributes. However since this draft proposes a new resource attributes extension encod= ing to existing topological SIDs I agree this should be standards track. Since the topological segments are advertised by IGP OSPF or ISIS, I am gue= ssing you would have a standards track draft in LSR that encodes the resour= ce segments and could update the existing SR-MPLS and SRv6, OSPF and ISIS R= FCs / 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 ce= ntric that would be applicable to both SR-MPLS and SRv6 but would be inde= pendent of topological or service SID so not at that layer. The resource S= ID would be associated with the BSID that binds the single or multiple cand= idate path to the forwarding plane and instantiates the path. So for SR-MP= LS 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 candi= date paths. In this option you would have a standards track draft in LSR that encodes t= he resource segments and could update the existing SR-MPLS and SRv6, OSPF a= nd 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 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) > wrote: Hi Sasha, Thanks for the review and comment on this document. Although this draft does not introduce new SR segment type/SRv6 behavior, t= here is change in the semantics and forwarding behavior of the resource-awa= re 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 a= djusted 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 Vainsh= tein 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-segme= nts Hello, I have read the draft, and I do not have any technical comments o= n it. At the same time, I wonder why its intended status appears as =93Standard T= rack=94: 1. The draft does not define any new mechanisms in the data plane or c= ontrol plane 2. Usage of the IETF keywords denoting requirement levels looks too va= gue/generic to me, e.g. a. The details of the underlay network MUST NOT be exposed to third pa= rties, 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 achi= eved using various already-defined SR mechanisms. Have the authors and/or the WG considered changing the intended status of t= he draft to =93Informational=94? 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 proprie= tary for the sole use of the intended recipient. Any review, disclosure, re= liance or distribution by others or forwarding without express permission i= s strictly prohibited. If you are not the intended recipient, please notify= the sender immediately and then delete all copies, including any attachmen= ts. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Gyan,
Lots of thanks for your email.

Looks as we are now in sync. 

As explained in my other mail, I see this draft as a framework document to be augmented= by specific Standards Track documents defining specific solutions.

Regards,
Sasha



Regards,
Sasha

From:= Gyan Mishra <hayabusagsm@gmail.com>
Sent: Friday, January 26, 2024 2:44:55 AM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com= >
Cc: Acee Lindem <acee.ietf@gmail.com>; Dongjie (Jimm= y) <jie.dong=3D40huawei.com@dmarc.ietf.org>; draft-ietf-spring-resour= ce-aware-segments@ietf.org <draft-ietf-spring-resource-aware-segments@ie= tf.org>; spring@ietf.org <spring@ietf.org>
Subject: Re: [EXTERNAL] Re: [spring] Intended status of dr= aft-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 dr= aft TBD to be developed  in LSR that would have an OSPF and ISIS TLV e= ncoding for the resource segment information discussed in this daft and tha= t 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 gue= ssing you would have a standard= s track draft in LSR that encodes the resource segments and could update the existing SR-MPLS and SR= v6, OSPF and ISIS RFCs / drafts.


Kind Regards 


Gyan M= ishra

Network Solutions = Architect&= nbsp;

Email gyan.s.mishra@verizon.com

= M 301 502-1347




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

Gyan, and all,=

I have re-read the draft, but I did not find any proposals for =93a new resource= attributes extension encoding to existing topological SIDs=94.  T= he draft explicitly states that it does not involve any requests to IANA.

 

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

 

For one IGP prefix, multiple res= ource-aware prefix-SIDs can be allocated. Each resource-aware prefix-SID ma= y 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-SI= Ds 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 associat= ed with the same <topology, algorithm> but different groups of networ= k resources.

 =

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

 <= /span>

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

 <= /span>

What, if anything, di= d I miss?

 <= /span>

Regards, and lots of = thanks in advance,

Sasha

 <= /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>; draft-ietf-spring-resource-aware-segments@ietf.org; spring@ietf.org
Subject: [EXTERNAL] Re: [sp= ring] Intended status of draft-ietf-spring-resource-aware-segments

 

 

Hi Jie

 

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

 

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

 

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 exist= ing SR-MPLS and SRv6, OSPF and ISIS RFCs / drafts.

 

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

 

Another option would be t= o introduce new resource aware SIDs that is NRP centric  that would be= applicable to both  SR-MPLS and SRv6 but would be independent of topo= logical or service SID so not at that layer.  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= .  So for SR-MPLS it would be the entire label stack pushed onto the p= acket when the BSID is popped.  For SRv6 it would be SRH segment list associated with the candidate paths.

 

In this option you wou= ld have a standards track draft in LSR that encodes the resource segments a= nd could update the existing SR-MPLS and SRv6, OSPF and ISIS RFCs / drafts.

 

The contents of the resourc= e SID would now apply to the NRP and would be as you described, buffers, qu= eues, bandwidth, SLO and SLE  parameters such as latency and jitter for NRP network slice.

 

Kind Regards =


3D"Image

Gyan Mishra=

Network Solutions Arc= hitect 

Emai= l 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 Sas= ha,

 =

Thanks= for the review and comment on this document.

 =

Althou= gh this draft does not introduce new SR segment type/SRv6 behavior, there i= s change in the semantics and forwarding behavior of the resource-aware segments, as each resource-aware SIDs ident= ifies a subset of the network resources used for packet processing.

 =

Thus t= he 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. <= /span>

 =

Of cou= rse we would like to hear the opinions from the WG participants, and follow= the decision of the WG.

 =

Best r= egards,

Jie

 =

From: spring [mailto: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: spring@ietf.org
Subject: [spring] Intended = status of draft-ietf-spring-resource-aware-segments<= /u>

 

Hello,

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

At the same time, I= wonder why its intended status appears as =93Standard Track=94:

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

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

a.      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.      If there are rel= ated link advertisements, then consistency MUST be assured across that set = of advertisements

 

IMHO and FWIW the d= raft describes how resource-aware forwarding can be achieved using various = already-defined SR mechanisms.

 

Have the authors an= d/or the WG considered changing the intended status of the draft to =93Informational=94= ?

 

Regards,<= /u>

Sasha=

 

 

Disclaimer

This e-mail together with a= ny attachments may contain information of Ribbon Communications Inc. and it= s Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclo= sure, reliance or distribution by others or forwarding without express perm= ission is strictly prohibited. If you are not the intended recipient, pleas= e 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


--_000_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_-- --_004_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_ Content-Type: image/jpeg; name="~WRD0666.jpg" Content-Description: ~WRD0666.jpg Content-Disposition: inline; filename="~WRD0666.jpg"; size=823; creation-date="Fri, 26 Jan 2024 00:44:54 GMT"; modification-date="Fri, 26 Jan 2024 05:58:02 GMT" Content-ID: Content-Transfer-Encoding: base64 /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== --_004_PH0PR03MB6300471EC585B5BD0C265E2FF6792PH0PR03MB6300namp_--