Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Shraddha Hegde <shraddha@juniper.net> Thu, 27 May 2021 13:01 UTC

Return-Path: <shraddha@juniper.net>
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 CED7D3A091F; Thu, 27 May 2021 06:01:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.696
X-Spam-Level:
X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=CGwKg6m7; dkim=pass (1024-bit key) header.d=juniper.net header.b=RLW2pG+E
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 skbTUYYuvZsk; Thu, 27 May 2021 06:01:15 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 4DC443A0916; Thu, 27 May 2021 06:01:15 -0700 (PDT)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14RCxNUb020848; Thu, 27 May 2021 06:01:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=uYlykysZId8yWbXsm4beVyw8/QdxRLgNbyJhpB6wsHw=; b=CGwKg6m7rR6e6T7hhNrpOHkmJrST1IjLRjOf9y/Kpyme+kD2RBm4kfOOm7pjugNg8snU slge+dPJjMgEx5U2C7/iEGT4aWOEJvbwr6b4Rpdw93JBfOtUiE0nHysPfyE/beF56O/Q SzJtnWaiYC/DWYUl5Sezpr5TV/ZIo8gxNqDVKRw7Yvt03EM1Sp502TumhA78N+tBQckB u06ujcjY1aHwvu1m7/X1BlanGi3etGdZJmsVAYoWf4A+JB2LWl6pzjiVGWGZIPq5tU5W 2SeLLnAQhRFVG50YdxMph+kVbohWeWc7AhLtZJh+YXZBn9tdcd9QDeWYAVmjTS3UsESI wQ==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2108.outbound.protection.outlook.com [104.47.58.108]) by mx0a-00273201.pphosted.com with ESMTP id 38t34a92ms-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 May 2021 06:01:12 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EOyoVPfWh3C+Mn9R1ZKyBR1teaceqCNsr0+ru/shKIolFayqGsWuMV+N5VpZz37MWUkSyYz/lyW2/bNFMA0cXAhxi7hjiQPgdLcEsK/jbiozuqnS+FW7tWCe5WKv8IYjOGey02HzOdk7k/WgY8rxEfjhuBgrXHicSk6zxNUst0xLoeBMAxo5uGfU/+STE2DCi5SOEdIm3VJjY/MfHZ+fbwNToGl7R8bQ6hhpWUcuoXiKKLpm6MoO/lu5YianAtcKZoEN0rZlfc79yqxZ/n4rPkawJ9fMXuTTiZnzt7KRG3GPJJ60AlSjwvhg4FWXcz+kcjcV+04Mx/9sgMh6t/eWRg==
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=uYlykysZId8yWbXsm4beVyw8/QdxRLgNbyJhpB6wsHw=; b=mNcIEAKCWhUG+KA3nnyQw0tnP/yWLNpQ/4L0HEe9abiK8Rk/sFmnTmIigR3tZr3KcppdEv1VaFIDyrDExuRpTL2MSZ+OYahfI/f9H422DEL3ct6j8/YFgbo9S0vPKdDEz+P+UF2jLfyD/LfQX/kfISP0EVC8dkRZAHws7CxFqb+Lxu3QIcd9RbSwRUEbORXpTpaLMbyq1+uWBavL4MsXOgazJDVCAkmXt/rZjlfp/039MSSgVPNMHhDbxLT4Rdgfgd8eVcRfM0BENjqNNazL9YbEYsAmFQlKQJIYIBitBD12AynwH6OWXzAQqL98YUF3TB8vVp3l/x/D4N+EA7UTVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uYlykysZId8yWbXsm4beVyw8/QdxRLgNbyJhpB6wsHw=; b=RLW2pG+EXgrS7mxsZByp0vtB/H16XvAeCzO2Qea8+6/0PB9n7quZ7OAheQ855TL+gXpuALz8Ci1xm+40Usgfl98rEs3WxZayiFNWq+2QIA4ieCjXovLpiyhrqPibQ+/Vw0CTpLg4FVjloRr0EL2FcEQLxEUMDzWvY/iSwsn66Os=
Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR0501MB3746.namprd05.prod.outlook.com (2603:10b6:910:8c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.15; Thu, 27 May 2021 13:01:08 +0000
Received: from CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::2cb6:435f:f75b:1602]) by CY4PR05MB3576.namprd05.prod.outlook.com ([fe80::2cb6:435f:f75b:1602%6]) with mapi id 15.20.4173.020; Thu, 27 May 2021 13:01:08 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: Tony Li <tony.li@tony.li>, Ketan Jivan Talaulikar <ketant@cisco.com>
CC: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "draft-hegde-lsr-flex-algo-bw-con@ietf.org" <draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Thread-Topic: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Thread-Index: AQHXR3MLVak8G/B87Uy6Hz9GuLxph6ry6AsAgAAi2ICAAk+LIIAAsj6AgAFSw8A=
Date: Thu, 27 May 2021 13:01:08 +0000
Message-ID: <CY4PR05MB3576B217AEDF4C58353EEB83D5239@CY4PR05MB3576.namprd05.prod.outlook.com>
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <MW3PR11MB4570FB10A5788FDA3BBA6C91C1269@MW3PR11MB4570.namprd11.prod.outlook.com> <AE6570D7-062E-4F8A-92E8-120FA52D4785@tony.li> <MW3PR11MB4570BF55DAA30AAB9E25D7EEC1249@MW3PR11MB4570.namprd11.prod.outlook.com> <82697C23-4283-4646-A266-F67828337C5C@tony.li>
In-Reply-To: <82697C23-4283-4646-A266-F67828337C5C@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.100.41
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-05-27T13:01:05Z; 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=9d7db09f-46da-4f28-8bcb-4c26a0fdf253; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [116.197.184.13]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ab76d553-f19c-46b5-ee27-08d9210f7ec7
x-ms-traffictypediagnostic: CY4PR0501MB3746:
x-microsoft-antispam-prvs: <CY4PR0501MB374689567246102A97D545C2D5239@CY4PR0501MB3746.namprd05.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: r3qoxHbBS6kyyLxQPgNR457vjR/3EExVuBPkJM1vbdxUZe7xKyjU3MzPfFLtxs+xdhv0YuQ75RGXDW7RROhbdD5ngAemt1WNn0srNBlOFoNR4gI+c0Eus/mEK8NxZww2g3HtQ9kof/doYLClbYGdylH5yhEJT5ydCt8PrzZblhuHeph4A0GMMgX+np2qZ5d+NW0yUTXk1xYlkoNXC+jHgu5C5trNOediO6XCHtlQ/Cv4k85fO4aWkBQMEjRyi326y5FEGGQ5hKbo2f61iGOUz6H5SQ45aVLdeIEy27CpZz9Yr7sF4uIEAvRps2Vta7Tx7itc9mDTmiozn1IbfTCka0kWRjNqkB1nb69Cvi5Ftrlc4Lkcxhd9AEtaK6BAq1eahynM4swNowm8ueZ3B0hABsClc9SR+I5cDJw8hD4cWpgF49HUI5hVONR9WVKFrHlTGsVlRultunMRUuTRnhtpTrpMwPzWsdR1tBu9RYrJTEdKAGRVTqEdyStkHsNtvqCX3G6T65qirlpBFGNj2/XPeSSX0mdFl6bCxq1vQnSOCKZNklnZ73YQjVIX99xcsnjoGaS4K+pgDebP/iQUxfxuwhOrz8elIwThaSN1c7MlBDmbeCdPoh550fhZgecy8Su50MyYVHAw5yP/mwZiz41VLDr/tRczKCDuPWuXLB3FC+sBMOdzFqRTKG7/fK6GBUhKHi76l+5tLk/SKMfZXgNbKw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR05MB3576.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(136003)(366004)(39860400002)(396003)(346002)(5660300002)(8936002)(478600001)(316002)(9686003)(53546011)(6506007)(86362001)(7696005)(2906002)(4326008)(966005)(33656002)(64756008)(66946007)(71200400001)(8676002)(52536014)(55016002)(26005)(66446008)(66476007)(66556008)(76116006)(186003)(54906003)(38100700002)(122000001)(166002)(110136005)(83380400001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?I5HQ4GFe9cWr0gCLNJDKIWXXrVklxiPw2WnZ5REUCp/2Jr6HrPDos/4QwVwZ?= =?us-ascii?Q?rE0cXVg2LjonTdCwA61FcUpxddTG3/jf+Zm7s9/9JHbrqDGo0bwjjeXx97rM?= =?us-ascii?Q?DUiddswbWRVaWu1ej+oOP4XLwX83WJ0aIq/+TAkuLSxJudZVaMX0GSGS/YgH?= =?us-ascii?Q?kyCnwKFKvNNvSYzW/G/FrLX3056F6+uGT565PtukqoypdIBbr4W8sWCGwYr8?= =?us-ascii?Q?xcEBZ3bmFqZ3qk6uCdL76PkHYTWFxT/DMmYtXb8zGRuHHd+SEWEcpca5RZvF?= =?us-ascii?Q?FKbUTkBRKRf5G7rVrFhimUuahs18muxryEq/ERtTFPj3YWPaoUlnB4uWOdpK?= =?us-ascii?Q?iQdZCNWYHNtQ3TgvSdnXUfIi4b/ezdOmifTD7k4P5Mf4ptyV3cxXiNZGOG3A?= =?us-ascii?Q?fI1OoUV2nx8wNrjat7sKbIIHIgS8A7hVVF9Y8iZs7F/buIvHr3yqB2iHRyN2?= =?us-ascii?Q?pRacF1IiuZFvs4e2OVKQRt6APGQKWducm/hr/zEnqwwkj7ahU16e50atIP4b?= =?us-ascii?Q?xQ8itEjLUcqgAH6XFXHPw6MCQqY96Id2UjmZI4wl9Wr3CDnhxt3+0+dSmrqW?= =?us-ascii?Q?u8hjLbPjoaE3dSzil5IDhMAasJ5i66jj/TX8STvnoGNt5bI0GKsUjqvumzU6?= =?us-ascii?Q?hZc/B9MnMU0nG+qkzX2qbqSGj4hHgvYMlWRTOc21XG8lwIi6KQdkMjkAXiGo?= =?us-ascii?Q?u0cP1kDZ4s/QiJqUP6CF4HpH42YRWniDxWwgxINmdE/4sIxEaKmoB/MPf9VG?= =?us-ascii?Q?kCuP4/1pbuSxtWK/WxQOQy11xtHKf31XhCQETSq6ozpspXMl/yYgG4s5S5SM?= =?us-ascii?Q?WOH7iLTA9BUg83G2pJJM7ndckLOwzwRIewYgiKM8HzenAAuxhuUOHCKZw3LF?= =?us-ascii?Q?WsLUaqqZdMjpBTrNWaDsub6Sbw0O3vDZejKCBxiU6ydC1lMgQARVWEg6I4ea?= =?us-ascii?Q?uNSTknBvDQJ+8sXyh0QI9Db6vfnHUQSTpEWdkUnUdF074/u8EjKfY6yA8b8e?= =?us-ascii?Q?TGHdo0IqwrfR1bKYd+KrA79kZz11s2N1TaOOHT6M2MXPLHu3ff/3DtWKqQaq?= =?us-ascii?Q?daMs3k30s6JcUfzaHKMiPa5RPqlHsfO5lQ/XkZxAOkoRRecqoVVRtsBCQ7xh?= =?us-ascii?Q?Of6GzU3FLq4UzXcg70jrqVg6NOZ7XWSdkKRdAs5Z20nef0i68eEINp5KmtVh?= =?us-ascii?Q?d30uQShrk91tresobaJoJF2k9l2hzS9ZMTGeX1oF2MTu5OVflLn61dh9duxg?= =?us-ascii?Q?7J48o/6qMZ/o2oGxXpY0Ul2SNAycgaNNUj8hI37SHD6mnWm7109DULJWNUJu?= =?us-ascii?Q?xd4xvwp/I3NEIw9Ya1riJsoK?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3576B217AEDF4C58353EEB83D5239CY4PR05MB3576namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR05MB3576.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ab76d553-f19c-46b5-ee27-08d9210f7ec7
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2021 13:01:08.2914 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: agUvGJNBG8+kmOv42Y9o9eDjspdb1UsyntjoO9m7jucVZdXEw4mHH+QcTfMWQ2i0ZoW3vybHMeTGhDF0d7SVlg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0501MB3746
X-Proofpoint-GUID: 2pkeF3bSDoayl7V4eklediHGii6wPdlL
X-Proofpoint-ORIG-GUID: 2pkeF3bSDoayl7V4eklediHGii6wPdlL
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-27_06:2021-05-26, 2021-05-27 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 bulkscore=0 adultscore=0 clxscore=1015 phishscore=0 malwarescore=0 spamscore=0 impostorscore=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105270087
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/E8xqmpiZ7zlyMzWJ8TLrRU8UjmQ>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
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, 27 May 2021 13:01:21 -0000

Snipped..


5.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>4$>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>?


I'm sorry, I don't understand this comment.
[KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$>


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>] MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in [RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>]$>].  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested this, updating the other two protocols.


