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

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Mon, 31 May 2021 07:44 UTC

Return-Path: <ketant@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 127503A0815; Mon, 31 May 2021 00:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.495
X-Spam-Level:
X-Spam-Status: No, score=-9.495 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_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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eOSA9CJr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OxYbsEdF
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 cea9NwivPbdo; Mon, 31 May 2021 00:44:14 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1393A07FA; Mon, 31 May 2021 00:44:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57912; q=dns/txt; s=iport; t=1622447054; x=1623656654; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aCQJigVPyYxDcP/TwZuxihLJVQQjoS1IBDUx2C418yE=; b=eOSA9CJr36oXpkv7ZnhkQTpFMw/qj2QeytEMYn6wRlB47cKOtDbE0r7F CeVCGEVSF6Ig9MMdynt+cj50RyTmD0V966wchtIinK6w+n6kse420bYIX +bzH1mNpVL9hZvncHZOJPh/Vk9LdPf3gGuBwNSHsSFZKhh4YRRE/YA9VL 0=;
IronPort-PHdr: =?us-ascii?q?A9a23=3AOx6upBbRQO/RbpF0rsjgjUb/LTDPhN3EVzX9o?= =?us-ascii?q?rIllrRPaqm5uZLvIB+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANM?= =?us-ascii?q?n1NicgfkwE6RsLQD0r9Ia3ocio7BMlYEllo4yLzPU1cAs2rYVrUrzW75iITH?= =?us-ascii?q?ROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhRCg=3D?=
IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AAQ4YBaELgAtG8Mk0pLqFPpHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk/NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsW?= =?us-ascii?q?rCpeO85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bU?= =?us-ascii?q?UzSGqF16NohqAP7EpGsljpxKZ/HFfOmj/w6MPPUAwvnk2ooWA6mepWlHBHV5?= =?us-ascii?q?ACAYUh4bD30XklWqvoJhiKpbzP0dMeRf0078wmPm9yr0qp9VWH5ebcEEjbMi?= =?us-ascii?q?32NXTqi/blmwS+xkoJu3fw7PZv6Evo2qhNPqV52w=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAACrkrRg/49dJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAgUMEAQEBAQELAYEiMCkoB3cOTDc?= =?us-ascii?q?xAwiGHIFpA4RZYIhqA4pEj0iBLhSBEQNUCwEBAQ0BATAPAgQBAYRQAoF+AiU?= =?us-ascii?q?0CQ4CBAEBARIBAQUBAQECAQYEcROFaA2GRAEBAQEDEggTEwEBJQcLAQ8CAQg?= =?us-ascii?q?RBAEBIQECBAchERQJCAIEAQ0FCBqCUIF+VwMvAQ6cIQGBOgKKH3iBNIEBggc?= =?us-ascii?q?BAQYEBIFIQYMJDQuCMQMGgToBgnqEDIEZgVCDeiccgUlEgRQBQ4IwLz6BT1F?= =?us-ascii?q?CAQECAYEoAQsHASMMGAcJgxeCLoFYbAgeRAEDLxQOAiItASsKRw0qATY6kFw?= =?us-ascii?q?iNosTjRiRIVsKgxmKDo4HhW0Rg16LG5N+gmGGXo5pjBWDJI91D4RlAgQCBAU?= =?us-ascii?q?CDgEBBoFUO2lwcBU7gmlQFwIOjX0iN20BCIJDg0aBToVKcwIBATQCBgoBAQM?= =?us-ascii?q?JfIgXgTYBgRABAQ?=
X-IronPort-AV: E=Sophos;i="5.83,236,1616457600"; d="scan'208,217";a="873932668"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 May 2021 07:44:12 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 14V7iCRv024374 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 May 2021 07:44:12 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 31 May 2021 02:44:12 -0500
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 31 May 2021 02:44:11 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 31 May 2021 02:44:11 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GCc5gvPsXDBYZ/+rHk/Zindk+mbEmxnZ2bno1NaO4ijS4AUhbSA8srtbqO2LoRPYVFsnvXKIk4tNULiK7aVkBY84IUiP4Q7LFFtntYyioVLsidTpxctUKOSf/bBuncL9rb8deCThExzGdsklHwGAXpChO9HeRZ6HJ0y98fEGGrB1QdlMAWD+Bjl5w432+IXIdMdnaq75eJpqO3Um1juUrJBOyeSttmkjDCvJMT+8O4ZcIX7kx3OvjXHOylBxx6lSMvhWymqr0UJFa+C1imkHlrp2vwr6g/2cyTujCorAG3blH6tsS2fbghaeitR77qHublfg2l7c+AcPm4+0cc9+Dg==
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=kd8WgNT9/Qm1qqoZTcirYxOD3YHTMAZipMvzqJpQekE=; b=KZmRn4FYsTBM1Jn7+hA2NQCi/4oD4qh/DWQ3agZOtuPzy7JREPM9eG8vK0A0loduzs3ANT70g2VTIgzsA+yuTDFuo270hPsKPaQtjWWrCvjKl0OphqlLb+1+Q+4gmEnZ04QmCEs8O9sld2gdvJRZVMjoPvfRqnWipq2o00QmmBrsqqMibLvV+aOUB8TS6IVyL5qoPthTAfXP/eKNvkcLfNhkkn6HM8gNCBi1gCiFiaJyYNTfpN53XFijTjWzzOXyGyymv9BRq6M4Tk6E/rwioso9NoviRr4DcoCueehBC021D0Ogd8KJm0g/MYNH3yjj1ioLJcAYJbYaTur7jvClkg==
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=kd8WgNT9/Qm1qqoZTcirYxOD3YHTMAZipMvzqJpQekE=; b=OxYbsEdFzObECLSmNflc7/IURFIvU65q20w6qMexYOjdCAA6sussCOb/gszl3YoNi1jL+EwrYMRRdGaHPJ5hVRiHVwtGrEJO9RM1I83yv3OMF1/YF2mu5Qr6MVpfh/OpdkXb6/hU2utZAzbCQT9Oh1yQR/quEOr/1Mge3k4dqYs=
Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by MWHPR11MB2015.namprd11.prod.outlook.com (2603:10b6:300:28::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.27; Mon, 31 May 2021 07:44:09 +0000
Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::ec42:2e34:fc81:d45f]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::ec42:2e34:fc81:d45f%5]) with mapi id 15.20.4173.030; Mon, 31 May 2021 07:44:09 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, Tony Li <tony.li@tony.li>
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+LIIACB5WwgAAKE+CABaABsIAAQOhg
Date: Mon, 31 May 2021 07:44:09 +0000
Message-ID: <MW3PR11MB4570FC4EFA6A729C0C0314FEC13F9@MW3PR11MB4570.namprd11.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> <CY4PR05MB3576847D1EFC6CFC29981879D5239@CY4PR05MB3576.namprd05.prod.outlook.com> <SA0PR11MB4576A85DEDC7823E9E32FB4CC1239@SA0PR11MB4576.namprd11.prod.outlook.com> <CY4PR05MB3576B4BC21D91F5EBEC46735D53F9@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB3576B4BC21D91F5EBEC46735D53F9@CY4PR05MB3576.namprd05.prod.outlook.com>
Accept-Language: en-GB, 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-05-31T03:42:50Z; 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=f511df7d-8db3-4ccd-8456-82670d9c0747; 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: [72.163.220.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0a901fc0-4e15-4cea-0509-08d92407e047
x-ms-traffictypediagnostic: MWHPR11MB2015:
x-microsoft-antispam-prvs: <MWHPR11MB2015F7F4D9CFD50DA9781A1BC13F9@MWHPR11MB2015.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: 0gOf845NPhOgvAZgQ2ESQFekaxWiaHvvzaWhdkaYxywGfglcojg45bqw+076p8GjZjobgp/DxnNj8I5bzbWJ6JR2UcKP6Ty7fYaxiOdTHHGIe+Z2ciJh6PTvzj5XoIJDWKeGOOyNF6PR2J+LOKYt1sepDrlmBH2rkd6qFlpOHcrW6wNtnriZ0Iz56M9wSGq4929THwIdOTho0eoDmGjeYDGs8DKco7RFHYGM90KBXlgIV1TNrdcNy6eppZ4NtqgUyc4MSX9WQztZFzmxv/TAHNasdUuYMUwJE3CH3oC8/WueqUI4p/tfPuCCezaOkPnk4yAhAEuNlIfrJeSeZUsDP8B5c7yMx+zbcp/yBZ2cgXrikXHolKXrRWPU21PQPOnYYP0QCRXJuefYTD+tRP+XII5g0qJb55GUyZcdshaQdriAhhpvoY1e/qIIqJPylSMBuNBunmSLYjk/FqsR3FOa97OOYXaRHtbVz9rPu2EvQ7WOuP1GrYy7ECZEcJuAJTu4uqMG2Vo2DGK3ObXvq4fHu1Ldc7N3u4+Q57wJ4Lq+Mrq0P+LzdMRwA0ZzQc4jkR3/GLoHS8xZbASTCEeFdvZAO+uVfM959LF9BLnNen5uZoKmS0G5oC6bgcC/pDBDtcDqciWjeYY1chHIAdHcRJfJ3vwVz4oviv6eGxxDylCDAin9dUW8KjEjeGIdwlG4zU1Ag6HiYN4Jwq7QKXV1MIxR3dTuGmg0emJIjkrum1zBMmPpXZrPfKbLfflIBCTSUeKV
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(366004)(396003)(346002)(39860400002)(376002)(64756008)(5660300002)(53546011)(166002)(9686003)(186003)(2906002)(76116006)(66446008)(6506007)(9326002)(478600001)(7696005)(66556008)(55016002)(4326008)(66946007)(122000001)(83380400001)(52536014)(86362001)(8936002)(316002)(8676002)(71200400001)(54906003)(66476007)(33656002)(30864003)(38100700002)(110136005)(26005)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?M03YBhZj4BoeZ8SDsxWQ7YNSFTZR/Ef7kXwssxuAWqmu87ffy/by8I/rXyO0?= =?us-ascii?Q?AbhcyRSfHO8Nfs+PWTWvMddtYcDVzv+QOEYMCttRvGI+VtVRFA2iYAO8hK5m?= =?us-ascii?Q?MMzwah8ndO50PgwKRFGQ5qtlEsNTw4la4W85Hj03hN5MamF4sOdEaimETRrs?= =?us-ascii?Q?ZK9Wm0e7eu8JSgdzjXkcpUnvXzx6so3lBrtP1RVbZH7aYcaTfnKu7wDjd87X?= =?us-ascii?Q?BZTIRGkvMvG1rDRb8H7XMvYLrSh4X8RPAhuO8avGSqfgKKTduT9dAtNEs+bA?= =?us-ascii?Q?YrSP2QLOVhAynkeikn5ArvcM+7AlIQFTXHUGpxEl9EWJj7BcTwPSn1l7UBn0?= =?us-ascii?Q?n2ikR0K4kxrI6Au98Iz8kVy4OrTJZogjNVTJTUpUfx+9eRYJLU0cHYLGYZnF?= =?us-ascii?Q?cdyiFCP5DkakJhrqQ8WwQVUjGhNdnYDcK2d1D0bLPpmmKqhXiJecHxvw26/m?= =?us-ascii?Q?7u7njJP4EZnHLvrYQXuTLvVbHGlAtjPB5S8aDDWINKPn7z/qpyrr/xz9n9PL?= =?us-ascii?Q?pD8hsQLnGId2tcc3Af/07eurYtWsxkGkrrLswEH0Ejn1h4ZPxZWMY2pvwuiG?= =?us-ascii?Q?u6QxekYSK93IEMnROKrv36gQGgFJ7Mek61s0KmbiuKWFEPwFLhCHvUEE6cvj?= =?us-ascii?Q?dxseuoJrgLpWCWvex1Nd4VIaEUWGoFKrRzGyQs++DHDEIAwsti5bAOcYa+Q9?= =?us-ascii?Q?CLY+0erjMCm4UIxzZaKg8n8qQ9ijE+q0KWAWCgmWiFnDbze9S5twyBUaWu4w?= =?us-ascii?Q?VufnMnUTDkVrn8MDWXEK/4xlGO6jAAXexXdJ5G2OVGYuJFN9ng0dTfkaz22w?= =?us-ascii?Q?IUGEkbas9FlUaQzjEr2k8h/KUIRgWiR9urTkhGRLS7UxLJZXT0D8PGhsHY1o?= =?us-ascii?Q?IaZYGZE+dXroOLGlk5IoFf8RGq1ql/1dDwjZxePXSW4e1p9ZI8YbRj5spSn+?= =?us-ascii?Q?bykbcTO3MikIQahf+qGQAsD3W68J7JHnkUV1KiweFmd3eGD/syDN5VibHD5o?= =?us-ascii?Q?UWjmJjL7AHUbpTNrdPsEhTb6yjdwqW73ZAx2Ls0ZSU3Ur0wKFEVRgjLzELzO?= =?us-ascii?Q?YMgMDLwdAsEB6DQzFKYDtFzRwVukEVlNJGu9SHpHFIg96ECIDD991AuFTlIO?= =?us-ascii?Q?f1Df6ZHOa+2+IC5HKOCxN0VBoHnJ/7b4ABby2BhjvELO5Wkkp+xOTdj+R9Fm?= =?us-ascii?Q?6OFuz9KplaBPDJskBU7BDdFfXtsVLZES6MU6K6RzZEF9+jxTBqoIfbZ9d0dz?= =?us-ascii?Q?95ocJoev/upjTBTZRbmjRUwM+0vcGDnC8oTCGEv9hd23mjXeQbDGLO45wkbg?= =?us-ascii?Q?1Mo=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570FC4EFA6A729C0C0314FEC13F9MW3PR11MB4570namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a901fc0-4e15-4cea-0509-08d92407e047
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2021 07:44:09.4552 (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: LPoKtG/Vezv3ra9KfpZeWqscSWrXhb7NkVfvR6WM6QmU4xk5FhHjNZEhOe8HIXCYoat2Vn0mbtEdQIRoxPcbdQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB2015
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ZzDpBjbntXf6K4CNOEm61L5IIo0>
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: Mon, 31 May 2021 07:44:20 -0000

Hi Shraddha,

When you refer to "a single TE application", it is not clear which one you are referring to : RSVP-TE or SR Policy?

I believe, for ISIS, you are referring to this specific section of RFC8919 : https://datatracker.ietf.org/doc/html/rfc8919#section-6.1

There is no ambiguity here. This section is about use of "legacy" advertisement. The Generic Metric is a new TLV and hence cannot be considered as "legacy" by any interpretation of the word.

Coming to OSPF, the considerations are similar. Additionally we also have to deal with different LSA types here.

Please refer to https://datatracker.ietf.org/doc/html/rfc8920#section-12.1 for the equivalent discussion for OSPF. This section is about "legacy" advertisements being in (RSVP) TE Opaque LSAs. If the TE application that you were referring to was RSVP-TE, then there is also additional guidance provided here : https://datatracker.ietf.org/doc/html/rfc8920#section-12.2.4

Please clarify where RFC8920 describes advertisement of application-specific attributes in say OSPFv2 Extended Link LSA other than within the ASLA sub-TLV.

Thanks,
Ketan

From: Shraddha Hegde <shraddha@juniper.net>
Sent: 31 May 2021 09:13
To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; Tony Li <tony.li@tony.li>
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

Ketan,


Networks that deploy a single TE application and already advertising and using attributes from top level TLVs
Will benefit from new attributes also coming in the same top level TLVs. There is no confusion and ambiguity
from a network operators perspective and IMO this must be allowed in the protocol.

If the attribute gets advertised in both ASLA and top level TLV, how the receiver should process it, has been
described in RFC 8919 and 8920 and this draft will refer to the same procedures.
If you think there is ambiguity in RFC 8919 and RFC 8920, pls provide specific cases that are ambiguous.

Rgds
Shraddha



Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Thursday, May 27, 2021 7:13 PM
To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; 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]

Hi Shraddha,

This is a new attribute that we are introducing and we are saying that it has application specific semantics. We now have the ASLA mechanics defined in both OSPF and ISIS. So why should it not use just the ASLA encoding?

Allowing its advertisement in the existing top-level TLVs in addition to ASLA introduces ambiguity for which applications can use it - we get into complications that are entirely avoidable.

Thanks,
Ketan

From: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Sent: 27 May 2021 18:36
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>; Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; 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

Snipped..


  1.  Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic - we will need precedence rules and such. I prefer we avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA (quite correctly) for FlexAlgo application. Peter has confirmed the same. I am simply asking to avoid the complications of using Generic Metric in both ASLA and outside it. Whatever new "application" we invent to use this generic metric type, can use ASLA so that the Generic Metric can be very cleanly shared between applications. The encoding allows for using the same value - sharing single advertisement across applications or doing a different one per-application.
<Shraddha> Generic metric is allowed in ASLA, it is also allowed in all traditional TLVs/LSAs where link attributes are advertised.
This is required so that all the applications, existing and new can make use of generic metric.



Juniper Business Use Only
From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Wednesday, May 26, 2021 12:09 PM
To: Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; 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]

