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

"Acee Lindem (acee)" <acee@cisco.com> Mon, 24 May 2021 11:09 UTC

Return-Path: <acee@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 D944D3A2429; Mon, 24 May 2021 04:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.896
X-Spam-Level:
X-Spam-Status: No, score=-11.896 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, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qdsigh4U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=depZcLXi
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 BmMjNi7xc8s0; Mon, 24 May 2021 04:09:48 -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 8CCFB3A2423; Mon, 24 May 2021 04:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21644; q=dns/txt; s=iport; t=1621854588; x=1623064188; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1d9g0FZBXFC4DXVCzfcftgxkjh8v669nesobYz+rick=; b=Qdsigh4UJvf6QKaXNLj9zjfry85EuzMCvGJUdOqG37DrIFvwEwzXANQL AZaLb/qpNkKx97ziNEOYf6946IGhGMH0Nwz3fZYgs10dQwgONvmsvfOUC I6hdsXk9qJ8viZHUojh4rpbRaeHsknwBa84lnnK1EDs1XUljsVVLzWMkP A=;
X-IPAS-Result: =?us-ascii?q?A0A8AADSiKtgl5BdJa1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFXgVNRflo2MQuEPYNIA4U5iGwDij+PQIFCgREDVAsBAQENA?= =?us-ascii?q?QEqDQgCBAEBhAxEAheBZwIlOBMCBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUA?= =?us-ascii?q?QEBAQEBAQFohWgNhkQBAQEDAQEBEAsGBA0MAQEsCwEECwIBBgIOAwMBAQEBA?= =?us-ascii?q?gIfBwICAh8GCxUICAIEDgUbB4JPAYJVAw4hAQ6MRI80AYE6Aoofen8zgQGCB?= =?us-ascii?q?wEBBgQEgUhBgyMNC4ITAwaBECoBgnqEDoEThUgnHIINgRUnHIIwLz6BT1BCA?= =?us-ascii?q?QECAReBEQERAgEgFyOCXTaCLYFZPjMHXQQNRAIgDyEIAz0sGSUGKQUPL5B7g?= =?us-ascii?q?ncBQqY8WwqDF4oKjgSFTgUkg1uLGZZYhliNVwyNEoMklGUCBAIEBQIOAQEGg?= =?us-ascii?q?Wsia3BwFTsqAYI+UBcCDocfhwAZHoM5g0aBEzuFSnMCNgIGAQkBAQMJfIdhA?= =?us-ascii?q?YEQAQE?=
IronPort-PHdr: A9a23:/lK1ChcPV5eXmxLmOolNJItdlGM/rYqcDmcuAtIPgLJJary4uZP4M x+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANMn1NicgfkwE6RsLQD0r9Ia3hbysiB N8EU0VqrDm3NEFPE5P4YFvf6nS58T8VHED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaE Q==
IronPort-Data: A9a23:oPn7iaCVq4vPcBVW/xHjw5YqxClBgxIJ4kV8jS/XYbTApG52hDUGz zYbCmmGM/fYajb0etsgbo7ioxgP78LSx4AyOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /3z6bAsFehsJpPmjk/F3oPJ8D8sj8lkepKmULSdYn0rGVc9IMscoUsLd9AR09YAbeeRW2thi fuqyyEIEAb4s9LcGjt8B5Or8HuDjtyr0N8rlgBWicRwgbPrvyJ94KTzik2GByCQroF8RoZWT gtYpV2z1juxExwFUrtJnltnG6EHaua6AOSAtpZZc6z8rzFHrzIg7p8iBdM/eR0M1wTKv88kn b2htbToIesoFrfHlOJYWB5CHmQue6ZH47TAZ3O4tKR/zWWfLCCqmKooXRpwZNFEkgp0KTkmG fgwITsAYziIhvm9x/SwTewEasELc5OwbNlF5iwwpd3fJfF9R7ydcorx39pF3zgg2ssRF9fBe NVMPFKDazyZM0EQZT/7EqkWmPyyrnjybzMer0iazYIs43LawABx2ZDvLdzUYtGQA8NYgi6wq njP8Xi8AhwVONHazSGft3yoi/+KlCf0X8cYC/iz8fhCgVCPyCoUEhJ+fUO2p/b/kU63XNxCA 14I92wlqq10/0rDZtbnUhK5pX+epR0Nc9VVGuw+rgqKz8L8/wGfFy4ATxZdb9o38ss3LRQh1 liRh8jBDjxoqKWOD3WH+d+pQSiaIyMZKyoJYjUJCFtD6Nj4q4Z1hRXKJjp+LEKrptmrNBj1y i6YkBEntpwwnZRQi5T43U+S1lpAuaP1oh4JChT/Bzz/t14pOtb6O+RE+nCAt6ccc93xok2p+ SlaxJDEvIjiGLnUzHTVKNjhCo1F8Bps3Nf0u19kH5A7+y+q/RZPlqgPvWkufS+F3iv4EAIFj WfJsg9XoZRUJnbvPcebgr5d6ex3lsAM9vy8C5g4i+aihLAqKGdrGwk1PyatM5jFyhRErE3GE c7znTyQ4ZMm5UJPkmPeqwA1j+ZD+8zC7Tm7qW3Tlk7+iuPOOBZ5t59YYAPmgh8FAFOs+VWJr Ik32zqi4BREW+q2WTjM7YMWNjg3wYsTVM2o8ZcOHtNv1jFORTB6Y9eMkOxJRmCQt/kM/gs+1 irlChEwJZuWrSCvFDhmnVgzOeuzAs4n9SxT0O5FFQ/A5kXPqL2HtM83H6bbt5F+nAC/5ZaYl 8U4Rvg=
IronPort-HdrOrdr: A9a23:fhojCq6DGMjRuWAkQgPXwQuBI+orL9Y04lQ7vn2ZFiY1TiXIra 6TdaoguiMc0AxhJ03Jmbi7Sc69qeu1z+803WBjB8bdYOCAghrqEGgC1/qi/9SEIU3DH4FmpN xdmsRFebjN5B1B/LrHCWqDYpQdKbu8gdqVbI7lph8HJ2wHGsIQjTuRSDzrb3GeLzM2Y6bRYa Dsnvav0ADQAEj/AP7LYkUtbqzmnZnmhZjmaRkJC1oM8w+Vlw6l77b8Dlyxwgoeeykn+8ZmzU H11yjCoomzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8kuLCn2gArAXvUkZ1TChkFznAic0idyrD D+mWZ5Ay210QKLQoiBm2qq5+An6kd115at8y7EvZKpm72JeNtzMbswuWseSGqE16Ll1+sMjp 6iGAmixsVq5Fr77VbAD5KjbWAYqmOk5XUliuIdlHpZTM8Xb6JQt5UW+AdPHI4HBz+S0vFqLA BCNrCX2B9tSyLWU5kZhBgn/DWmZAV9Iv5HeDlIhiWx6UkZoJlU9Tpu+CUvpAZJyHtmcegx2w 3tCNUfqFhhdL5iUZ5A
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,319,1613433600"; d="scan'208";a="723822458"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2021 11:09:47 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 14OB9kFj009471 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 24 May 2021 11:09:47 GMT
Received: from xfe-aln-001.cisco.com (173.37.135.121) 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, 24 May 2021 06:08:47 -0500
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 24 May 2021 06:08:46 -0500
Received: from NAM11-DM6-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, 24 May 2021 06:08:46 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jmeZtmN9EVxzpF7XUJU7UfI9Zmkw4/xUFqspkyYXA0+vWS1CCJTwdThs6mjCdUvsn0KITJv/hqukzoIvBXmlBbDHv3HEquNdQjPjS5Q1l2I5jPp3ZgOCLO+OG8G/330yYpfVBBmT80HpebrQ2WfNm6io2UW85uMyF8qr8uyBEj+M9WMvoqUISD9ZtvPfMV0JmjdWWrG39uHsni8NxwxSkiZY/3+jrIYdN9xRr1P8mFbPD7OzqWTW5Zm3qeT6+JJTNLPNCqlWAp8YPDlKzdiR8OTDQZaKw1ddkRB5f49GMDe/NSq7lVPfI5FIXGCyfKsqC44Vb74lrkhb/7stOKmdxw==
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=1d9g0FZBXFC4DXVCzfcftgxkjh8v669nesobYz+rick=; b=GJkfg00GJTH8iAMExkmrg2KcFDNLYlHiI+qvgJIjh5ZMp5L7eSpSzfv6+08nrK3rclt2c6eGbzksJExIHXcYtO/R7j+IRZjmTeIUEsDKn3Etc/tWtjyRCQKsI7fLnQeR7VU30Sp0UrLFPYrzRhUjQJ/WL2yzTSXB9Ht6qclFAOUzlgb2Bn0LqTNdXCZ5sZ+2xeJtKlhczwRdKQhZD+7DKzL7ep4c8LncVXlL3fzG3kZ2aojw2eh541Het6OlisO1y9KprSg7jkgQtzoxqxXlAYY4FcHB7CpNGiT29VDUlLu66UGrp30n8LwK0NAYImYLZ2ey0xhZdP+rIIxWcGj91A==
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=1d9g0FZBXFC4DXVCzfcftgxkjh8v669nesobYz+rick=; b=depZcLXiJ4Uygo7lxN8uHKxV0c+tUokGv9R5gvQs2yAUISXD1QxozhWRaP8NsV7d5fwBx0fYK2aatAtQGbB4J1zjVX1kbsFgGQ8JpMQDSNLDgY9BYg6RiGw4HgxX6doDcwAiOIcfT+JEPaDdBvOJck8NINoEaahh2IQ92o8gagM=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by SJ0PR11MB5151.namprd11.prod.outlook.com (2603:10b6:a03:2ac::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.23; Mon, 24 May 2021 11:08:45 +0000
Received: from BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::e98f:cd3e:b6d:6f9d]) by BYAPR11MB2887.namprd11.prod.outlook.com ([fe80::e98f:cd3e:b6d:6f9d%7]) with mapi id 15.20.4150.027; Mon, 24 May 2021 11:08:44 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Christian Hopps <chopps@chopps.org>
CC: Tony Li <tony.li@tony.li>, Greg Mirsky <gregimirsky@gmail.com>, "peng.shaofu@zte.com.cn" <peng.shaofu@zte.com.cn>, "draft-hegde-lsr-flex-algo-bw-con@ietf.org" <draft-hegde-lsr-flex-algo-bw-con@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, "lsr@ietf.org" <lsr@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: AQHXTS8TsfWK+VBvbUypEXm2sCkCsKrxgzKAgAAOlAD///IXgIAAU0OAgABlwwA=
Date: Mon, 24 May 2021 11:08:43 +0000
Message-ID: <8414EAB5-BFA0-4A81-8F1F-BEE5BC9BC67C@cisco.com>
References: <202105200955495710804@zte.com.cn> <CY4PR05MB357659CAE530C61E253AC958D52A9@CY4PR05MB3576.namprd05.prod.outlook.com> <CA+RyBmVRqpSxxFoDKEtdv=zSu6gXbdyDFbpuM7ek93La1n5Hew@mail.gmail.com> <E63007E1-4C5E-479B-A4EE-7EADF93B058A@tony.li> <D363EE45-B866-43EE-B7AD-68B5D70E17E1@cisco.com> <m2eedx9bpy.fsf@ja.int.chopps.org>
In-Reply-To: <m2eedx9bpy.fsf@ja.int.chopps.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.49.21050901
authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [136.56.133.70]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cbcb9cf8-d90c-484a-d320-08d91ea44bd4
x-ms-traffictypediagnostic: SJ0PR11MB5151:
x-microsoft-antispam-prvs: <SJ0PR11MB5151202AEC342BD38C0A0A2AC2269@SJ0PR11MB5151.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: udnZRZprmjkXHjNEVGps1BCpE/OE7BvsSLvJkofToqst/sKMlhmBK7z2QFRacXEfAqlG/A+hLNGWtSG37PDltPRcyrGAoiRB5D0jwcEUok3L1QKaHIqWwKunNmP65DDEvyhj8GcnkhHQusV+NTXLUBbEx6+nGr4rCrhQ1sYI5FINJk8H1CdgzhejdT+g1syFfLD3NPVniJQEi9D6m8fXrwhi2fMDZ7ZJ7tlAa0E6U2Owa/rFf4JYrXigs2ZRajy6Awty0SHriJ5hreSGndjysYgMY2BVIvd4Bhb1xSI4unQE881VPIXIFZMrK/MOsfvcwXciwXl6tVLzcI+sxAM6Yx2DdW7ymj6YfRxSstkRaTCjtt+bdAZ1G0lLgi195+xBFgnuQZL8bJNNdhiYuR18gMRQ8qPw9DuMSEUJEfZcDgFcSyrKLt4HOHk99HTlfrGxruMsCnjOXObcpHjh2qOB4KtNofaZ+SgdKp7l31LzSgi2fZyStS1QpRhHjiHhDLoUG1VYTPzYlcCBjZmAhjT7/NrSI146KhakkDPvhJ6D0PVzYF2in8qXiHnL6BxI7DCWlr6/LMBWtrXtdHqVxSzAuzcsvItAeV7AqthUM/Vw5vL8FsSpiX1q0FPAUWI/aK0cuiORn/3QzyA5z9uimWynbLtukG+CUR6LNfjr4Sn0U0yBVkNvXLbhYQpRw8Ntx8wpZ5hLqLtdr7a6x13Oo4g0poJDIWrhjiv77MocfPU8G2bEk4Nm6IjeMmpGOXrB6/3J+h3PJxzH9Zy1jWd1tRRj8A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2887.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(346002)(396003)(39860400002)(54906003)(86362001)(66446008)(76116006)(478600001)(64756008)(4326008)(5660300002)(2616005)(8936002)(316002)(66556008)(66946007)(2906002)(66476007)(6512007)(6506007)(26005)(30864003)(71200400001)(6486002)(122000001)(83380400001)(36756003)(8676002)(966005)(186003)(53546011)(38100700002)(6916009)(33656002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?MVA1a0NOZG0zZVh0Y1NjT2FGR3Y1cW41cVFXdTgyQ2VCVDNBSkRaQWVEZU1J?= =?utf-8?B?TWZRMnRybXM2cm9PZTlRS1I3b211MWtoMHIySk0relB5TDBvSUlFWWFhaTFW?= =?utf-8?B?T3Y2SzFtRzBsQ2x5WWdWS3BVQ0QwMmlkSnRZRVNSeTlXclltR0hsamlTQVZo?= =?utf-8?B?ek9FN0tUSVhROFBlVW5pYTFzdHhPMUdTY1dkaUVSbE9HUjdyK0RJSC9GdDJr?= =?utf-8?B?SE5SSUl1Q0VUOGdOd2ltVTVEaTFkbXVlRXNWWWdreDhQQ0JqUGxrOGV5SlFr?= =?utf-8?B?TE4vc0pnRnpUdGJYTGRMNHViMjVjeVlsTnRLVGdwRytiTFl3UDlPL0FYRy9V?= =?utf-8?B?dXlLcmVZUU4zbkR6NmdmZjhqRUZ1QlF5OEJmK0ZvWDAvQ094bU1vTDBpMmNJ?= =?utf-8?B?K2RYbURWbktVRmRtajJ6NFM3ajFBUXIxS1hmQWZzNVNaYzBRVndYRWNHb2pG?= =?utf-8?B?cDVXMVl0RnJ0Umh3Q1MrLzRodHpyc3NpWDJPSzJrTDlpNjNrRFIrTnpNa2RY?= =?utf-8?B?SDhDY28weXFFVlJxdDZwQmJDWFhDZnlEbkhUREI5Y1hIZG93SkxDNnViaFNG?= =?utf-8?B?LzNjOEZlTkRkQlhrYnhhck1pYUQxamtpQ0VtSTVVVUtWWGlZRUpPTlB1QTVo?= =?utf-8?B?cU1GdXlWdGpnOWprdkRpcThQTGcvci9NL2pscEdEK0JxZ3pIQTNBVHMzdXFW?= =?utf-8?B?V3pwbVNaSnc5MllYb3RWQUdkeHlFWjBsc05pS1BXclBDSE5MbU0xVURxaWlN?= =?utf-8?B?WnZVby9pY041RnVlOHJDUnp1SGpwYkRaL2dxV3Bpb1dxdzRrWW5IeURhNjEx?= =?utf-8?B?YUFSYi9jZnNHa3hHWENwZ3pRZ1Jub0lxaVNQUnRnVVBFT3lqK2FVY3JiNk1T?= =?utf-8?B?elhNaEcvTVRYSEoweXUyQ2RsWUt1ZFVnTkU1YWs1VjBLanA5M1NQRDVHWk9R?= =?utf-8?B?YjllSVB5TDBZdXRscFBndW03LzJZaFh0QnFLMVhUcTd6dlh4VVkzMjErQnBE?= =?utf-8?B?RFlDL3lOYUMvY3Q1bW1PZStWR25jUVNpaHI5NC9sU2JlS1haSVFEbEgrTW5o?= =?utf-8?B?RCtiQkJaclFydWorZ1N5Um0zdjhwU2VZeDB0N25rUkFhWXN1cEtTOWVrNDlH?= =?utf-8?B?SUIwdUFEY2tkQ3V2UjNZc2hSUkttTVhKdkQralBmT2svTFpqdElrL2ZzSW5M?= =?utf-8?B?aTVQL0I3MG9wRWl3VDRsOTI4VGpaUXkrWGJjQi9LTUUvczFVYTNRVlJ2ZjRo?= =?utf-8?B?OEo1a2pQek5uM3B6cFhMMi9DYmRWMTZHdUpNQk5pdE9kODJ2VVl5UUkxMkJF?= =?utf-8?B?c1k2bnhlZFlhSytyd0JKcjNaeG9wTEl3R1NkdlhhRFh2c3VPeTJtc0RORXZv?= =?utf-8?B?YlVtREt6cStYc2gzT2ttTUw4cGJPQ2c4Z0cxOFJQT0FEMVNLUmNWMlg4QzZF?= =?utf-8?B?N1krRUlVYWp0MFpLbnJLUmhuQm5CUzl1c0tpTHJkM1JnMVV2QlY4UW82a0Zu?= =?utf-8?B?b1RNbkpBMXp5eStyeWVOVHJ6LzVWR2Y0WEVpZFA4dXlWTGZOSVhuK2l6WEtu?= =?utf-8?B?RGx2bUM4WWlXdWlCSjIvTU1mTDdVVDhXNmtJN2NoMFl6UldKS21xb3lwSW9x?= =?utf-8?B?aUpqQngxeWRwOVhmN3gySktTdy9VMytIdmFHRHoydVlHRUx5azFmazllRGJu?= =?utf-8?B?VXRXeVNhaGw2NjRNNHlnTDBPMmgvbFJUMVMzNEhmVFBQZTlqM0ZnOWs1bXc2?= =?utf-8?Q?sQuhWcV1sFdUOGUePjgrLbREc5evzL0oBWTdKNC?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <21051CB2C1CF2747A21F6E54247422C0@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2887.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cbcb9cf8-d90c-484a-d320-08d91ea44bd4
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 11:08:44.0957 (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: fYjD5yiGff2beVFpRZz2f+l1LVgtyI77OkQHBBagJeo/xvQb1lGl5SBEuE6rMfdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5151
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/qVa9cOUK4YRt223VJtJF0OKDM_4>
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, 24 May 2021 11:09:55 -0000


On 5/23/21, 9:12 PM, "Christian Hopps" <chopps@chopps.org> wrote:


    "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org> writes:

    > Hi Greg,
    >
    >
    >
    > Additionally, in a vacuum light will only travel 300 meters in a
    > microsecond. So, in a nanosecond, that is less than a foot. What
    > transmission technology and application do you anticipate that will
    > require this this precision?

    Off by a few magnitude; light travels just shy of 300,000,000 meters per second.

300,000,000 meters per second / 1,000,000 microseconds per second = 300 meters per microsecond 

So, I don't think this is wrong. Also there is the standard definition of light microsecond - https://www.convert-me.com/en/convert/length/lightmicrosecond.html?u=lightmicrosecond&v=1


Thanks
Acee

    Consider that 100Gbps links transmit 100 bits every nanosecond. So about 5 nanoseconds to send a minimum sized ethernet frame (sans the pre/postamble).

    Thanks,
    Chris.


    >
    >
    >
    > Thanks,
    >
    > Acee
    >
    >
    >
    > From: Tony Li <tony1athome@gmail.com> on behalf of Tony Li
    > <tony.li@tony.li>
    > Date: Sunday, May 23, 2021 at 4:56 PM
    > To: Greg Mirsky <gregimirsky@gmail.com>
    > Cc: Shraddha Hegde <shraddha@juniper.net>et>, "peng.shaofu@zte.com.cn"
    > <peng.shaofu@zte.com.cn>cn>, "lsr@ietf.org" <lsr@ietf.org>rg>,
    > "draft-hegde-lsr-flex-algo-bw-con@ietf.org"
    > <draft-hegde-lsr-flex-algo-bw-con@ietf.org>rg>, Acee Lindem
    > <acee@cisco.com>
    > Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
    > Bandwidth, Delay, Metrics and Constraints" -
    > draft-hegde-lsr-flex-algo-bw-con-02
    >
    >
    >
    >
    >
    > Hi Greg,
    >
    >
    >
    > That’s a very fair question and not one that has been discussed.
    >
    >
    >
    > Do we have that kind of accuracy from any of our measurement tools?
    > Is that even on the horizon?  I haven’t seen that…
    >
    >
    >
    > If it is time for nanosecond level measurement, then is it time to
    > shift to floating point to give us more range?
    >
    >
    >
    > Tony
    >
    >
    >
    >     On May 23, 2021, at 1:04 PM, Greg Mirsky <gregimirsky@gmail.com>
    >     wrote:
    >
    >
    >
    >     Hi Shraddha, Authors, et al.,
    >
    >     I apologize if my question has already been discussed. The unit
    >     for the maximum link delay in the draft is a microsecond. There
    >     is a group of services that require a highly accurate bounded
    >     delay. Have you considered using a nanosecond as the unit for the
    >     link delay?
    >
    >
    >
    >     Regards,
    >
    >     Greg
    >
    >
    >
    >     On Wed, May 19, 2021 at 9:17 PM Shraddha Hegde <shraddha=
    >     40juniper.net@dmarc.ietf.org> wrote:
    >
    >         Hi Pengshaofu,
    >
    >
    >
    >         Pls see inline..
    >
    >
    >
    >
    >
    >                           Juniper Business Use Only
    >
    >         From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
    >         Sent: Thursday, May 20, 2021 7:26 AM
    >         To: Shraddha Hegde <shraddha@juniper.net>
    >         Cc: acee=40cisco.com@dmarc.ietf.org; 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 Shraddha,
    >
    >
    >
    >         Thanks. Actually, I don't really want to define other metric
    >         types.
    >
    >         Let's go back to the bandwidth-metric related to bandwidth
    >         capability. My worry is that bandwidth-metric (whether it is
    >         automatically calculated or manually configured) is not
    >         cumulative in nature,
    >
    >         <Shraddha> Yes that is correct.
    >
    >         which is different from IGP default metric/TE metric/delay
    >         metric,
    >
    >
    >
    >         so that SPF based on bandwidth-metric may get an unexpected
    >         path (see the example of the original mail).
    >
    >         Can more text be added in the draft to describe why this can
    >         work ?
    >
    >         <Shraddha> Knowing that metric derived inversely from the
    >         link bandwidth is not additive in nature, should set the
    >         expectation right. I can add some text in this regard.
    >
    >
    >
    >         Regards,
    >
    >         PSF
    >
    >
    >
    >
    >
    >                                   原始邮件
    >
    >         发件人:ShraddhaHegde
    >
    >         收件人:彭少富10053815;
    >
    >         抄送人:acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org;
    >         draft-hegde-lsr-flex-algo-bw-con@ietf.org;
    >
    >         日期:2021年05月18日 13:01
    >
    >         主题:RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
    >         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
    >         draft-hegde-lsr-flex-algo-bw-con-02
    >
    >         Hi Pengshaofu,
    >
    >
    >
    >         If an operator wants to configure any other metric type draft
    >         provides a mechanism with generic metric.
    >
    >         Generic metric allows any standard or user-defined type
    >         metric to be configured.
    >
    >         The draft allows for any computing application such as
    >         Flex-algo, CSPF etc to make use of the
    >
    >         Metric. The intention of the draft is that for a particular
    >         computation same metric-type is used
    >
    >         throughout the network. If that is not clear, I’ll add some
    >         text in the draft.
    >
    >
    >
    >         Using a combination of different metrics for a single
    >         computation would need significant change to SPF algorithm
    >         and it is not in the scope of the draft "Flexible Algorithms:
    >         Bandwidth, Delay, Metrics and Constraints".
    >
    >
    >
    >         Hope that clarifies.
    >
    >
    >
    >         Rgds
    >
    >         Shraddha
    >
    >
    >
    >
    >
    >                           Juniper Business Use Only
    >
    >         From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
    >         Sent: Monday, May 17, 2021 12:49 PM
    >         To: Shraddha Hegde <shraddha@juniper.net>
    >         Cc: acee=40cisco.com@dmarc.ietf.org; 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 Shraddha,
    >
    >
    >
    >         The two methods of automatic generation of BW-metric
    >         introduced in the draft are also likely to be the method of
    >         manual configuration of BW-metric by operators. Operators
    >         can certainly manually configure any  BW-metric he wants to
    >         configure.
    >
    >         However, the manually configured BW-metric cannot deviate
    >         from the actual bandwidth capacity of the link, otherwise it
    >         could be any other names such as BX-metric.
    >
    >         For manual assignment, the problem may still exist We can
    >         find an example that  the accumulated bandwidth-metric on the
    >         path may offset the manually increased bandwidth-metric of
    >         links on the path.
    >
    >         Combination of bandwidth attribute of link and other metric
    >         that is cumulative may be another co-exist way to completely
    >         address this issue.
    >
    >
    >
    >         Regards,
    >
    >         PSF
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >                                   原始邮件
    >
    >         发件人:ShraddhaHegde
    >
    >         收件人:彭少富10053815;
    >
    >         抄送人:acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org;
    >         draft-hegde-lsr-flex-algo-bw-con@ietf.org;
    >
    >         日期:2021年05月17日 12:15
    >
    >         主题:RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
    >         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
    >         draft-hegde-lsr-flex-algo-bw-con-02
    >
    >         Hi Pengshaofu,
    >
    >
    >
    >         I was suggesting to manually assign bandwidth metric which
    >         will override the automatic metric calculation
    >
    >         as described in the draft section 5. Physically adding more
    >         fiber/capacity is not a feasible solution.
    >
    >
    >
    >         Rgds
    >
    >         Shraddha
    >
    >
    >
    >
    >
    >                           Juniper Business Use Only
    >
    >         From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
    >         Sent: Monday, May 17, 2021 7:40 AM
    >         To: Shraddha Hegde <shraddha@juniper.net>
    >         Cc: acee=40cisco.com@dmarc.ietf.org; 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 Shraddha,
    >
    >
    >
    >         Thanks for your rely.
    >
    >         So it seems that the scheme may lead to the selection of
    >         links with less bandwidth. To address this point, the method
    >         as you described to assign more bandwidth to high bandwidth
    >         links seems not always possible, e.g, adding more fiber ?
    >
    >         Can this point can be addressed by combination of bandwidth
    >         attribute of link and other metric that is cumulative ? IMO,
    >         bandwidth is not cumulative.
    >
    >
    >
    >         Regards
    >
    >         PSF
    >
    >
    >
    >                                   原始邮件
    >
    >         发件人:ShraddhaHegde
    >
    >         收件人:彭少富10053815;
    >
    >         抄送人:acee=40cisco.com@dmarc.ietf.org;lsr@ietf.org;
    >         draft-hegde-lsr-flex-algo-bw-con@ietf.org;
    >
    >         日期:2021年05月13日 21:01
    >
    >         主题:RE: Re:[Lsr] LSR WG Adoption Poll for "Flexible
    >         Algorithms: Bandwidth, Delay, Metrics and Constraints" -
    >         draft-hegde-lsr-flex-algo-bw-con-02
    >
    >         Hi Peng shaofu,
    >
    >
    >
    >         As per the draft, if automatic metric calculation with
    >         reference bandwidth method is used to calculate the metric
    >
    >         Then as per your example s->D path will be chosen since
    >         metric is 10.
    >
    >         Lets say operator wants to choose S->X1->X2-àX10->D path then
    >         operator can manually assign higher bandwidth
    >
    >         Metric on S->D link which will ensure S->D path is not the
    >         least cost path.
    >
    >
    >
    >         Rgds
    >
    >         Shraddha
    >
    >
    >
    >
    >
    >                           Juniper Business Use Only
    >
    >         From: peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
    >         Sent: Thursday, May 13, 2021 1:05 PM
    >         To: peng.shaofu@zte.com.cn
    >         Cc: acee=40cisco.com@dmarc.ietf.org; 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]
    >
    >
    >
    >
    >
    >         Sorry for spelling mistakens in the previous email.
    >
    >         updated text:
    >
    >
    >
    >
    >
    >         Hi WG,
    >
    >
    >
    >         I have a little doubt about the scheme described in this
    >         document.
    >
    >         See the following example:
    >
    >
    >
    >         S ---- X1 ----- X2 ---- ... ... ----- X10 ----- D
    >
    >             \----------------------------------------------/
    >
    >
    >
    >         Suppose the links in S---X1---X2...---D have the same
    >         bandwidth  10G, and the link S-D has bandwidth 1G.
    >
    >         Suppose that we select "reference bandwidth = 100G", then,
    >
    >         each link  in S---X1---X2...---D will have the same
    >         bandwidth-metric  10 (i.e., 100/10)
    >
    >         link S-D will have a bandwidth-metric 100 (i.e., 100/1)
    >
    >
    >
    >         So flex-algo path from S to D based on bandwidth-metric will
    >         be S-D, not S---X1---X2...---D, because the later has a large
    >         cumulative bandwitdh-metric (i.e., 11*10).
    >
    >         But our expect path should not be S-D, but
    >         S---X1---X2...---D, as it has large bandwidth.
    >
    >         Do I misunderstand anything ?
    >
    >
    >
    >         Regards,
    >
    >         PSF
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >         发件人:AceeLindem(acee)
    >
    >         收件人:lsr@ietf.org;
    >
    >         抄送人:draft-hegde-lsr-flex-algo-bw-con@ietf.org;
    >
    >         日期:2021年05月13日 05:49
    >
    >         主题:[Lsr] LSR WG Adoption Poll for "Flexible Algorithms:
    >         Bandwidth, Delay, Metrics and Constraints" -
    >         draft-hegde-lsr-flex-algo-bw-con-02
    >
    >         _______________________________________________
    >         Lsr mailing list
    >         Lsr@ietf.org
    >         https://www.ietf.org/mailman/listinfo/lsr
    >
    >         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/
    >
    >
    >
    >         Please indicate your support or objection by May 27^th, 2021.
    >
    >
    >
    >         Authors, please respond to the list indicating whether you
    >         are aware of any IPR that applies to this draft.
    >
    >
    >
    >         Thanks,
    >
    >         Chris and Acee
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >         _______________________________________________
    >         Lsr mailing list
    >         Lsr@ietf.org
    >         https://www.ietf.org/mailman/listinfo/lsr
    >
    >
    >
    >
    >
    > _______________________________________________
    > Lsr mailing list
    > Lsr@ietf.org
    > https://www.ietf.org/mailman/listinfo/lsr