<shraddha> As per RFC 8920, Maximum Link Bandwidth cannot be advertised in ASLA. Will update the text to reflect Maximum Link Bandwidth sub-TLV in Extended Link TLV of Extended Link opaque LSA.

For ISIS, Maximum Link Bandwidth sub-TLV is allowed in ASLA just that different values for different applications is not allowed. Maximum Link bandwidth is also allowed with all bits set to zero in SABM/UDABM  or each individual application bit set for all applications making use of ASLA.

RFC 8919 sec 4.2.1
"  Maximum link bandwidth is an application-independent attribute of the
   link.  When advertised using the Application-Specific Link Attributes
   sub-TLV, multiple values for the same link MUST NOT be advertised.
   This can be accomplished most efficiently by having a single
   advertisement for a given link where the Application Identifier Bit
   Mask identifies all the applications that are making use of the value
   for that link."


  1.  Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.
<shraddha> As long as we have fixed length generic metric, there won't be any changes to FAPM. We'll add a section to clarify about FAPM



Juniper Business Use Only
From: Tony Li <tony1athome@gmail.com> On Behalf Of Tony Li
Sent: Wednesday, May 26, 2021 10:10 PM
To: Ketan Jivan Talaulikar <ketant@cisco.com>
Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>rg>; lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-con@ietf.org
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Ketan,


  1.  Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, I do see MAX METRIC being referred to as 4,261,412,864.


