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 16:39 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 816773A2E87; Mon, 24 May 2021 09:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.335
X-Spam-Level:
X-Spam-Status: No, score=-9.335 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, HTML_OBFUSCATE_05_10=0.26, 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=eSGf3KWV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KRtcQ1i2
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 KH2JAW4yFHwY; Mon, 24 May 2021 09:39:05 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC0E3A2DF0; Mon, 24 May 2021 09:39:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84471; q=dns/txt; s=iport; t=1621874345; x=1623083945; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=O13OecCsAvznB4AKXqVCBvbMWa0F0UC6oxC3egHgaQI=; b=eSGf3KWV2sul+zAte71mPYWdj8HfC+9wqTLwRHefBOJ2ns8dj2PgIjlX m4WHKRbTcjusAuP7/qV76gtlCiA080/SXE8UVa3a8Hw16h9qwVdZrFqA9 0NK3TKQrk44w+oTS/NOrPo2AAwiLpkvqCnsCtYWCHxxtO6uPFw9du5wzt k=;
X-IPAS-Result: A0A8AADS1atgl5hdJa1aDgwBAQEBAQEBAQEBAwEBAQESAQEBAQICAQEBAYIXgSMwUX5aNjELhD2DSAOFOYhrA4o/j0CBQoERA08FCwEBAQ0BASoBDAgCBAEBhAxEAheBZwIlOBMCBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohWgNhkQBAQEDAQEBEAgDBgQZAQEsAgkBBAsCAQYCEQMBAQEBIAECBAMCAgIfBgsUCQgCBA4FGweCTwGBflcDDiEBDo0AjzQBgToCih96fzOBAYIHAQEGBASBSEGDMA0LghMDBoE6AYJ6hAwBAYEThUgnHIINgRUnHIIwLz6BT1BCAQECAReBEQERAgE3CQ0JgmE2gi2BWT4zB10EDTYOAiAPIQgDPSwZJQYpBQ8vkHuCdwFCiAqeMlsKgxeKCo4EhU4FGwmDW4sZlliGWI1XDI0SgySUZQICAgIEBQIOAQEGgWsia3BwFTsqAYI+UBcCDocfhwAZHoM5g0aBEzuFBUVzAjYCBgEJAQEDCXyHaQGBEAEB
IronPort-PHdr: A9a23:dKy2bxGzdlvJlmwrOMggM51GfsgY04WdBeZdwpMjlrdIc+Kv4pfve kHT+KYlgFzIWNDd7PRJw6rTvrv7UGMNqZCGrDgZcZNKWhNE7KdenwEpDMOfT0GuKvnsYn8zG NlHUl4j82y4PA5YFNutL1HXq2e5uDgVHBi3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJ xLwpgLU5aEr
IronPort-Data: A9a23:O+/+8ajzH9X+/gTha5sBJOTdX161vBAKZh0ujC45NGQN5FlHY01je htvCGmCa6zfZzamfIp+bYvnpkwOvsXcmNE2SAZu+CA0QyhjpJueD7x1DKtf0wB+jyHnZBg6h ynLQoCYdKjYdpJfz/uUGuCJQUNUjclkfZKhTr6eUsxNbVU8En551Eg/w7RRbrNA2LBVPSvc4 bsenOWHULOV82Yc3rU8sv/rRLtH5ZweiRtA1rAMTakjUGz2yxH5OKkiyZSZdBMUdGX78tmSH I4vxJnhlo/QEoxE5tmNyt4XeWVSKlLe0JTnZnd+A8CfbhZ+SiMay6QWPtQsN0BuoAqWkI0rk P5Mi7XgYFJ8VkHMsLx1vxhwCSpyO+hN/6XKZCH5us2IxEqAeHzpqxlsJBhpZstDpaAmWicXq KZwxDMlNnhvg8q/y7+2YuJtnc8kasLsOevzv1k/lG6DUax4Hsirr6Pi6tFY4nA2vvB3EN2DO uMVN2QyaDCfSkgaUrsQIMtuwLj37pXlSBVcs0i9pKcr7S7U1gMZ+KTqNsuTft2iWcJTjwCcp wru5GTjCx0WNNW3yyeD82qhnKnJkD+TcI4IHbOks/5nj1Geg2gIElgYUVar5PC9hUn7Uc0aI EsS0isjsaZ081akJvHlUhu35mWEtxkSRvJCD+B84waIjKHSiy6WHGULTztAcsclpec5QDUr0 hmCmNaBLTdvt6WNUlqW9rCMtSj0PjIaRUcLYygDVSMM58TmpoB1gg/MQ5BuHLPdszHuMSv7z zbPpy8kivBKy8UKzK68u1vAhlpAu6QlUCYs5CjdcFL76TpSW5GqOtbwwlnlxKZpedPxoka6g JQUpySPxLlQV8jQxHLVH7ll8KKBvKzUbGKH6bJ7N9xwqWv1oS7LkZV4uWkmfC9U3tA4lSgFi aM5kTlQ759aJnexaqkfj2mZVJlynfGI+TgIqpnpgjdmeJN9ckqM+ztjIBf4M4HRfKoEzPxX1 XSzKJvE4ZMm5UJPl2beqwA1iuVD+8zG7TmPLa0XNjz+uVZkWJJwdVvjGAXXBgzexP3dyDg5D /4FXyd340wFCbanMnW/HXA7cA5aRZTEOXwGg5UHKrHcSuaXMEogEPTWiYgwYJBomr89qws71 iDhCx8JkTLCaYn8AVjaOxhLNeK0Nb4i/C1TAMDZFQvxs5TVSd30t/l3mlpeVeRPydGPOtYkH qFZJJ3YWqonp/au0211UKQRZbdKLHyD7T9i9QL8CNTjV/aMnzD0x+I=
IronPort-HdrOrdr: A9a23:a4ImpK9QVQ1Kv0XOv0Nuk+EOdb1zdoMgy1knxilNoENuE/Bwxv rBoB1E73DJYW4qKQ4dcdDpAtjmfZquz+8K3WBxB8biYOCCgguVxe5ZnPDfKlHbakjDH6tmpN tdmstFeZ3N5DpB/LzHCWCDer5KqrTqgcPY59s2jU0dMD2CAJsQiTuRfzzranGeMzM2fKbReq DsgvZvln6FQzA6f867Dn4KU6zovNvQjq/rZhYAGloO9BSOpSnA0s+4LzGomjMlFx9fy7Yr9m bI1ybj4L+4jv29whjAk0fO8pVtnsf7wNcrPr3PtiFVEESotu+bXvUnZ1SwhkFynAhp0idyrD D4mWZlAy200QKIQoj6m2q35+Cq6kde15ar8y7pvZKkm72ieNr/YPAx2b6wtXDimhcdVZhHod B2NyjyjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1SwKp5KuZLIMvB0vFrLA CuNrCU2B9cSyLUU5kYhBgl/DWIZAV8Iv6reDl0hiWl6UkfoJki9Tpt+CU2pAZ3yHsScegw29 j5
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,325,1613433600"; d="scan'208,217";a="717242670"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2021 16:39:03 +0000
Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 14OGd3FS016915 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 24 May 2021 16:39:03 GMT
Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-005.cisco.com (173.37.102.20) 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 11:39:02 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Mon, 24 May 2021 11:39:02 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Mon, 24 May 2021 12:39:01 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WSydtcWo1O11DBh3jRMYcwwxZdvVmlzXcGQG3CCRARR0AmGWmkFf1/hlxEo6vOTgyIHS+MUaOdkyTcRFK/YOZyYUtbmcVYLMKdpt0aWyot4ZhUbLRF7bybo+sGlJCMv7YvQF3cV9aQKIfxxXc45Vy5xjF/Drd0gyLD8wYoKUvKHYEStBqUebebNcGTuyDS+cjh6/+ljJUMYGUb1/KQmIlU9VS7grjFh7Fslyy5MruSdI4LS4+9RaQoglnLXP3vD/8DF8G9tMZCB8poqLDAl8gy6jWN66UeqT4D7a52DcElvsx7AON4CXt40G6cjbVSkeXSJCUt8jDfUHV9/2ubVdmA==
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=O13OecCsAvznB4AKXqVCBvbMWa0F0UC6oxC3egHgaQI=; b=E7ZNdaj//M68l9Pw1lfB6XoxbjVSCfS/q9SQAW4cEtOqhPFTjgFklPvSvySrnRMIEXWVaYMxNwgbxCai2xalXXpG+w65OHp9Cr6wMnf4D2M81NxFSX0MMwNiGGqRkkFsB30ULlmeCztNgSoLU6xtWavrqjs7JUyWM986Qg4ewGsGngc18TYyIHx8vl4OmZfObGp0jA/5Ca1UloMzQaLb11lWsJbLo3emSitAWeCaZKb98C5tF58VoxRbtk2XnipJfBs+IIkKwJge6yWnJuWDIzi9JpB3/kU/amoT6sA9AZSbKaesczC79Ma5E4Raz1xpc05ydhIGRjOGhhvI/wSajg==
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=O13OecCsAvznB4AKXqVCBvbMWa0F0UC6oxC3egHgaQI=; b=KRtcQ1i2oUF4/mWMsuJPuiGKQrZfgoW2r8+f1v3TY3S6uejrYR0wcxGeWSyKgotuXyxZ10lNwv5Fis/Lzl5k2lrldeArC0qGV79P7w/VN4dOoUWvzWVxGDTEx0yTCH4weR9/9BzYheQETcpqPfknE3KM3Db9lsylzyW2aMkphb0=
Received: from BYAPR11MB2887.namprd11.prod.outlook.com (2603:10b6:a03:89::27) by BY5PR11MB4086.namprd11.prod.outlook.com (2603:10b6:a03:187::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.26; Mon, 24 May 2021 16:38:59 +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 16:38:59 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Anoop Ghanwani <anoop@alumni.duke.edu>
CC: Christian Hopps <chopps@chopps.org>, 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>, Tony Li <tony.li@tony.li>, "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///IXgIAAU0OAgABlwwCAAItTAP//0PKA
Date: Mon, 24 May 2021 16:38:59 +0000
Message-ID: <ED420D8E-54D2-449F-A9A7-9903278FE5C0@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> <8414EAB5-BFA0-4A81-8F1F-BEE5BC9BC67C@cisco.com> <CA+-tSzxrMncSbBhiRrCWq8XD4JLWar6j1ROocUG4FCu-P+NJUA@mail.gmail.com>
In-Reply-To: <CA+-tSzxrMncSbBhiRrCWq8XD4JLWar6j1ROocUG4FCu-P+NJUA@mail.gmail.com>
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: alumni.duke.edu; dkim=none (message not signed) header.d=none;alumni.duke.edu; 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: 22b2f5db-b8b0-4a76-51fd-08d91ed26ea8
x-ms-traffictypediagnostic: BY5PR11MB4086:
x-microsoft-antispam-prvs: <BY5PR11MB4086724F6CF994DB2F69B292C2269@BY5PR11MB4086.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 9tFNmFv5lkCzTxp7iX3pZ04xfxQsyUhsiSRcxc2I/J1z/dZK5vKUqQweEMeSK+luC3yJjKF4JP52RxSIIl19hBjEUgmviD17E0Q3ESI5a8eubNDWb4vHMn4nB4xoCBrgfNuwDZkuSP9WNmUK7VZxYmpCXFzDw5KTsh+MFaMsEFmgWECufQPjQMB3aSHfRI1342Ga0e4zdJWQKppDYO70MBcxc597eNGGYQY5EPqztgBGlRSuHRqblVtMYKD+v3JI1I7UQ0o7HjsO+u/CtY3HM2iy9ME7sFyr6mwxChARM9ArSg4n/D1zqX9kM/f32L8GbpiOlgUDxN3o6cH2GW1aksfStUEfXn5s64dIDDI/8G8AYAHRCQwWxfeYm9MgPJWhdd5zvaI0zebYPd7HiMPCHcmo7nIe4d/AnVMDUmt43hfDRPfd/k3wy2mkCdZAzOAkd5AR/yM4nTgEwiuIcyJLRlKSy7yCF2eKY5GPUO+GaWH8BWAHRdT7Fu3hAiyRDFNIPblW/ALOXtr9tpT3z267hFml7hltxcjqduKKXSC+ZthLkJ+mq2JH+oha/dd1XydYqop4qg3fFSeJzOlFX1pVDmZfhzfXhuTmSsZxH3BHcZTRigAuyRdX3w1OiyToD8WmbzyV4DALNH4i8Cd5Vv3lS9vT+kKAXW2nJvJ1UVpdxL38ks/RXBE6ehRGREQCRY+bXYmQC1xk/cN2sCvnyZu+jG6THKmvbxKy7WUkNce3DjI+EToWMP8G0hA8Uu4DJSqMBUX/4omN/f1vF+tDI55QlA==
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)(396003)(346002)(39860400002)(136003)(8936002)(83380400001)(76116006)(86362001)(33656002)(54906003)(6916009)(2616005)(478600001)(66946007)(8676002)(186003)(4326008)(64756008)(66446008)(66476007)(66556008)(38100700002)(316002)(6506007)(53546011)(26005)(71200400001)(966005)(30864003)(5660300002)(36756003)(166002)(2906002)(122000001)(6512007)(6486002)(45980500001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: JvdXpKD+PQHMvcLeg3uNn1yGn7glOAl9p7EVijWF/EP53W311/KQn3JXIc7oNc0aPNkkd3xOpwa86fpIS1vfhPMEVOfk47wKTltvR5gviEIRRxu7Z3qb3osd5VjMyINRy5lzuo4vqhNwk5otjPHyI2yuqDSAVkYVEZrPSO5LIVmdixtMRW/tIN5b5BFfwmkPAfFIIv4TeLUGQZX8lJ1QZEUrsdAhaIUgKd8xHP2Y03xi6MhT7TdGwO9jyin3nW2oJPDUYWcz2MavNftwvhn4teHgBU+8mwM4/qNSbP3//gge5yLV3Oo9wLA6dI4qV6YBhWuhpBpJ0bgnf13GOgkV2bP5csZzjFVncT8/UEm4YCq7KFb/7/gTOidyGi0RT05hd3k0skmQhtMjFLbbedO3N05IghUx+bJjXj37YYYQ7Oi26qfHEh1Vo424gJlv/GFGwuI1u7k7YNMtipwgyCE5ITXZBpB23y7KvPsqY9bIGgklr/8uCQrzAe7opUTjRdJ0ymazFDUblD2mzC3qFPm7U0tZ8oXWbjw9qbiyVKY4f45UVIp2Pv+VGVTPqrCAB0I82f/4IAe3RN6pkJrO1ftwzmD59QYi7jWRccjhwvPzrWj9uZHVF3PHndfehX58K2kZV7Q7NuXNzeQzBKVvb9Kd9u9lrE85Vpn1SaNULLcJsNm50zV3ZGANY404pApWLdchRecpAF/EYk1xokXCQnhhTUeeDIQTDxKQIfoJhAYk00+yJyjyNwZn7jbprBYwAWdvONm+qN+tN7SjTPy1VIuqkC4Ho3zzTmVJ/YURUHBQ5i6fdjzKxybJdTGCuRLvGwTqyrbFA2KwjpHP87zwlxo6xXyGnNhwSNijuH4N+YhuLJztzLLOuONfiNclKzSwuWonqMF3m8gChd9+UuHsXS0S4vGJs1BxE0UAn/h+TwTQAdPMy5Zy8iCXGuxiNRS4OdKOPagZEBaSOpchVWlymXPbNnE02o38d1lsDM97gSRlYp5rEyhg18sqHjDE1DARwgW9cDEY/9ioKjoajvi0i8Oe+joJC6KEWeTQrIWrkM6T6jq7p5N4JRH7MtFUm0evPLCzTTjLKbZgT49paBsNXlpqW1ZZbT6xonew0kVDviFKu9IvVjLYITZInVDPP8LI3IAd58YJRB3LSDiM7JKZJZckVEAwowNYo0KStL0YJkYcAtWJpfX0/RMj52YA8rv4hLaufMiOSoWRf5weqJydHb9tFjOta8NFGYMA7SAiDElcvZtQ0Lh2G0nsB9EPwsG/P+hWldxPol1Jy6WnxefNHaDwHPptUl+MLsP8F+zP+O95oFCR5QsEGgIxunrhBqYIZIhU
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_ED420D8E54D2449FA9A79903278FE5C0ciscocom_"
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: 22b2f5db-b8b0-4a76-51fd-08d91ed26ea8
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2021 16:38:59.7036 (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: ZQ8laS4KWmX1Z97Q9MLgKBYw3H7xiFerczN8Tw+cWnEDzhhR+sPcPtB9O/FhX+NP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4086
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/1-b7TQk2vvQFFkMYGeyGrZhELok>
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 16:39:11 -0000

Any measurement of delay would include the both components of delay.
Thanks,
Acee

From: Anoop Ghanwani <anoop@alumni.duke.edu>
Date: Monday, May 24, 2021 at 11:28 AM
To: Acee Lindem <acee@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, 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>, Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@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

The part that Chris mentioned (transmission delay) doesn't depend on speed of light or cable length; it only depends on link speed.
The part that you mentioned (propagation delay) depends only on cable length and speed of light in that medium and is independent of link speed.

Typically, the speed of light in fiber is estimated to be around 2x10^8 m/sec.

There's also packet processing delay which I mentioned in my other email and queueing delay which I forgot to mention.

I think it might be a good idea if the draft mentioned what delay(s) "SHOULD" be used.

On Mon, May 24, 2021 at 4:10 AM Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:


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


    "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org<mailto: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<mailto:tony1athome@gmail.com>> on behalf of Tony Li
    > <tony.li@tony.li<mailto:tony.li@tony.li>>
    > Date: Sunday, May 23, 2021 at 4:56 PM
    > To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
    > Cc: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>, "peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>"
    > <peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>>, "lsr@ietf.org<mailto:lsr@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>"
    > <draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto:draft-hegde-lsr-flex-algo-bw-con@ietf.org>>, Acee Lindem
    > <acee@cisco.com<mailto: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<mailto: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<mailto:40juniper.net@dmarc.ietf.org>> wrote:
    >
    >         Hi Pengshaofu,
    >
    >
    >
    >         Pls see inline..
    >
    >
    >
    >
    >
    >                           Juniper Business Use Only
    >
    >         From: peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn> <peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>>
    >         Sent: Thursday, May 20, 2021 7:26 AM
    >         To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
    >         Cc: acee=40cisco.com@dmarc.ietf.org<mailto: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,
    >
    >
    >
    >         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<mailto: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>;
    >
    >         日期: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<mailto:peng.shaofu@zte.com.cn> <peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>>
    >         Sent: Monday, May 17, 2021 12:49 PM
    >         To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
    >         Cc: acee=40cisco.com@dmarc.ietf.org<mailto: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,
    >
    >
    >
    >         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<mailto: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>;
    >
    >         日期: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<mailto:peng.shaofu@zte.com.cn> <peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>>
    >         Sent: Monday, May 17, 2021 7:40 AM
    >         To: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
    >         Cc: acee=40cisco.com@dmarc.ietf.org<mailto: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,
    >
    >
    >
    >         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<mailto: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>;
    >
    >         日期: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<mailto:peng.shaofu@zte.com.cn> <peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>>
    >         Sent: Thursday, May 13, 2021 1:05 PM
    >         To: peng.shaofu@zte.com.cn<mailto:peng.shaofu@zte.com.cn>
    >         Cc: acee=40cisco.com@dmarc.ietf.org<mailto: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]
    >
    >
    >
    >
    >
    >         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<mailto:lsr@ietf.org>;
    >
    >         抄送人:draft-hegde-lsr-flex-algo-bw-con@ietf.org<mailto: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<mailto: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<mailto:Lsr@ietf.org>
    >         https://www.ietf.org/mailman/listinfo/lsr
    >
    >
    >
    >
    >
    > _______________________________________________
    > Lsr mailing list
    > Lsr@ietf.org<mailto:Lsr@ietf.org>
    > https://www.ietf.org/mailman/listinfo/lsr


_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr