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> Wed, 19 May 2021 10:42 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 6B2AF3A25E5; Wed, 19 May 2021 03:42:15 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=0OXR9fkB; dkim=pass (1024-bit key) header.d=juniper.net header.b=g/PhR42x
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 NWV7ISsPUnFh; Wed, 19 May 2021 03:42:10 -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 DE1C03A25D3; Wed, 19 May 2021 03:42:10 -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 14JAPKrR019724; Wed, 19 May 2021 03:42:06 -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=lMiAIxbzNZSIYtQwsaIAgnCctI9k2629C5GZKjJqOVc=; b=0OXR9fkBnwHpW/GbW305nDfUzyi+XzloieR6Gb8uW/4sAKrqoNSBXuGsNYZsURplpQz6 q7xq99Zc4N7Ij+WkXobwwuRYqRneW7uE15Ej+h06hb4fQa5QMsKvPLJSaXhDAIl0gCyt FVJR4IJ9a3TdEB9IYiH16+Yf1aBp0dwofknj4gsdbrJMyS+758Y7Ux5tH0+7pdzjdWs4 SEZzR/SzWwVWfOEbY0EwRgqLrjXQ3w0RcByActpHdU+rPW0l81v2Q98fGmRUqVRQPZ6t FfGlGliHGV78t2rwS8CTjboxLh8gYKQD/FzlMl71VO12j3MjlUBpz68sZdeFjUe88XC9 dg==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by mx0a-00273201.pphosted.com with ESMTP id 38mtnxrje3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 May 2021 03:42:06 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XoHpYUtyV8J7R9nZN3IAX+fbdWWg9GBqsSBnO+JMC8e3cZboDV6YUKA+CLaSh2FpVK3/NOiLj1VGSPq8fqft08YSpcYQDE9B1ne0vsk0G6Ye7K7PtXG6XEb9/IvM1+z+AgXoMkB4GVlWvViOtVNHTqm2N10LQnuKBA89kwBw/ZJ2RSJCz8OTDqPK+1VU2P3sD3DgL2y5rTJRksG22iUii0Na+viRpAH/InIjKjzIf/eFZJCfDF4sh9pITlEN0U7EOXF6rGevgBUWV2Uv8mAEBOZkjDoAQkyEwo9Cha0/d+d6Qp5vzIHlhP/DiJ9JgAHMSEu333WfdVc5fqhZdRfNVQ==
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=lMiAIxbzNZSIYtQwsaIAgnCctI9k2629C5GZKjJqOVc=; b=Mvz1uYUcE0JnOVNgPahkNhy3N9uGpVn1jZ9FF7Xvwh6564RvBWlglxc2r2CkWGzCEddIY9njIYKz1J1EZNC4hDeEiUPAoj/4ZbvUXKloRq4qGC96uLdY7USEkn0W9UPFQuhbxWEJ6oo+9eQKPXBXm0kywwT1VLC2jvviGvSwtrtILjxWLkgqfY5p0XKaeKubANGX4AUp+6HjAq6MfLDAZXvCxQ7kluPxxam6ZRab1M7itZhtdWbPzcPQL74L18kzyJ1RSPoMPNmbv1NPr9D3wSvR3U7ZLPzOETtOwZbt0Cr60Zr9ZguWlcI8R2hMN7ih3Qzlz6nPMrwoKGqlAJ8d1Q==
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=lMiAIxbzNZSIYtQwsaIAgnCctI9k2629C5GZKjJqOVc=; b=g/PhR42xsnKKjxWpwsfjSKiUNMMVT2GuLFaJsS6ne0b1Ufi/YImdg0Ys395+M45YX7hdfXcOwUntAhE2Qv9O3SNaFZIo8pmGyE+HYyuwLz6szfJRHhjP3KgKLCC0RsBv2vc9Zt+JATcVk4hGQ48qIgVbjyeVC6L46b6TvTc82Es=
Received: from CY4PR05MB3576.namprd05.prod.outlook.com (2603:10b6:910:52::22) by CY4PR05MB3144.namprd05.prod.outlook.com (2603:10b6:903:f8::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.11; Wed, 19 May 2021 10:42:01 +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.4150.019; Wed, 19 May 2021 10:42:01 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
CC: "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/B87Uy6Hz9GuLxph6riWwyQgAYvaOCAACxVQIAAKt7AgAGzZDA=
Date: Wed, 19 May 2021 10:42:01 +0000
Message-ID: <CY4PR05MB357689A750C9BFC19E2FC7AAD52B9@CY4PR05MB3576.namprd05.prod.outlook.com>
References: <0BAE6DBA-04A3-4A3A-A1E3-14EFAA0FBE68@cisco.com> <6ba087997bc1433babc8f3c00b7998ee@huawei.com> <c64e5d848b584d8bac2e0841ea69021d@huawei.com> <CY4PR05MB35765125D0E54D1CB3637B68D52C9@CY4PR05MB3576.namprd05.prod.outlook.com> <054375c607fd4fe2b95b35b435f2af41@huawei.com>
In-Reply-To: <054375c607fd4fe2b95b35b435f2af41@huawei.com>
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-19T10:41:56Z; 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=4ea86d46-6c56-45c8-9229-2ee687e656bb; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [136.185.136.23]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c6ad17d1-5269-4472-f7bf-08d91ab2bc75
x-ms-traffictypediagnostic: CY4PR05MB3144:
x-microsoft-antispam-prvs: <CY4PR05MB3144B778430198D87C9771E7D52B9@CY4PR05MB3144.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: tvVVVXcSKuWlsmM9tJtA0IW5ij0snaj2oTciVxkSIPCnvS6S8OmjEpqTWQOyVV3V3J/sx1IgQrwEhahup7Ah/ULyXe3LIijWILnOxdq7uI3H3n+dfzLzkZLRIAuwa47V2mF4Blhay5O0jmEu5cX1ZGMla22Mx1z/Ur52/8UP3kF94glw5TnG2xgiipdusrWksqBr/ajzSZwkKuEh8x6HfSpL2RKL6wL4bq1aNm5K+O7afK5FVF8ON+UZrM+xpioOuIEd3PJatLuVjbfeRtNTCMR+ZeJpsmgyS9h5D/gVCB9MDkfz4j/DpjMSXj6WbDoQjYTS+CC+YslObTDlDOMxyndWPlxXxwCdb+4IT9QO/O5lxAqKK5bN5RKSaxjmf994aoE/JVo76s3l2w5jTXPcmZU8s5ivoR6LGbiuuC1V6Uyu0gbNtnvjA41BLy2hJSQCkbqTcEAxiLyxuLyPDN3L3/Ixa5TPU5YH7FbaiO2nvjo46VPDLHkh8KI1PJI6+6G0tWvgbLAzwvLqo1Ga9QfeWLuWHf3wdJgh4qRbBFZaXnK1mvEAqsTL7szuQbfbhM4NdIgp+nAC0wVcj6fopyugnFDQOBuRTYlKEVhDXt6itwgfy1F9/9p4lyG9Fpj6/OcSO+I/MKBcu+v6/b79Hj4swIxmRdHoFZEyrLdzwJRHD7qxqe7soCSD+diGz3j+ic1U
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)(396003)(346002)(366004)(136003)(376002)(39850400004)(8936002)(316002)(6506007)(8676002)(76116006)(166002)(71200400001)(33656002)(2906002)(478600001)(9686003)(110136005)(66556008)(64756008)(7696005)(66476007)(66946007)(66446008)(53546011)(5660300002)(52536014)(86362001)(38100700002)(26005)(966005)(122000001)(83380400001)(186003)(55016002)(4326008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?6jLAv3MperTdsz4JLdbQW8gMY881xUTPwrFk+1kid7f438x4j5+hW99nWk+T?= =?us-ascii?Q?yp4N3F63EghuUwXg/IOCL7gNZs7p/DBhcv1xN6Ps59KYJNP5uL0AoqpPuXvA?= =?us-ascii?Q?QwaRG3n3JowmTPuodZzzo/J8tf8L1IJnbiCA85JWxIQ04yK4byDSJ4SEEQxJ?= =?us-ascii?Q?LSOx/o85tKqyioeO7lV+xvqDQEmfaHD/OJUuA2cFV2SOvVuoGrX764z1EnUV?= =?us-ascii?Q?WR9sA7pT1lQM1PCtvTUQFfYyHdK/pbhCZX5Q+V8fWwH7hobN2Dzz4H7S+wq6?= =?us-ascii?Q?IQQCFN7zilJ743oVqDZVSMJmfnZRb20j0WheB8RLkL/3hZpTK8X9kl5NgD7e?= =?us-ascii?Q?f7T7CpLIqGpGQPnfCqMt7DkSBaHnyhmFkUByEMY4POPIz181a9QDb99S9eE3?= =?us-ascii?Q?/RTyCZHmKFjX/HnTTy4GV+xoCPHEUWesI7lG+IR93Xqz1wEDaSTBkYmQxkH8?= =?us-ascii?Q?0Z7YYBKH8O0AN2E1pYwZH3WouLjpS1t9/MdET5xUkz1ZntjQxTDpO6rWA/bI?= =?us-ascii?Q?26ViDj+HLDv3ZF2+3iVaPALRr/qKm3ZoqPWoFFqJJTTgx7erwkqQtONih+W8?= =?us-ascii?Q?+YlFbZp2F9jVQYZVA6taG25nJ4EkrV0bzI0YT5zh74esZ41OcJ2onnsS4v7I?= =?us-ascii?Q?wdK30JW3CXAz2l9aJ/bxFL2off7PpHqQOYCPm5+Ji6s/HpsEnGCMt7X+zvNG?= =?us-ascii?Q?GrQ08Lv8lzq5l9hxOEblLXAnXlTWkJi5Lq9zI6CSexwTEdVSDizt3PKeMWXr?= =?us-ascii?Q?iagSQ1+Y4GRolZnO2YzVqksi+3eUf0Md2z/JXSSqVQmzSp5bIP9mMV/nSbGV?= =?us-ascii?Q?seBD+SKKYaz8jwL5Sp5WdX7DgsRfEEsb68pnCQq2lp6RqVIXW2twUy3OqHxc?= =?us-ascii?Q?5o4WxffUbojOkzoQZ+w4Gl4h/Ay0y+9GhVGRCV7U4rJV5RzSZoeScV+dXFnp?= =?us-ascii?Q?Dwd5t2yvlYMRL1/2rw0t0UOUjysBU8rBxX1gFnJz5Y4KM1Jg7dU5w3aC/6CA?= =?us-ascii?Q?uHzk6GBqFcRA9s4/kiCxt0n061arEY/ADLdzW0VwHDH7QjvCF+bU2k0vke0p?= =?us-ascii?Q?CyHlLEentv6MAslwffb+p8daFDwtucswehNSLBhy+GcCajIqQVocjUGBzAms?= =?us-ascii?Q?q1aI7x4h4cH8VmP5z8qfkC1kFgDA9wmPeDp7eHgQPCDu+/1wq2eLFSQ6h5mM?= =?us-ascii?Q?AKwC6CGMuz+MWssHYskc7arekxvNGlJUZgwfZLyv0EDQ0w/UL5gf9AjSoMw7?= =?us-ascii?Q?N/veduaOJp+tPYBAgE49LHFeZ8LfBpQa031QR3D5Iv5N6yJZF/ISV+iZME2t?= =?us-ascii?Q?8QNwuXMkKpCT0rhv8W9NSbah?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR05MB357689A750C9BFC19E2FC7AAD52B9CY4PR05MB3576namp_"
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: c6ad17d1-5269-4472-f7bf-08d91ab2bc75
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 10:42:01.7114 (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: Hyo7olB+qIdeci8wDWx2rH0KtehvaSgJiyEH/RaqgEWgNgpD02+FGR/oOTf8Vf+jUvEUkmDGVy7EfPQEXS4MfQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3144
X-Proofpoint-ORIG-GUID: gxQ3-Y_r8ICGZnuv40Rj82J0vQOPDK2z
X-Proofpoint-GUID: gxQ3-Y_r8ICGZnuv40Rj82J0vQOPDK2z
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_04:2021-05-19, 2021-05-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 impostorscore=0 phishscore=0 mlxlogscore=999 clxscore=1015 spamscore=0 suspectscore=0 mlxscore=0 adultscore=0 bulkscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105190072
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/DuWtsTlDziPv5vNEfhSY57NMShc>
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: Wed, 19 May 2021 10:42:16 -0000

>[Jie] I can understand how this works for a single Flex-Algo, while my question was if more than one Flex-Algo use
>bandwidth as constraint to exclude some links, what would be the consequence to the network?

Operators design and plan whether one flex-algo is suitable for their network or multiple. The planning also involves
the definition of each flex-algo that is suitable for their network. This network planning exercise has to be done
irrespective of whether bandwidth constraints are used in the flex-algo to ensure traffic distribution is even.

Rgds
Shraddha





Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong@huawei.com>
Sent: Wednesday, May 19, 2021 12:59 PM
To: Shraddha Hegde <shraddha@juniper.net>et>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>rg>; lsr@ietf.org
Cc: 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 Shraddha,

Thanks for your reply. Please see further inline:

From: Shraddha Hegde [mailto:shraddha@juniper.net]
Sent: Tuesday, May 18, 2021 1:18 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>
Cc: draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto: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

Hi Jimmy,

Thanks for the review and comments.Pls see inline



Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Sent: Tuesday, May 18, 2021 7:58 AM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>
Cc: draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto: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]

Thanks to Peter for his response to my third comment.

Could the authors also reply to the other comments (1, 2, 4) in the below mail? Many thanks.

Best regards,
Jie

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Dongjie (Jimmy)
Sent: Friday, May 14, 2021 3:52 PM
To: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>
Cc: draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto: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

Hi authors,

I've read the latest version of this document and have the following comments:


1.       Is the generic metric type applicable to applications other than Flex-Algo? If so, it is better to make this clear in the document, or perhaps it may be defined separately from the Flex-Algo specific extensions?
<Shraddha>Yes. Any application can make use of generic metric including Flex-algo and SR-TE.
                      Sure. I'll add some text to clarify this.

[Jie] OK, thanks.



2.       The "Exclude Minimum Bandwidth" constraint is compared with the maximum link bandwidth to exclude the links from the computation, it would be helpful if there is some analysis about how much this can help in traffic engineering, such as to reduce the congestion or improve the link utilization. One simple example is, if multiple Flex-Algos use this constraint to exclude the same set of links, this may increase the possibility of congestion on the rest of the links?
<Shraddha> The motivation for "Exclude Minimum Bandwidth" is to avoid low capacity links for the high bandwidth traffic. For example if the Flex-algo 128 carries high bw traffic flows of bw greater than 10g, it makes sense to remove 1g links from this flex-algo topology since these links if happen to carry traffic, it  will get congested and traffic will be dropped. The introduction section talks about this motivation.

[Jie] I can understand how this works for a single Flex-Algo, while my question was if more than one Flex-Algo use bandwidth as constraint to exclude some links, what would be the consequence to the network?





Perhaps a more general question is, what would be the benefit of introducing bandwidth attribute into Flex-Algo based distributed path computation?  It is known that bandwidth can be used in centralized computation for efficient path placement and resource management, can distributed computation with bandwidth constraint achieve the same, or is there some advantages compared with centralized computation?

<shraddha> Many network operators assign link metric relative to bandwidth of the link and it is an existing practice. The draft is defining new attributes and constraints in order to simplify and automate this process.

It does not propose any bandwidth reservation/ bandwidth management solutions that a centralized computation or distributed RSVP based solutions provide.



[Jie] OK it is clear that this mechanism will not replace the centralized bandwidth computation or distributed bandwidth reservation solutions.  While if the purpose is just to simplify and automate the metric configuration process, , it seems the gain is relatively limited?





3.       With the automatic metric calculation, it could introduce per Flex-Algo link metric value, while the existing Flex-Algo only refers to the metric of the link via metric type. Is this the expected behavior? Will it be further extended to make other link attributes flex-algo specific?



4.       In the reference bandwidth method, the draft says it simplifies the management in case the reference bandwidth needs to be changed. Since the reference bandwidth applies to the metric calculation of all the links in the flex-algo with the same proportion, it seems the change of the reference bandwidth will not impact the result of the path computation in the flex-algo. In which case the reference bandwidth need to be changed?
<Shraddha> Lets take a hypothetical example. Lets say a network starts with all 1G links and 10G reference bw.
Over the years, many links get upgraded to 10G links and some get upgraded to 100G links. Using a 10G reference bandwidth will not be feasible and reference bw need to get increased to a value > 100G.

[Jie] Yes this is a valid case of changing the reference bandwidth, although it happens in a relative large time scale.

Best regards,
Jie

From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Thursday, May 13, 2021 5:09 AM
To: lsr@ietf.org<mailto:lsr@ietf.org>
Cc: draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>
Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

Esteemed Members of the LSR WG,

This begins a 2 week WG adoption call for the following draft:

     https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QjpfqmfDtSmB967Xe4sgDxr_V5e5fKU85mRhXYGofuadzmAhYjkW1d3yMUntZ2nT$>

Please indicate your support or objection by May 27th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft.

Thanks,
Chris and Acee