Re: [Lsr] Proposed Errata for RFCs 8919/8920
"Selderslaghs, Rudy (Nokia - BE/Antwerp)" <rudy.selderslaghs@nokia.com> Thu, 17 June 2021 13:38 UTC
Return-Path: <rudy.selderslaghs@nokia.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC943A1FFD for <lsr@ietfa.amsl.com>; Thu, 17 Jun 2021 06:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level:
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnPzHcx2LL_6 for <lsr@ietfa.amsl.com>; Thu, 17 Jun 2021 06:38:34 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60090.outbound.protection.outlook.com [40.107.6.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DAD3A201E for <lsr@ietf.org>; Thu, 17 Jun 2021 06:38:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ud8H2BJvgBBgj8u5ot4EIbAZKRybnwCqS3r1folUJJ4F1lzfeJ1iLv6sBHcua5QtABZFJdAosGbZf9B3Yw/m7q7QlybTendtGp0AAxv/J/s0JOTrBIV1lVNkPSbTlP3NNKITEjRCpcBf75Ch3GsoJShuUff5NLS9/perGkqG8dNj3JzAqA05dSibbj8OQ6+39rkNsokp5PQlq7x/rxciudH2hIHzRWNdMOskft0SO6WcL5vGoFhcFxjPsHGqxjPeJ+IH33OwmE0ijvr+2ArLM7vXqqO+lgZKbeZTAkl4jZr3en5ErBt6D++PncJVa5EQ/MGoDUoutfaEL1hh/ORWkQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NGx3Bqyi9PpBaeYWkOutC4xh78iyMpfz7uuzj3Yz8EU=; b=fwBTnnj76TjMxcW9YRIiJWyQTQulGvqQeUk2X01S1E7ytvDQfGjjeEvpP0h4a9A2TgR3TzltQNbvYGHF5asEJVrGNh9PqTGlNQE4kjYxOfzpgYWNjBrwqsPFncbxt60mBiRumQUJff+2xJat+0NEjcaKaY1aOn+adOzmTG5/JzMn09WBkUvAf35xYKAWeDdHiIDlS2raisjlNRoLdav2GlMB4fxaESECYwjv51k2/hofvP2RRwtTyui//EeKIYObiTWsSb4WYrQufyIXHFaTeRlfdApm/0JR2s+ZpsEGrdrmjaq/0EM5NVEG0lBcezuIIYhhEwrjFcLdaMqSi12iLA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NGx3Bqyi9PpBaeYWkOutC4xh78iyMpfz7uuzj3Yz8EU=; b=nbdV7O7yCTBuVP6MJVvYWe96wNNwzlZ4ylrnK3AIISfUEUsAlu5m9UEBytmoaDOuxr9n0DXXmKi8cDiiI0IE3A6eL8WLs+WkhFIm3sHNCA8R6IA7puAZNHLdFhBEMHpIk6fnUqSw61r7pgxuTAgbj2EdOg+MrrGJnLYJ8srS/Fw=
Received: from AM0PR07MB6321.eurprd07.prod.outlook.com (2603:10a6:20b:151::19) by AM8PR07MB7346.eurprd07.prod.outlook.com (2603:10a6:20b:24d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.7; Thu, 17 Jun 2021 13:38:31 +0000
Received: from AM0PR07MB6321.eurprd07.prod.outlook.com ([fe80::ed91:6f11:c623:6088]) by AM0PR07MB6321.eurprd07.prod.outlook.com ([fe80::ed91:6f11:c623:6088%8]) with mapi id 15.20.4242.019; Thu, 17 Jun 2021 13:38:31 +0000
From: "Selderslaghs, Rudy (Nokia - BE/Antwerp)" <rudy.selderslaghs@nokia.com>
To: Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, "lsr@ietf.org" <lsr@ietf.org>
CC: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>
Thread-Topic: Proposed Errata for RFCs 8919/8920
Thread-Index: Addh+XAWKUvBLsteQNyAf8QRieIv8AAw563QAAMQTwAAAeM0YAAZjCMAAA71sPA=
Date: Thu, 17 Jun 2021 13:38:31 +0000
Message-ID: <AM0PR07MB6321150D75F6077E0EE51C8AE80E9@AM0PR07MB6321.eurprd07.prod.outlook.com>
References: <BY5PR11MB4337B8FB7707B24DDE302182C1309@BY5PR11MB4337.namprd11.prod.outlook.com> <CY4PR05MB357627C26A90AE7E9C5C89F7D50F9@CY4PR05MB3576.namprd05.prod.outlook.com> <AM0PR07MB6386EEAFB141820A4B1C5844E00F9@AM0PR07MB6386.eurprd07.prod.outlook.com> <BY5PR11MB433748CF078EAF485FD12641C10F9@BY5PR11MB4337.namprd11.prod.outlook.com> <CY4PR05MB35760AF7195C31E25E920A4FD50E9@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB35760AF7195C31E25E920A4FD50E9@CY4PR05MB3576.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-06-17T05:14:00Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5e02bd8c-472d-4a73-aad8-89932bfb7a64; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [2a02:a03f:8a18:d000:8851:3435:470f:120]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9202af4d-bbb3-4fe4-8f63-08d93195324f
x-ms-traffictypediagnostic: AM8PR07MB7346:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM8PR07MB7346EDF86AE23D4B9AB3D18CE80E9@AM8PR07MB7346.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xCK+c3hnZ34jROzuD8PN1AioZgMhqZvo9Rjmu+b4ua24D7lI4+4/hDgYs5t81vVx0BIxEEEoY5rUEy6Dn87W8Niv3RP2AqtWjtJr6tjApQaTGiowcayPvjjacTzKJzjYyoVhp+76ulUYg7hrB8lV56JPkzOx2C9/UtwY9y+PzUHmMGPM7wQr4Wvr0ykNlG/X/abQajf2ShzA6Mtk9lWImADc9X0bOoQwZuS01dfsky1maJZGua55TmNKisBIllRQtlnJ7Ql07smww5NVPtn3hD8pQ2xdmj0Y7dGNaCmuTy+EY/eGap1UVQe+alE+3S9luz/Yym5d7bxuSyQWD1N3ExL+zRBFFIAaFN7eMMPfZ2PNaHrOGVyNQ0irU8XpsL8PYsk0hDU8682gXXa7kUjFamceFVqcEu2kOhOyoVB80Anoy1mTk6NxYHXTDJavgA/yHRlnUDAYbHkobWQ6/kQdbEtxtYvkb4cYiDgpoaV7EqDd2xEsPAjj2L1+C+ELuVdthnFbrDvKaaZ84PPezb+7Szij/s7JO563cWATqFg9GHvS6uqZVmOVNhbTFDu4xX3HGqRj6eNb31Xqr3qq0jdQiwFt03kZZEASnBGj4lkm/G6KjC3aTQ9Qtjp+ElLAhm6qY+xwCdGk/Xdx9Dt/7l9HZ5iChwFDMmuwiCYJUL/HtcWYvIeCofcoNiyrYrbSzHyMmlJOPts9hiU3/AXpX1TZ2zfoCPIVJvlNp36RSQAGrIWNK0ZgNp2lUTajtErVAV4//gDXcAiNlnoDLnMw1GEXcQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB6321.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(376002)(39860400002)(366004)(396003)(316002)(33656002)(186003)(66946007)(53546011)(66446008)(64756008)(7696005)(5660300002)(2906002)(66476007)(6506007)(76116006)(52536014)(966005)(166002)(66556008)(38100700002)(71200400001)(55016002)(8676002)(8936002)(4326008)(110136005)(30864003)(83380400001)(86362001)(9686003)(478600001)(122000001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: kfmtNpa13MVPdg7DUdTEVK5l9F3n1pOJzzF3M3B7mgk9UepIeR/qI2h4tTf8Lnu9xGFAoVSwR1uHwXKiqpBRcBCQ8h0UHOh8jFrbbQA1fBM8w18Pr5PAHKeIIRbxTpVRSmqbef7LVB0ZH+RBeFh68G+oo0gg9NaMh/jYogrQMu+nBya90ztCfl1K+ecQW0Kv2/5VOjoCLBIpLZCynqSQOLbVE6oWtyp/x+S6f7//5zZo4kQECzvGo240Idp5gJPzSuBT4jWKcWMT8hPEmcy+nRVz8AyXyI+UC4nqaayr5uTVSHanbWqkTB/Njg2bMFWK+OlJ/bmExv5IXgzB4Vo856NImfP7RSKl7GZmw8gA74qNTlPK0vjPrFZf4PuSFRGauKs7xVsLx56Gb+bpWq+hPPGVXod6k26VJ5X9Bet5sQ7lQP14maeQ8YeGbHPwJJ4CdG4scAPGjGz+v4UDocfgrD9j1IcKH7DpZo4ymJi4x9dcPrd2LvGWR2W5LjvJL5phhIJjl4sJJmZEJa5Dfi7hQ6qQtsueJlPVEBeWqZ+MX3Ui2wuycfOFFa6zgZ+YL1sG6dvEWr1qKrmh3dpcZd7OchJwETfTkWuxUji7XKKJZR01HR3qnTI5oaj67mSkbG/THN7HyvbzrogMkp7jq4HpaDoGfFvla0wf9//4v4XeNw/M9zZY/F63IEAxZC6Av6Ir86tZyNp3pPB/UeFmhC2DmrHtDh2SiWaELdbhslpyQVxySbdEn7UHCggLxiS82V2ZohKOX6Bfw+yPGzPSkQ7LbKDTvZiI3iPw7maG0Xr8JnsPvEvE8jMq2YgNl1vfwzUz2ATG0ZtiM0pjnZMl3tt8+GV42W3k2JGmIoRhbDR2iGJriYbKTNEnEr+qkBNi5rXpq9i4bkmXZOLmaO9C5eFSmQ/O2eTtlyPxBuuc+7BXCBM44EoiRdfFolFEF2UdqWbMWw85yg1P6oHq0qzPw9lDQwEqyuwbNtNaG9swWD1OzXiFMmyYPGav/Dw5t4+yz8L7BScEtu47x+HtlOdqD/w67UGcCQ+XXQhYwQjthOF04Xt1KXoiYIKdAhqdbj1E8Dd3Td5kUDSXWL5qkgCRFz9ya+SN/eJvqpFf8dUCxnzK82icH6A6j8d8HBPA03Ioy2Z8rGF9mhhMdjecJ/nfdba1B3gCoDmMNL+r9007pNYX9v+/RmVu836YpAce73zbm8TI4z1K7VCxeZAGn1CkQ9XkaxzGaWnGfz6OG42252F9wUXwgJHQ7dLSpHhg3y/Mt3/llpkGLmAnJf2ynpre97HZ1UjaWxtHb5/nIxxXxXaETyiC5XISmCf/om9hIjAJiUJ/YInsEOIW7DaJb/r1y9a07rL/u6AZnEd7mOc+bAKRrogw/u6+5wE7P0CdqWuOlUn3
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB6321150D75F6077E0EE51C8AE80E9AM0PR07MB6321eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB6321.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9202af4d-bbb3-4fe4-8f63-08d93195324f
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 13:38:31.2901 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MV/e0nJ8Yx47Kjb4DGyVUwIywrIgftBL3lP4B3vr8wDYfmO1ARFbfzJt6DcAwpvdZsmCu1Bn+I/sERP8lmd2RUXxJR9GYJB6sRk4WCfIbk4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB7346
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/9Va0T1OF6e8xel0IHmLsNzT1jCU>
Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2021 13:38:50 -0000
Hi Les, The question remains whether an ISIS Appl-Spec-SRLG TLV with SABML 0 and UDABML 0 means that it is valid for all applications or not. This is currently not specified in RFC8919. Secondly the approach to handle ISIS Appl-Spec-SRLG TLVs independently from ASLA sub-TLVs in the context of overruling "All-Appl" attributes, creates confusion in BGP-LS in my opinion. Take the following example with TLV's belonging to the same link: IS-Neighbors TLV ASLA TLV SABML 0, UDABML 0 (= All Appl) TE-Metric 20 Appl-Spec-SRLG TLV SABML 1, UDABML 0, Bitmap SR-Policy SRLG 1 Following your answer, SR-Policy has to use TE-Metric 20 and SRLG 1. Now suppose that the node that receives this ISIS advertisement has to pass this on to a server via BGP-LS, this will be the result: Link Attributes: ASLA TLV SABML 0, UDABML 0 (= All Appl) TE-Metric 20 ASLA TLV SABML 1, UDABML 0, Bitmap SR-Policy SRLG 1 The server that receives this BGP-LS advertisement, has to take into account that it comes from the ISIS protocol in order to treat the ASLA TLV with SRLG info independently (as ISIS is supposed to do). I.e. the ASLA TLV with SRLG info does not overrule the first ASLA TLV and the server has to use TE-Metric 20 and SRLG 1 for SR-Policy. If the server would receive the same BGP-LS advertisement for the OSPF protocol, it can only use SRLG 1 for SR-Policy, because the second ASLA TLV overrules the first one in line with the OSPF rules. I think this is confusing and that it is more consistent to treat an ISIS Appl-Spec-SRLG TLV as an ASLA TLV in the context of overruling of "All-Appl" attributes. The fact that ISIS transports SRLG info via a separate TLV seems no reason to me to treat it independent of ASLA TLV's. Thanks, Rudy From: Lsr <lsr-bounces@ietf.org> On Behalf Of Shraddha Hegde Sent: Thursday, June 17, 2021 7:14 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>; lsr@ietf.org Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com> Subject: Re: [Lsr] Proposed Errata for RFCs 8919/8920 Les, > Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG TLV - and vice versa. Can you state this explicitly in the document? Rgds Shraddha Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Sent: Wednesday, June 16, 2021 10:31 PM To: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>; Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> Subject: RE: Proposed Errata for RFCs 8919/8920 [External Email. Be cautious of content] Gunter - There is no relationship between the ASLA SRLG TLV and IS-Neighbor TLV. I do not understand why you would think that there is. Whether ASLA sub-TLV is present in IS-Neighbor TLV and whether it has zero-length ABM on non-zero-length ABM is irrelevant to the use of ASLA SRLG TLV - and vice versa. Les From: Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>> Sent: Wednesday, June 16, 2021 9:07 AM To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>> Subject: RE: Proposed Errata for RFCs 8919/8920 Another item of ambiguity is whether "wildcarding" applies also to the ISIS TE-Appl-Spec-SRLG TLV. It seems that the RFC8919 does not specify it. Note: for OSPF the wildcarding also applies to SRLG info because it is transported via the same container TLV as the other TE attributes. Example 1 TE-IS-NBRs TLV Link x ASLA TLV SABML 0, UDABML 0 (= All Appl) TE-Metric 20 TE-Appl-Spec-SRLG TLV Link x SABML 1, UDABML 0, Bitmap Flex-Algo SRLG 1 2 3 Should TE-Metric 20 be used for Flex-Algo or not ? In other words, is the wildcard ASLA TLV overruled by the specific TE-Appl-Spec_SRLG TLV or not ? Example 2 Maybe this is an invalid example if wildcarding does not apply for the TE-Appl-SRLG TLV. TE-IS-NBRs Link x ASLA TLV SABML 1, UDABML 0, Bitmap Flex-Algo TE-Metric 20 TE-Appl-Spec-SRLG Link x SABML 0, UDABML 0 (= All Appl) SRLG 1 2 3 Should SRLG 1 2 3 be used for Flex-Algo or not ? What is your opinion ? G/ From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>> Sent: Wednesday, June 16, 2021 4:46 PM To: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>> Subject: RE: Proposed Errata for RFCs 8919/8920 Hi, I think that there may still be some ambiguity arising from the text below due to the fact that There are attributes such as maximum-link-bandwidth which have special behaviour mentioned in later sections. "Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such advertisements MUST NOT be used." For example, If max link bandwidth attribute comes in a Zero length SABM & UDABM and we have a Flex-algo specific ASLA that does not have the max-link-bandwidth advertised, can Flex-algo use max-link-bandwidth attribute? My interpretation from modified text for ISIS is that, it cannot use it. I think there is no harm in re-iterating in order to avoid people reading is differently. Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such advertisements MUST NOT be used. In other words, When an application specific link Attribute sub-TLV is advertised with one or more specific standard application or user defined application bits set, all link attributes that are allowed in ASLA MUST be used from the ASLA sub-TLVs having that specific application bit set. For the purposes of such applications, link attributes MUST NOT be used from ASLA sub-TLV with zero SABM & UDABM length. Rgds Shraddha Juniper Business Use Only From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Les Ginsberg (ginsberg) Sent: Tuesday, June 15, 2021 8:55 PM To: lsr@ietf.org<mailto:lsr@ietf.org> Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>> Subject: [Lsr] Proposed Errata for RFCs 8919/8920 [External Email. Be cautious of content] Folks - Recent discussions on the list have highlighted some unintentional ambiguity in how ASLA advertisements are to be used. Please see https://mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/prSLJDkMUnHm6h7VuCdn_Q7-1vg/__;!!NEt6yMaO-gk!RK_eZNNu1y0aJvAqIaNwHTIFAjHWFJwW1UqyOO8ACxB0kof3jmD_dRkiPkbVLJyA$> The following proposed Errata address this ambiguity and aligns language in the two RFCs. We welcome comments on the proposed Errata before officially filing them. Les and Peter Errata Explanation Both RFC 8919 and RFC 8920 define advertising link attributes with zero length Standard Application Bit Mask (SABM) and zero length User Defined Application Bit Mask (UDABM) as a means of advertising link attributes that can be used by any application. However, the text uses the word "permitted", suggesting that the use of such advertisements is "optional". Such an interpretation could lead to interoperability issues and is not what was intended. The replacement text below makes explicit the specific conditions when such advertisements MUST be used and the specific conditions under which they MUST NOT be used. RFC 8919 Section 4.2: OLD "If link attributes are advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes so long as there is not another set of attributes advertised on that same link that is associated with a non-zero-length Application Identifier Bit Mask with a matching Application Identifier Bit set." NEW "Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such advertisements MUST NOT be used." RFC 8919 Section 6.2 OLD "Link attribute advertisements associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications are usable by any application, subject to the restrictions specified in Section 4.2. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced." NEW "Link attribute advertisements associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications are usable by any application, subject to the restrictions specified in Section 4.2. If support for a new application is introduced on any node in a network in the presence of such advertisements, the new application will use these advertisements, when the aforementioned restrictions are met. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced." RFC 8920 Section 5 OLD "If link attributes are advertised with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications, then any standard application and/or any user-defined application is permitted to use that set of link attributes. If support for a new application is introduced on any node in a network in the presence of such advertisements, these advertisements are permitted to be used by the new application. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced. An application-specific advertisement (Application Identifier Bit Mask with a matching Application Identifier Bit set) for an attribute MUST always be preferred over the advertisement of the same attribute with the zero-length Application Identifier Bit Masks for both standard applications and user-defined applications on the same link." NEW "Link attributes MAY be advertised associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications. Such advertisements MUST be used by standard applications and/or user defined applications when no link attribute advertisements with a non-zero-length Application Identifier Bit Mask and a matching Application Identifier Bit set are present for a given link. Otherwise, such advertisements MUST NOT be used." RFC 8920 New Section between 12.1 and 12.2. Current sections following this new section will need to be renumbered. 12.2 Use of Zero-Length Application Identifier Bit Masks "Link attribute advertisements associated with zero-length Application Identifier Bit Masks for both standard applications and user-defined applications are usable by any application, subject to the restrictions specified in Section 5. If support for a new application is introduced on any node in a network in the presence of such advertisements, the new application will use these advertisements, when the aforementioned restrictions are met. If this is not what is intended, then existing advertisements MUST be readvertised with an explicit set of applications specified before a new application is introduced."
- [Lsr] Proposed Errata for RFCs 8919/8920 Les Ginsberg (ginsberg)
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 bruno.decraene
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Les Ginsberg (ginsberg)
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Shraddha Hegde
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Les Ginsberg (ginsberg)
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Les Ginsberg (ginsberg)
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Shraddha Hegde
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Shraddha Hegde
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Selderslaghs, Rudy (Nokia - BE/Antwerp)
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Peter Psenak
- Re: [Lsr] Proposed Errata for RFCs 8919/8920 Les Ginsberg (ginsberg)