Re: [Lsr] Proposed Errata for RFCs 8919/8920

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 17 June 2021 15:29 UTC

Return-Path: <ginsberg@cisco.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 9D32A3A243C for <lsr@ietfa.amsl.com>; Thu, 17 Jun 2021 08:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.795
X-Spam-Level:
X-Spam-Status: No, score=-11.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=h4QWIaz0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jfPP+XsK
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 rqk_4GZhM4Oz for <lsr@ietfa.amsl.com>; Thu, 17 Jun 2021 08:29:22 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C1A3A243D for <lsr@ietf.org>; Thu, 17 Jun 2021 08:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49139; q=dns/txt; s=iport; t=1623943762; x=1625153362; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Dnx4E0krbNqvGNhZ1vuxB3Hd4u3hzzk1Ddv2Cmud8aA=; b=h4QWIaz0lzZALhsU/lyiXwn7vDolxxMN3klRadittgb5yaWclNUuGzgp spmOMYorWIjTwNOQiSL9QTzVLDgUYimOmhx9VZQjddCcgpi9ojlKl8m7u ZP5cNkKab75yTXGMvdwnIMMkPVkYySD2Z7GN8ywE1qjEVcwsTxGTmS4Cu k=;
X-IPAS-Result: A0BjAwDnactgl4kNJK1aHgEBCxIMQIFMC4EjMCMGKH4OTDcxA4YkgWkDhTmJBAOaGoEuFIERA1QLAQEBDQEBMA8CBAEBgxuBNQKCbAIlNQgOAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZFAQEBBBIIExMBATcBDwIBCBEEAQEhAQYHMhQJCAEBBAENBQgagk8BgX5XAy8BDpoxAYE6AoofeIE0gQGCBwEBBgQEgTQBhAgYgjEDBoE6gnuEDIZjJxyBSUSBFUOCYD6CYgICgSkBEgEjKwmDF4Iugi4BEAFaBhcnTDEiLkGBIBSRFot1jSCQbYEVCoMfihKHMIxTEoNeiySWbJVWjB2Kf40iAgICAgQFAg4BAQaBVgM0LT5wcBU7gjUBATJQFwIOjX0iGYELAQKCSYUUhUpzAjYCBgoBAQMJfIhlAQE
IronPort-PHdr: A9a23:LDvS5BMY1ettf9WkLc4l6nflWUAX0o4cdiYX95wmk79UNKKu48eqM E/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EVxIMhcgM2QB1BsmDBB75MfjrdyEgW sJPSAwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=
IronPort-HdrOrdr: A9a23:iTmscakTS83TzL16bQYccQ25FNfpDfORimdD5ihNYBxZY6Wkfp +V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYOCGghrpEGgG1+vfKlLbalbDH4JmpM Jdmu1FeaHN5DtB/IXHCWuDYqwdKbC8mcjC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6 Dsn/avyQDQHUg/X4CePD0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZdbxp/hZMZtU TVmQ3w4auu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESotu/oXvUkZ1SxhkFynAid0idyrD AKmWZ5Ay1H0QKXQohym2q35+Cv6kd115ao8y7ovZKqm72IeNt9MbsduWqcGSGptHbJe7pHof 52Niuixuhq5R+splWP2/HYEx5tjUa6unwkjKoaiGFeS5IXbPtLoZUY5149KuZNIMvW0vFsLA BVNrCQ2B+WSyLSU1nJ+m10hNC8VHU6GRmLBkAEp8yOyjBT2HR01VERysATlmoJsMtVcegL28 3UdqBz0L1eRM4faqxwQO8HXMusE2TIBRbBKnibL1jrHLwOf3jNt5n06rMo4/zCQu1G8HLzou WLbLp8jx9yR6vDM7z44HR7yGGEfIzmZ0WY9ih33ekOhlTTfsufDRG+
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,280,1616457600"; d="scan'208,217";a="735641672"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2021 15:29:20 +0000
Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 15HFTKQF016328 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Jun 2021 15:29:20 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Thu, 17 Jun 2021 10:29:20 -0500
Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 17 Jun 2021 11:29:19 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 17 Jun 2021 10:29:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AnyB1WFqxtZ0b9d0bfOqhVoz++vF1MDxBsKVaokUh85THO/cwvDr8/ABe8h8N8PHBeA7PqD3Wh3ZWyvRkLswctTGkIKHu+sOGVYrekJa3nW2KxklCR/8bLNefePk527U+xI7rtpkx8qw3qvfoh8NadCpagLarAWwTURS7S0mlTGEDb0t8bufOckwgiD/5kKGml2ZdQ5zKGrt28/SeFBDz7ygRyPMeDR8nzHT2Gzifyvk92H+RpmunctTENsEaLbRyfFpOzKssVVc/7PtYXxLd4AfAiPhL9oYzP9y0BeUIjI1b1I6QWHtBXxhYtaiwDxQBi5ic8WsFedn2ueSE9nquQ==
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=tNpRf5zisT2zrnKGzhm42XQAkOQK59JXFpRZAKMY70c=; b=dE7NCu0+NNJw+vmqGRDOPJefcHnQ1KiHNJP+9ldIhop0qaBYW/Y6LkN9Rdy8hwm9ziFiYHBswjMs0G7MaDNZPKiPWCm3xHdQgoS+bZdx/3m88y+yNJbWIVEUmhjHlcnxfZs0YDFiBqldtuAjcPJPuLxlAaRxzUPoyRkjkbmsGH12hl1Mh+hHntJ2UI3IE9LHFgkgZtgkJAETviX9MBIzN5GI2POTgqyBfa2CU+VsOhvPY4xF+3uNos548k8gfufoPHOdV9udfKMxNWR8s6XxhtyWVNRks7/G7D8buymLrhkMAg777opSJhs9IC3vPh7bMxahGvOxlULQJzfoZ+M2PA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tNpRf5zisT2zrnKGzhm42XQAkOQK59JXFpRZAKMY70c=; b=jfPP+XsK/qmiuSLmKi8EoQF/051uvj5DzI1JxX9Qbtfi70yKihHtMkH2YtnpNtwF3l1EXofeosvycZkjobDWU2/KR9XhX2oYTKpko6mlLG/cY+TW6Dy7L55ixxGfFPgx2jOy3c/oMRz7/68cecJvtWPBSecrlYWmhgNI5v/EB7Y=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by SJ0PR11MB4926.namprd11.prod.outlook.com (2603:10b6:a03:2d7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.23; Thu, 17 Jun 2021 15:29:17 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::65f1:2ee8:c1e8:c9b8]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::65f1:2ee8:c1e8:c9b8%7]) with mapi id 15.20.4219.026; Thu, 17 Jun 2021 15:29:17 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
CC: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Thread-Topic: Proposed Errata for RFCs 8919/8920
Thread-Index: Addh+XAWKUvBLsteQNyAf8QRieIv8AAw563QAAQMLRAAGYeigAAV8uOg
Date: Thu, 17 Jun 2021 15:29:17 +0000
Message-ID: <BY5PR11MB4337560A915AA6CE1A762E93C10E9@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <BY5PR11MB4337B8FB7707B24DDE302182C1309@BY5PR11MB4337.namprd11.prod.outlook.com> <CY4PR05MB357627C26A90AE7E9C5C89F7D50F9@CY4PR05MB3576.namprd05.prod.outlook.com> <BY5PR11MB43370363782BDF31BCFDBEE5C10F9@BY5PR11MB4337.namprd11.prod.outlook.com> <CY4PR05MB3576CE8B2A29F8EB16F28542D50E9@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB3576CE8B2A29F8EB16F28542D50E9@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:05:07Z; 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: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2602:306:36ca:6640:70de:f0b:4da5:6839]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 86cff7e9-1309-476d-fe5c-08d931a4ab97
x-ms-traffictypediagnostic: SJ0PR11MB4926:
x-microsoft-antispam-prvs: <SJ0PR11MB4926448A62141F090954734EC10E9@SJ0PR11MB4926.namprd11.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: ZYloIwZUsy1BD6Khn2WlRl/7mNCIVugGZlMuqelRC0WlptlOLwhnowPFs+uPcw4mgW6CGutLJutMaYu74UwHTbG7Dr+5fanWMitGUEi0tXPqqOvwpt6LEeKoFRgzY5kC30CPDVxFlodqzhpspd0x3jt+zBN/ekr5U76L7hrZKEK3JOXYrVZsyqOShtMvW//vBsg3z4msnCQQp+M2CBr7EWY8aEmfKcpOAnbVhkSrg1tSBBBq/l0CN3WHAD7xvCGZUiUZSl60hnS9VF9QuEQyDO5Sag0A9FewxIw642t5HV21epXk4HCZstFfy/YVcdkxGA2UDR2GDyLnAJRBaXPvq0zBnkoNY82RC9FozvTBwOjnnaWsRrtzXYmomZnU57QUG0M4ml9iiA5R0GmeS73gIPIR6Tx7nVp2IuJVvUi/Qeu0i4EH/Pd/H4bie39ocnfWuxsMHRvyEoNDS1J/iMG6qzRAWt0SrMRoYvbx51AC6OFu4cw6TKSvWyvOPMKQAWgX4tcCXhb4Yg55KDVyGPDi0GvOEdse4UVtpdngr/g5hDY+96Ypw2d+B587li6DMkU5WBD3TPjNnGD8UXai0opuP4daK9wqT8Rw2Ct70b4ZPNUQNWowVnrZi28TJc1I9DB/uiGaxD2S9UN+WOqUqyl8X8pPiDv29ogpUZUSlXeYc/RFt2gEE20w6dIqqLu66Ap5st8xxeO/R5ps1Psxm3xWxnVqPPrDFbjuCwLkJ1bxxg8=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(396003)(376002)(366004)(136003)(166002)(83380400001)(9686003)(66476007)(64756008)(7696005)(55016002)(478600001)(53546011)(76116006)(966005)(2906002)(66556008)(66446008)(5660300002)(52536014)(6506007)(30864003)(186003)(4326008)(86362001)(38100700002)(66946007)(33656002)(8676002)(122000001)(8936002)(54906003)(316002)(110136005)(71200400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: sTpADkbAW7BeYzYwoK4mA1H8L3ayCrdLFW3t3oBV4UxGd+sVNBt08/T1HN+dN8T0bM9vZuUSwjCEI+6Gx/HlsS82uAFN0ss4jArr7rYuf9nS/J5tSjesbcX8qkj3teraZTgyFuPY5webz3c1XbxpunVA54IsK4GhFL9tfB3fmmLiQb2+LiD/gDlpBfXNH7IWD3Zn5OzpwdytZUxbaRPQZT6ulDDnsSc/wiFGdcCinb0harSolc84ClR/bciDqZQPSjOeY/DjzU/A/5vf14TGhGEb8WgXY6FGqnwP77P8fjOn1DCy8yswZrCd7zYKh2xR0ne1D2eNCKso6KzPfXNcKnea+R3kEmJLeQp2GUbJ6ssKKEFVLBCBBJncKrZoluZ3LemMpD4w+rxqgnolL5S3VaW1Sw8DDkL8WrKrTyvCCME54Lx5XDoFjQVCkoU05/nHYKcFeV1ddyKGd+cL/WQ7Lpwltl27QpY5ZJ4Ux0yEqh6BrHRjGIbHZjqJgpTcZufmANj9nomWQx4iXRfuPwJFLCT68+iIrMber4frj4UGrEBw60iub0rAxMlByENPplD66ISVHIK+36m1SsU0160Mswy5VnIxyrs4Qcu7TxBBX7nKcrQX9XcJ103ZsJZ7NnWpba4l0Lf71SmHs+1AaxXOcOCdNv5MXjOH+0L1y5Eqc+VBJuJ7y/es0Wk8JjTOzpWbpKzgz9L4yFSf73W7HQPBF70dYuT0vHekQ/PP4ZmzcioRvLZT9pwHAGF2SsMQmkKVc6cGZlvj584fhkJaYbNGF/6pvKua+O+SXovjBIf6kaz5lpHwyZ9lW+/vqXp5lmQx3rb/VzCukR8Ipfx81bkcymVv6KNe4OdOTJw9KqPwfTnKJU/cz8AYdbMjPHDweHDjG+hyBcray5Ay7QzSjC2EXalIIDQBkB8zbS1OafvpXJmyKA62PeUqqr9xl/+eUyAybPl01YHX2GbSjtzJ251AOxf1ps4LLgJgxFxcC6dfr8oq0y7cLpE1/wPzPj4sXIwkLsw+wIqxhI3/tHBNBXu3kEA458eKjzZKEWy5ttTnBKyyEGz2ykKnDngBH7AIkNPbJqgG8JnQmvgLmC3OSGv6A89aUj1HZDgNz8HLpLDFHdFFcA5CjsJxSrnaN232Vh5Pp3WTIPaDdFgsmGeHS5Bzp6FyAYWBrrlA846mh/vaIjaijQ5LBwEeoOLsdPjw4HTWNK0tunSElBfKhqfs1bVb517/XyATr+qNFUQi4gU8tmB41x4h4A7HfH3y4Hq0MaWNJE+/W1+9HblwzSoEFJZ0p5JailmtZI4Td0ErH6F3lcr6OAmPWnPAV7TD/FsHkDikRQLDcm/fYoRHmZgBhf17JGJ/2eIQq46fK/CT8KqjcyUTvkrbD08Fyi6pOV2n3S6p
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337560A915AA6CE1A762E93C10E9BY5PR11MB4337namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 86cff7e9-1309-476d-fe5c-08d931a4ab97
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 15:29:17.1509 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HJx+pSxN4pjge6OGK7L0gu0+gb6sEYX3JfDgdI+FUYCN8HxCCDyR+zgWz83XyP69QoEFBroOBn/BJ1skaS826g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4926
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/VaHHtsrrOV7idi1fGBVuojsaOr8>
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 15:29:28 -0000