Hi Tony,

Please check inline below.

From: Tony Li <tony1athome@gmail.com<mailto:tony1athome@gmail.com>> On Behalf Of Tony Li
Sent: 25 May 2021 00:15
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:acee=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; 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 Ketan,

In general, I support the adoption of this document. There is, however, one specific point which is not clear to me (8) below that I would appreciate some clarity on before adoption.


As the chairs have noted, adoption is binary and not contingent upon rough consensus on the content, just on rough consensus on the interest.
[KT] I believe the WG has (or must have) the ability to determine portions of the proposal to adopt and/or to split documents. I have seen this in recent past in other WGs. In any case, it is not a point that I wish to argue or debate on - especially in the context of this document. My point (8) was clarified and hence I fall in the binary YES in this instance.


  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.

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


  1.
  2.  Would be good to cover the max-metric considerations for the Generic Metric. Similar to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15*section-15.3__;Iw!!NEt6yMaO-gk!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKigDlnfK$>


Fair



  1.
  2.  Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic - we will need precedence rules and such. I prefer we avoid this complication.


We preferred avoiding ASLA.
[KT] The text today does not avoid ASLA and in fact requires the use of ASLA (quite correctly) for FlexAlgo application. Peter has confirmed the same. I am simply asking to avoid the complications of using Generic Metric in both ASLA and outside it. Whatever new "application" we invent to use this generic metric type, can use ASLA so that the Generic Metric can be very cleanly shared between applications. The encoding allows for using the same value - sharing single advertisement across applications or doing a different one per-application.

  1.
  2.  For the newly proposed FAD b/w constraints, I would suggest the following names for the constraint sub-TLVs where the b/w value signalled by all is compared with the Max Link B/w attribute. This is just to make the meaning, at least IMHO, more clear.

     *   Exclude Higher Bandwidth Links
     *   Exclude Lower Bandwidth Links
     *   Include-Only Higher Bandwidth Links
     *   Include-Only Lower Bandwidth Links

  1.  Similar naming for the FAD delay constraints as well would help. Though I can only think of the use of "exclude" for links above a certain delay threshold to be more practical but perhaps others might eventually be required as well?


Thank you for the suggestions.



  1.
  2.  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!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$>j$>, 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!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKrdBaWXz$>?


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!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKn7h1XsO$>


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!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKiuV4Gz8$>] 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!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKlvO8Grj$>


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!SDczOqpejUmhJOhxekn9upuxrXWvzAysd0z2Nitrtt8rtdmdHY_KVQLsKgE3htSJ$>]$>].  Because it is an application-

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

Somewhat similar for ISIS as well.

  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?


  1.
  2.  The document introduces a new Generic Metric type called Bandwidth metric. I've been trying to follow some of the discussion related to this on the mailing list - about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is - but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft.


I'm sorry if this has been confusing. My understanding is that the metric is cumulative. Others had other expectations.
[KT] Thanks for this important clarification.

Thanks,
Ketan

When there are multiple links with the same bandwidth, and thus the same metric, then the total path metric becomes (link metric) * (number of links).

Regards,
Tony