Because I'm a lazy sod.

It's far easier to detect metric overflow on three byte values than four byte values. True, four byte is not impossible, but it's just quick and easy with three byte values.  Adding a fourth byte would add range to the metric space, but in practice, this seemed like it was not really relevant. Most areas are not a very high diameter and the need for detailed metric distinctions has not been that high.  Thus, we went with a 3 byte metric in RFC 5305 (sec 3.7) and that seems to work.
[KT] The Generic Metric is by definition something that will get extended in the future and we don't know what use-cases might arise. It doesn't seem right to follow in the steps of an administratively assigned metric type like the TE metric. Therefore, I suggest to make it variable.


Thank you for the suggestion. I don't think anyone has suggested a variable length metric before.  A variable length metric is difficult to implement as if the length exceeds your processors word size, you need to resort to long integer software emulation packages. These are a huge performance penalty.


[KT] Regarding metric overflow, I think it would be better to leave it to implementations on how to deal with it. A guidance similar to below (from draft-ietf-lsr-flex-algo) would help handle the condition in a manner that does not cause interop issues. Theoretically, it is something that is independent of the size of the metric.

   During the route computation, it is possible for the Flex-Algorithm
   specific metric to exceed the maximum value that can be stored in an
   unsigned 32-bit variable.  In such scenarios, the value MUST be
   considered to be of value 4,294,967,295 during the computation and
   advertised as such.


