Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Tarek Saad <tsaad@juniper.net> Wed, 03 March 2021 22:47 UTC

Return-Path: <tsaad@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 0B9453A1CA7 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 14:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.356
X-Spam-Level:
X-Spam-Status: No, score=-3.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=tknPZhEE; dkim=pass (1024-bit key) header.d=juniper.net header.b=EaFksFam
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 I4ZOACpmEjvD for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 14:47:36 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 15E983A1CA5 for <lsr@ietf.org>; Wed, 3 Mar 2021 14:47:36 -0800 (PST)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 123MZTfE001180; Wed, 3 Mar 2021 14:47:32 -0800
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=YyTsJ9L5TE5pDTNwZyaiutax/fGJDZKIdnkSSLroAUM=; b=tknPZhEE7as31wLfYJDPM1iLfZMLb79ufFowXJH+TiY76qXKL2faeBQKou12QwWphzfl b8MM3Ec7EqAOrGyZzjeFfum9KIuNAAe2pwlx1XUR3g1bFIBqMF0ZCaG7NBDnm3rds8MU qY5mTpH1CqV4MmBcfK0K63kauC16Myyu4IBIq3y1tmgpy023iqGSIzHdARx6QUWN/H99 +3+zsK6G+BSlQ8ZJKxAuyFcRDGEEMXhqr1limj8CpGDgBoVJaDiLWikm3RNCIGB5lHiG seBoQsyiDKc0954BSrLXU8XZxOSKpI1IfFXrRrcTUr79zP/MMovAl+CL3rogHTtVcaWD Dw==
Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169]) by mx0b-00273201.pphosted.com with ESMTP id 371jcn3yjx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Mar 2021 14:47:32 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=acVuMn5ooNSn/F6BZ9jJ5sknJKvR7eRuuQ3kJcYKVX/XMJykDNgxiFvyHoc/8+fMOmbDIi4h8b0jf+dbv7lxCCgpU9yGgrz5L7AoS/VE1aFtYYnjFo8/GzzLdu9j/Z4oCvNNuMuIPrsuSdJnz0OucnYgoDjQJIz5Vn94sLdn2vhCzxNt5UEsMEtAJ7Go7NETqPZyqdSHXmx5pG+uqW/LONc6ry5hIudMmpgw1h6PQIIwXpvZQ88fklhjMUDHgI5oxu5JGoV73NiEi315iyQJJSFcyEIjakElzprwYn/2q+tfp7UkE0PwpsMLFcWs/vytZ5yYFHRsvq6tEQdDvAMliw==
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=YyTsJ9L5TE5pDTNwZyaiutax/fGJDZKIdnkSSLroAUM=; b=PUVZHFM3CpSbPZDw14nozFt4oIIrUZ10JW1HHTeo7gqdCSqJ+i/lXNFLgcLgb5f/k6GkD4wuz/Z0mKgiv3jkDI2/1Fvx29HysEnmQukglkOa6PSeahWBDmTPM3VEqvZmFJyPWNH1630GF0jm1Ql73dn9+1ZNGLbXrldHvwSxjz3lAGlh9I7zYIGoYTML6VNRa9YO2pO5IRgxE5W9u/RzGjjjgrb77BblKYAQDV2aELuy0QG/hHvz4RLSoOLwRs3AsQ3jDw4vl5pHSPAQ2yEfKUNHwO/ri06bYylQlEzWI2Q0DEP4/7Q5bZahejJ7ALgtqqN9PU5T5XScCmFWloPjpw==
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=YyTsJ9L5TE5pDTNwZyaiutax/fGJDZKIdnkSSLroAUM=; b=EaFksFam/21DqfEU1UlR1vJGtx4Q7kZwGvzOaekvmvsGp/VpTy/ZYTiJ/apgTVHivoXcsKt/Mrk8yVjhdLppOsgm5U98atYbDjj9IDgW25jYZBfV1ck2jmwCUneoBYHK03JcZjh5S1rOWfW/yoKxYE6N+uLLVQEUihbPkQyH25Y=
Received: from BYAPR05MB4136.namprd05.prod.outlook.com (2603:10b6:a02:85::18) by BYAPR05MB5142.namprd05.prod.outlook.com (2603:10b6:a03:a3::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.9; Wed, 3 Mar 2021 22:47:28 +0000
Received: from BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::cd99:e95b:705c:2420]) by BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::cd99:e95b:705c:2420%4]) with mapi id 15.20.3912.016; Wed, 3 Mar 2021 22:47:28 +0000
From: Tarek Saad <tsaad@juniper.net>
To: Tony Li <tony.li@tony.li>
CC: Gyan Mishra <hayabusagsm@gmail.com>, Robert Raszuk <robert@raszuk.net>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>, Rajesh M <mrajesh@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>, Peter Psenak <ppsenak@cisco.com>
Thread-Topic: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
Thread-Index: AQHXEH1ZmkwMex3QSU2oIyqylhIINapy26QA//+t7oA=
Date: Wed, 3 Mar 2021 22:47:28 +0000
Message-ID: <C6466A5F-BE30-4EF5-BFDC-3E411E3D4427@juniper.net>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <DM5PR0501MB380079CFD75C78610130D81BCD9D9@DM5PR0501MB3800.namprd05.prod.outlook.com> <CAOj+MMHKazMG3wnUA+Kd2wg2hfr01CdF5w5YYKdFaHU4_V+0SA@mail.gmail.com> <CABNhwV0UKB=HaMs9eLvvp4fVLPsEtJhQ2xFmwY80sqBNDFRudQ@mail.gmail.com> <DM5PR0501MB38006C4B638AD2AB6A7731B5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com> <7C67D01F-24DB-4450-8587-E004CAFBBEBC@tony.li> <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com> <08882555-009B-4068-ABB0-20B0D165D722@tony.li> <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com> <52B3A5ED-6ACC-4772-BEF7-085A33A53F31@tony.li> <e5190522-3a8b-2d6e-c2fe-646049689cc4@cisco.com> <1EABA651-2F05-415B-97EF-054507FADEAC@tony.li> <f935dbc4-6220-5f47-65a4-f642823f594f@cisco.com> <CAOj+MMHXd5j8B9a13E90HQVB=SUOkQ=fqhyJEgTf-Y7Tp5eiBQ@mail.gmail.com> <BBD5B678-D3B5-4E9E-8F9E-E054D9867EF9@juniper.net> <AEFDC6F4-3680-4100-9844-5934E060D684@tony.li>
In-Reply-To: <AEFDC6F4-3680-4100-9844-5934E060D684@tony.li>
Accept-Language: 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_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=9a2d5b7b-61de-4543-beb8-bd2d35c95692; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-03-03T22:42:27Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
user-agent: Microsoft-MacOutlook/16.46.21021202
authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [2607:fea8:e31f:e400:4c6d:60d4:d750:9034]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: c205db6d-bd8d-4a14-2ea2-08d8de9652db
x-ms-traffictypediagnostic: BYAPR05MB5142:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR05MB5142EBD1FAF5F6A7D83E763CB7989@BYAPR05MB5142.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Rz2IR+hQ6wJucsFWLQf/dhEc0LD2nDTZAPEWt2Bt4cGIa8azhPSWXukJ9+Qjq5WQoBH0j9eTPeUkqbKUFvcDe9X+RJP2pYMYICAX9xEVwh4bSOQwhxY5HvxYTHEqQmYth1jbWcyk2/1tpR6su1bN7TWNYthM8VZOlasqqP5HKqe72m2tKec97fgIF1JDCV3yhtIGvm6J/bKlP1P2j606yhHLY06n+XL7p9GuAxrG684+rcFRbyELxdRG0F7Bayl7P2hTGaDnWFvzuqa/m+GfrITQeietmewEefYftawGs/sh8R7186jVjdZFyBATw1EmDUfsEsJyHaXzBa08Gkm9Enz9x22bgchqxp0ocvPcxU7ArpzgH7YaeTEVukGl1N8Ne6l45eR4ZSBXyyQovC/59M7Yfe5lXJRCSPAvySxqy3cpWgINjcwN0I5TQYJHtRr/OXCaFo9iyshTC2CYvqJfKW8aXJ4Gg9uyRimhpNBn+xWA+GMfdIMlGysKGb/VpAy7fPyXQYsCI+yUPBCGLxDk9j2OA4p0+dm5F9BJhgKDx/zqzVPUi7zBeUasJ0DKGRiqUuK2a234Uimh4cQhxOdhjQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB4136.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(39860400002)(396003)(366004)(136003)(478600001)(76116006)(83380400001)(6486002)(71200400001)(9326002)(6512007)(64756008)(2906002)(66476007)(53546011)(36756003)(66556008)(4326008)(66946007)(8676002)(186003)(8936002)(66446008)(86362001)(33656002)(6916009)(2616005)(54906003)(5660300002)(316002)(6506007)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Wi9IWkhlSnIvbHNoYVJLa0VpY1lWM2JxcHBqa0I1R0U1alA1eDFabVRiOGoz?= =?utf-8?B?TnhMYTc0RGpXYStMRzZ6M0sxVHhsSkFDKzF6U1ZDRktsbnFqVXBvS1NnNUpD?= =?utf-8?B?MTlHUnF3R3BmQWxwenVBVzVRQVd6Q1BXUHBIR01BNHlYT3c1Q1B3cTV3R2VY?= =?utf-8?B?MDAxM3ErTmxKdFh5WXNYMnhhbHBqZlFIUExHeG50U3h0NFY4U1UvSHdOcTd5?= =?utf-8?B?WG9MKzZCTTZmYlorZGJSN2t0dVJFUkJGdlRRdXVtc3k3Z2VXRzMvT3ZWY3Mv?= =?utf-8?B?NGFhTWljSDBLanEvOVlFTVdtb1Raa2dxM2xjTXNZVE94NjVsbUlMVWxiMHlh?= =?utf-8?B?bWgzU1E3UUR6d0h6T0wwKzZNWDZiQlp3RTh0MVdWL1krdDQ1ZmpzL3JraXdX?= =?utf-8?B?Rmw4akxrOTRaL09KSG4vM0k0T0wyYmNBVVl6Rzg1bnd2VFBET0hwekxUWUxP?= =?utf-8?B?MUthUEJ1SDZ5L1htOWdoblB6Tmdpak8yODY5dUYySWoyQzJyaDZKOXVHSU1z?= =?utf-8?B?dHREL2VYQ2p3NUdBUGlJQWpBcmlmVFRhQ1JQM0lJMDZSUnBrTnNmaEFiUVZU?= =?utf-8?B?VnN3K085M0wrK0ppQTRzWjVMTDZVQkpBQzBuelM3YUpPbXlraDRKNmhHMmVY?= =?utf-8?B?TnN6endHaDVCQlVncC9GK2pIWTdZZXd0UXFxVThRVmMydmNGOHpKM2kra1dJ?= =?utf-8?B?aHZqU1Vrbjl4dUdlbFVXV3dIMFJLS2xTTFcyMDhzdmttL3c1TnVQdjZsZXRC?= =?utf-8?B?ZmcvMzhyc2h3ZExJdURGMFNxQm5Ca29hVkpoTWZYcHFsL1ZUN2lmQ053RnV0?= =?utf-8?B?MGJtWkhQZU1KNy9ubFp3Mm9WUGI3Y09IMTJ0cUhSMGxwZXJLVElpcVhtSlpz?= =?utf-8?B?dDVqM0piTnZoQVpjR0xLU2pFTzhyN01IdTdsdWhQUEJ2Z0FlZ1ZhSk81Wnc0?= =?utf-8?B?aEl5TitDM1VPQXVTQW41dDZNdWx3L2tZU2tyQzVTdnYveE0yNkJ3dDVZQTRH?= =?utf-8?B?bytvSHZtcXZCeVNZb2didmpZNUFLbUVoM3RtbHdnMHQ1emtZWG9nUEdlNGhL?= =?utf-8?B?ZUZvTHFnNzdjMzdPeGR3NVhXN09aak5jc0s5aWJRZDVuRml4cGZ5TTRPUkVL?= =?utf-8?B?VmNwd2NFMzY4ZkJZWDl3UXNoY2czaHVDbDl6bHNYaDJ5NTZONjZrVjczdmNr?= =?utf-8?B?R0xUMUJsVEhTY3ZkZ3E1anF2Z2xjcS9KT2V6aktDR2lYUHNFdVlvdmVEcDIy?= =?utf-8?B?SVVJeDV0Mk1EdXZIanVVR0NsUjdIQlZ2Mng1VGFNbVNaQmRGTlBYTTd6Wmpu?= =?utf-8?B?dlEvdnJmZ3c2QURoUWRhaDgwc2kwbmpTeCtGREtXOHh5ZkxyaDYvMVVZTjdD?= =?utf-8?B?ZXRFTktiUDBZRWVRblBNVkJPZjF5KzNIaEdHa0lscEFLbTdyUEJnNVBqMVlr?= =?utf-8?B?ZGtoUGF5NFgzaWgzMmF0dnRxMllEdlZzYUVJSW1mOXNhWVlkSE8wRkViQW9n?= =?utf-8?B?anVvZExIbTdINVllSmIveElSSG8rYTZtSElaV2lrbFk2YkhnbWlXUGdJekh3?= =?utf-8?B?K2RoVE1mTzUrU0IveXQvSmVtZ05mZHNVSkMyNW9IaTFwY21UNlZHbnpLME1z?= =?utf-8?B?djJWRUk1MXBqY0RTOG9mQW92NkI4SUlkMHVrU1Q3WkE4cXdZUERHWlR6WU5X?= =?utf-8?B?MlZVc3lHWlIxMlNKZ1ZoQlJCdmdzSlB2ZnRGUHptUjkxOFlxRUpBQktVRlZE?= =?utf-8?B?T0VMOThvYzRIbmp3ZHV5T1RUazBqaGRTZ2RZTm5ZYTFNb3VIVkRtNHBYZExQ?= =?utf-8?B?MGU0cnBjaHYzc0dSaHlTUGZ6STVmMHUwVzNBbW8xM0llOVlyUS83Q0owREJW?= =?utf-8?B?UWtzNG9vV0RzUEpNeit2TDltNENwVjlJUnRmSC9BOGhkK2c9PQ==?=
Content-Type: multipart/alternative; boundary="_000_C6466A5FBE304EF5BFDC3E411E3D4427junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB4136.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c205db6d-bd8d-4a14-2ea2-08d8de9652db
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2021 22:47:28.8452 (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: z0Fn1zHsh83y4aYGS9v6+0xGK3vOAeAxmYOYi9jZlIuqP9y/hw1Dm9uyyNPdEbsQ3402TSELJCtFJjKsBy/Alg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5142
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-03_07:2021-03-03, 2021-03-03 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 suspectscore=0 spamscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 phishscore=0 clxscore=1015 mlxlogscore=961 adultscore=0 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103030161
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/SBiLbE5Bfk44kAgxG6BFKBAfDUw>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
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, 03 Mar 2021 22:47:38 -0000

Hi Tony,

Yes, I’m aware FA is hop-by-hop..
My point is per-link delay changes can be suppressed and advertised at periodic intervals (usually order of mins) or immediately based on crossing a threshold.
The per-path delay cannot be accurately extracted from a “snapshot” of the view of the topology (e.g. adding per link delays for traversed links - as those values may quickly become stale). Such validation IMO (if any are needed) will have to come based on active/passive measuring mechanisms..

Regards,
Tarek

On 3/3/21, 5:41 PM, "Lsr on behalf of Tony Li" <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org> on behalf of tony.li@tony.li<mailto:tony.li@tony.li>> wrote:


Hi Tarek,

Please recall that in FA there is no path setup. If the delay changes and it propagates to other nodes, then the network will SPF and paths may change immediately.

Tony




On Mar 3, 2021, at 2:34 PM, Tarek Saad <tsaad@juniper.net<mailto:tsaad@juniper.net>> wrote:

Hi Robert,

The RSVP-TE world has had to deal with such churn resulting from frequent link attribute changes (e.g. specific to available BW). In that case, such frequent changes made their way to the network at periodic intervals and in the event they crossed a threshold. In my mind, the link delay attribute is no different and IGPs can react to it just like RSVP-TE did.

Obviously, any path that was computed and placed on a set of links based on a certain view of the network may quickly become stale. However, IMO, any per-path e2e SLA need to be validated (independent of the network topology) e.g., by active measurement using probes or other means.

My 2cents.

Regards,
Tarek

On 3/3/21, 2:57 PM, "Lsr on behalf of Robert Raszuk" <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org> on behalf of robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

Peter,

>  that differ by few microsecond

Really you normalize only single digit microseconds ???

What if link delay changes in milliseconds scale ? Do you want to compute new topology every few milliseconds ?

Out of curiosity as this is not a secret -  What are your default min delay normalization timers (if user does not overwrite with their own). Likewise how Junos or Arista normalizes it today ?

Thx,
R.

On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> wrote:
Tony,

On 03/03/2021 19:14, Tony Li wrote:
>
> Peter,
>
>>> There are several link types in use that exhibit variable delay: satellite links (e.g., Starlink), microwave links, and ancient link layers that deliver reliability through retransmission.
>>> Any of these (and probably a lot more) can create a noticeable and measurable difference in TWAMP. That would be reflected in an FA metric change. If you imagine a situation with multiiple parallel paths with nearly identical delays, you can easily imagine an oscillatory scenario.   IMHO, this is an outstanding concern with FA.
>> yes, and that is what I referred to as "delay normalization", which can avoid that oscillation.
>
>
> It can also negate the benefits of the feature. One might well imagine that Starlink would want to follow a min-delay path for optimality.  If the delay variations are “normalized” out of existence, then the benefits are lost.  The whole point is to track the dynamics.

for all practical purposes that we use it for, the two values of min
delay that differ by few microsecond can be treated as same without any
loss of functionality. So it's about the required normalization interval
- something that can be controlled by the user.

thanks,
Peter



>
>
>>> Please note that I’m NOT recommending that we back away. Rather, we should seek to solve the long-standing issue of oscillatory routing.
>>
>> not that I disagree. History tells us that the generic case of oscillation which is caused by the traffic itself is a hard problem to solve.
>
>
> Any oscillation is difficult to solve.  Positive feedback certainly can exacerbate the problem. But solving hard problems is why we are here.
>
> Yours in control theory,
> Tony
>
>
>


Juniper Business Use Only



Juniper Business Use Only