Shraddha -

New text will be added to RFC 8919 Section 4.2 immediately after the existing text:

"If the SABM or UDABM Length in the Application Identifier Bit Mask is
   greater than 8, the entire sub-TLV MUST be ignored."

Additional Text:

"When SABM or UDABM Length is non-zero and the L-flag is NOT set, all applications
specified in the bit mask MUST use the link attribute advertisements in the sub-TLV."

Here is why I prefer this change to your proposed text:

Clarification of when advertisements with non-zero ABM length are to be used is independent of zero length ABM advertisements i.e., even if we had never specified the ability to send zero length ABM advertisements, the above clarification would be meaningful.
I therefore do not want to tie this new text to the text discussing when zero length ABM advertisements are to be used/not used.

The presentation in Section 4.2 then can be summarized as:

1)Define the ASLA format
2)Define  when nonzero length ABM advertisements MUST be used (new text)
3)Discuss L-bit
4)Discuss zero-length ABM (with new text previously  proposed)

I think this is a clear and logical presentation which also addresses your concern.

Thanx.

   Les



From: Shraddha Hegde <shraddha@juniper.net>
Sent: Wednesday, June 16, 2021 10:05 PM
To: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; Les Ginsberg (ginsberg) <ginsberg@cisco.com>; lsr@ietf.org
Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Subject: RE: Proposed Errata for RFCs 8919/8920