In fact, we are not specifying how implementations deal with it.



  1.
For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>4$>, in case of ISIS also, it is not really appropriate for use within ASLA -https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8919*section-4.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxHHnJfE7$>?


I'm sorry, I don't understand this comment.
[KT] In https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02#section-3.2.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-02*section-3.2.1__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxAEMtKzf$>


The Maximum Link Bandwidth as advertised by the sub-sub-

   TLV 23 of ASLA [RFC 8920<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMntRW1t$>] MUST be compared against the Minimum

   bandwidth advertised in FAEMB sub-TLV.

And in the https://datatracker.ietf.org/doc/html/rfc8920#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc8920*section-7__;Iw!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxJfyA-14$>


Maximum link bandwidth is an application-independent attribute of the

   link that is defined in [RFC3630<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630__;!!NEt6yMaO-gk!RnUnB56xWLSsNhl6V89tximFfO34nZ_CSZD-HtoxBg6g9qBJ8rOO1artxMwurpJX$>]$>].  Because it is an application-

   independent attribute, it MUST NOT be advertised in the ASLA sub-TLV.

Somewhat similar for ISIS as well.


I'm sorry, I'm still not understanding your comment. Are you objecting because we are expecting TLV 23 in ASLA?  I believe that FlexAlgo has already requested this, updating the other two protocols.



  1.
  2.  Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric.


Nor this one.
[KT] Generic Metric is used for the links. When we get to the computation of inter-area or external routes, we will need to get into FAPM. The draft at a minimum should discuss the applicability of the Generic Metric and its use as FAPM. Now, if we do make the Generic Metric size variable (as suggested above), then we will likely need a new TLV for a variable size FAPM equivalent?


We would need a new TLV regardless of the metric size as the FAPM TLV only carries the default metric. We are not proposing that TLV at this time. That's future work.

Tony