Hi Les,

I am proposing to include the text I sent along with your text.

You basically want to imply that when there is an ASLA advertised with an application bit set
That application MUST use all link attributes that can appear in ASLA from only ASLAs
having the specific application bit set and MUST NOT use from zero ABM ASLAs. I agree it is possible to
Derive this from your latest text but I would prefer re-iterating this fact more directly than
Let the readers derive this information from current text.

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 for a link 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 that link.
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: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>>
Sent: Wednesday, June 16, 2021 10:26 PM
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>>; 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

[External Email. Be cautious of content]

Shraddha -

I believe we are in agreement on when zero length ABM ASLA sub-TLVs can be used and when they cannot.

The new text we proposed is:

"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."

This states both when zero-length ABM advertisements MUST be used and when they MUST NOT be used.

You have proposed different text:

"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."

This states when zero-length ABM advertisements MUST NOT be used - but it does not state when they MUST be used.
Instead, it states when non-zero length ABM advertisements MUST be used.
So this does not seem to be as complete as regards zero length ABM.

You seem to feel that there is confusion as to when non-zero ABM ASLA advertisements MUST be used - but I do not understand why that is the case.
You mention Maximum-Link-Bandwidth - for which there is a dedicated Section (4.2.1). The need for that section arises in order to make clear that different values for maximum-link-bandwidth are nonsensical and if they occur they all should be ignored.
But Section 4.2.1 also references Sections 4.2 and 6.2 to make clear that the same constraints regarding the use of zero length ABM advertisements apply to maximum-link-bandwidth.

So, I am not clear on what text is currently confusing, nor do I understand how your proposed text clarifies this confusion.

I am open to revising the proposed text - but I need more help from you to understand the source of confusion.

   Les


From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Shraddha Hegde
Sent: Wednesday, June 16, 2021 7:46 AM
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: [Lsr] 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."