Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 24 June 2021 22:27 UTC

Return-Path: <jheitz@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1803A2D8B for <idr@ietfa.amsl.com>; Thu, 24 Jun 2021 15:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.895
X-Spam-Level:
X-Spam-Status: No, score=-11.895 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, 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=R+OzyhO4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lE/LSvSQ
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 e82RXrjW0wFT for <idr@ietfa.amsl.com>; Thu, 24 Jun 2021 15:27:44 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9C153A2D87 for <idr@ietf.org>; Thu, 24 Jun 2021 15:27:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20694; q=dns/txt; s=iport; t=1624573664; x=1625783264; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5OBTNV+BMbcm+6HjDqDqCeZxZ0r7vKJb/kL6FT7wuSY=; b=R+OzyhO4/9QDgG1jPTbtp80/QVEXYKk62x4gy+qLCMOL8yNDaZzUoKcS +2qZlIYe5wNxKg/g7001wwF8zKFdtnvymItgIkf2SjkuIfynQiy5cJYxk jSBrSifVJmY0y2R/qDxSzxY/veU+AEiEaWhvrcWar7YOyosBwb8r4rh8H k=;
X-IPAS-Result: =?us-ascii?q?A0BPAABOBtVg/5JdJa1aHAEBAQEBAQcBARIBAQQEAQGCA?= =?us-ascii?q?wcBAQsBgSIwIwYoB3daNzGESINIA4RZYIh4A4pLilKFAIEugSUDVAsBAQENA?= =?us-ascii?q?QEqAQoKAgQBAYRSAheCWAIlNAkOAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBB?= =?us-ascii?q?gRxE4VoDYZFAQEBAwEBARARChMBASwLAQQLAgEIEQQBASgDAgICHwYLFAkIA?= =?us-ascii?q?gQBDQUIDAsDglCBflcDDiEBDpsHAYE6AoofeoEygQGCBwEBBgQEhSsNC4IxA?= =?us-ascii?q?waBOgGCeoQMAQGBF4VKJxyBSUSBWIJgPoEEgRxCAQECgWArCYJhNoIugi4Ba?= =?us-ascii?q?w2BEAMREAlSKhskCBuBDZQLRIgYjSWRKVsKgx+XMHuFdxKDXz6hWpVighiNM?= =?us-ascii?q?5AchGgCAgICBAUCDgEBBoFUO4FZcBU7gmlQFwIOjh8JGYECAQiCQ4UUhUpzA?= =?us-ascii?q?jYCBgEJAQEDCXyLBgEB?=
IronPort-PHdr: A9a23:/j+08RYiljbiLldsixX+WqL/LTDJhN3EVzX9orIrjrtUeeKi8ojse kvF6qYlgFzIWNDd7PRJw6rTvrv7UGMNqZCGrDgZcZNKWhNE7KdenwEpDMOfT0GuKvnsYn82G c1YXxlk8m21d09PF5W2a1jbuHbn6zkUF132PhZ0IeKgHInUgoy32um+9oeVbR9PgW+2YKh5K 1O9qgCC3vQ=
IronPort-HdrOrdr: A9a23:6LLuYKN3wi9/gsBcT0f155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMgs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QM5SWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HCVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5l+7Y23+40owwfX+0GVjbdaKvu/VfcO0biSAWMR4Z 3xStEbTpxOAj3qDzqISFDWqnjdOX4Vmg/fIBmj8CHeSQiTfkNnNyKH7rgpLycxonBQz+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fLFuI4O5l7Zvtn+90a1wah7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWJ3v+0i946IfxY9Fqt1CVKZ4uKfaqa 6xGW+w71RCDn4GIff+q6Gj3Cq9MlmAYQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.83,297,1616457600"; d="scan'208,217";a="722793267"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2021 22:27:43 +0000
Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 15OMRhi6008766 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Jun 2021 22:27:43 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 24 Jun 2021 17:27:43 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Thu, 24 Jun 2021 17:27:42 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Thu, 24 Jun 2021 18:27:42 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JyWrt4RtpOMBp6OzGrSRdxzD/c47uzxGUTJ1SHGCcbNxc8Iy5BNkgo8glH1tWRFw7oYVT/Ev0LV1/5Et1RpXqhapgxCFiJ2rLrsWjeIS1iQi98zu2Z8gqxUXhfxsY0UMmEGPwFb83BNQ1il9w52th8BIdkn+J8M92OPRmvM3jA9TazLKEKLZoWFSoi2FZWC5SDb0PPYAkmWZ94fZDTOs4c/etC9OH0drZk66em3zY1pAp4jp5RDLZLCt3PTreYQ1QRRJT0WeAi7Dh/EuBMtMZJI8ao9HUBT5YjXzmyLcyRQ6ACRI2YBv+swlab7EpO2gjOmDfJdewdn17YsGtBzPZA==
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=5OBTNV+BMbcm+6HjDqDqCeZxZ0r7vKJb/kL6FT7wuSY=; b=ka2Na3x0tIiKh7qApgiK1ElWy7w78pkAdFUBDN0cGHpjHHlFk0hJZ+kiKDwiYy/VBiSPKyK4e4CVXylKHTjrEoMqm7v6RFKKaljHPdOlL6RTSlBrnjgk2xf5KDRNbM7kydQPCP2LtkuDf2qJ1al/4qbtV/bAYMJdThBd/fAnUFWi/F1adu+YqsEgubuup332CI8hY3UmF0vzNBSVCq3YxP0ei2O2Ci75bOuTcs9bZzAO9DCvfQ5bB5/qj4Js0nFpyQFHgg6zviZETzgifFAk80LfEn+Lx40DofMMjUyFLSy2U7cqp1VwvDSdhRIKflzZgg8Nrx3zALRfMlNUOzTlXw==
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=5OBTNV+BMbcm+6HjDqDqCeZxZ0r7vKJb/kL6FT7wuSY=; b=lE/LSvSQnZigaiYU4FbnU6S8hZrjGEG6YdiAs2GvItu+Hd/+4p0CAhAc2iOB/cGaW/LmYi1SITo54f72di3Nb9EbSBTipUD2PkN0DGtS6varwsDor5KhCydaTLKCo/XD5zjTSxK5ag7LZwbZs1NmlNxrlU415fPa2qQ8HkvMD6w=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB3750.namprd11.prod.outlook.com (2603:10b6:a03:f9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.23; Thu, 24 Jun 2021 22:27:41 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::5c60:81c3:b049:887f]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::5c60:81c3:b049:887f%6]) with mapi id 15.20.4242.024; Thu, 24 Jun 2021 22:27:41 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, Robert Raszuk <robert@raszuk.net>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>
CC: "dwalton76@gmail.com" <dwalton76@gmail.com>, "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking
Thread-Index: AQHXaSTVEauHMW2CTEKGa0jgcKDmnKsjn+aAgAANVACAABCm8A==
Date: Thu, 24 Jun 2021 22:27:40 +0000
Message-ID: <BYAPR11MB32077F99EB6206C6BF8D2BDFC0079@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <F689CF63-236D-401D-9C8E-AC1C39CDE772@juniper.net> <CAOj+MMHg1f2rFNHZLM-j7Jx-ji_zWLhesmrNdS5LWfsNk_x9sw@mail.gmail.com> <BYAPR11MB3207351F5FA437DD807E576BC0079@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3207351F5FA437DD807E576BC0079@BYAPR11MB3207.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:889c:1c50:135a:ec0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bb5618ce-5e89-4715-003a-08d9375f4790
x-ms-traffictypediagnostic: BYAPR11MB3750:
x-microsoft-antispam-prvs: <BYAPR11MB375093B5B7F6E9B238C5EEA1C0079@BYAPR11MB3750.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: J/Ab6G2yTjuneOrsOmZyjE4XVHOUIEXwZK+Ch6jmEk0bPzNiNfXbyPZy1T560V7UTMZyulbab0pFt4LWaDjiJ4if9NY8/g0ZICvf+NQK15TgZj85EeXgiQaUkXGQvrjZjWXzwJitEcydYlQHg1IUurdNodnde94YN35wA2b71RxlZ3059PTno8QS6p5Tyyr9jmnHp6nImg5kDld8ejgnUrWHWifV9T3Wsc5PlxgBqjOJfmkyah+0sfpA/wypDjSkgz5F6UYzvG2mcS92tdstUbkgJXpp8/e7Yicyxj3gJLOz1+0SIyiecLtdh6fuMG6xIejItsMBNo6NgR7GZRpJd0mTROjw+Y5T1HjArkJ0R13SLEcXPAkudz7pojnm/XDh0L5GNQJ1QMrYZImPIfhMTrxhaE+0vTydzeyBp1UYQltYMohKh5gYK1/nD148rSI+oM6KTG6hc2iiXUudEExgHGKxlrkD/fyxGq6rzxi/HkopwtgjEKM0/6bLIgaU2rIcQ77stH9D5KtrUm/SLuriwMkImxJBzhz104iwfPOp7rIcSzmd4sP7kAg5aihGWyNxRjtmDbIaDFc8kPGZ9LLv8x5hn4NV/Whb0PhJB1aullf/nOTWalxDQ/Tmd1i/iSz4a0v4tOCjhmkK9+h2n2PlH0LLcyPHcGtCMp+1Ixu34LJx2tI5dJTmpGcs5/RPSsQs/RSGNU2aafhF+5NjrTmiJLbSs7C4l19v8B9QA9e3oAY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(346002)(376002)(136003)(39850400004)(2906002)(83380400001)(76116006)(52536014)(9686003)(5660300002)(86362001)(166002)(55016002)(64756008)(66556008)(66476007)(66946007)(66446008)(66574015)(33656002)(6506007)(110136005)(8936002)(53546011)(54906003)(122000001)(38100700002)(478600001)(8676002)(2940100002)(7696005)(966005)(4326008)(186003)(71200400001)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SXpGK2NqeU9vUUtUSVVucDlsc1pOQ2lacHFGSzg2NzV0SGFaS3lqKzlKK3ZB?= =?utf-8?B?aVNuWnMzODJPcmpRZzRjSnNqUkJlL2pNNkh5SUJESkY5RUFhUEdwT1ZHNWZx?= =?utf-8?B?T2JBRkJHOEJpWHgybWgrb2EyZnM1THczY0d5V2tNUkJMQlp3aXJyT1lBb1FB?= =?utf-8?B?emNzVStiNStxZTQ3UHBsNmFrQUNCS0VaZS9DeGUxb1VkNTIzRFNuNDYxOHhB?= =?utf-8?B?cUw0RUwwOFROZVZ6UHBjVUhrSHVCMW5ONEhITmljNXE0RHhxTEhlSjh4cVB2?= =?utf-8?B?MlhrTmtJUUdZTTZZdVkrWWNxT1dJMnRtUHdLT0gvdlZWTFRsUElpa3FlUUpW?= =?utf-8?B?MUdIa0QxTU55SDU2UENjekoyejloVTl6QlJlUjF3Tjd4QVFHazR4eHV2RjFx?= =?utf-8?B?R3lMNnpnMFBEa1g5MHZDVm51cm5vc3MzbkpSSUxHQWxkUVVKNGN2TGxjU29w?= =?utf-8?B?VlBOYlpUT3Rmai9rY0twcjUrdUFjbjY3cEsybzZseDVxZTl5azJjMzZoblUy?= =?utf-8?B?MkhJWCtwUFE1UWRNUXJRcFZSSDFSV2FVV0hoQkx5TmxtVmJ5eVkxMGFNeGFY?= =?utf-8?B?Y2s4OGZOTGNpMlZ2MGVNMEpPQ0lvTFNkN3E2ZlkzUkVSZ3BXaGx4Mi9JM0tN?= =?utf-8?B?WHZmcGxDTkJSQWFlbW14dnQxZVkvOXNxa0ZZdHJhWS9sZzZhbDJLeWx3SXhy?= =?utf-8?B?YVdpOFFiWDRiVXc1Q2h5R0Q5ZmVZZ21IcnFLbkFxVkEyN0ZJc1I1M2p0c3pj?= =?utf-8?B?eUt4YTBxR0FFeGZJT1dLNjlFWlhLaEVKSHNzQ3VyWGRqSzQya29ZWWxscnRz?= =?utf-8?B?NXdMdjdIL0E0cXRwQ1kvZ3NLbFRJZHhkSkN4TkRaSTRneUJ1b1dKMERxTEJk?= =?utf-8?B?bDBZOG84T1YyRlp3NTM0WndrVU1BUHQ5Zklmc0lIaVBGMHJmYnRPUkNHdmRi?= =?utf-8?B?K1NVa2FNQ2hYcHZKdEFzaTF5ak4zS2FreG5sdHJBaXRPTERvMm14bllUTDZ6?= =?utf-8?B?MVhaUFlEVURBbVJLUXZjY1Uvc1JxV2prQ2RHYmVTUjhhYnpwOFN5N3l4YjlK?= =?utf-8?B?c29sdC9uRlBLT1hvRC9uQTZjeHZxZ0dIZWtWeXlRWmF3M0I2b3dwZFNUWStr?= =?utf-8?B?TDdCWkdQYzN5dytoRjRLbGVRZHIzb3VoSVV2RU1OdFJEM05GS1hoekNzUVM1?= =?utf-8?B?Z3h4bG01NEZVa0lYdnJnckNhOTBoc0gySE4wZjkyYWlVc09pdVMrV3FBSDh5?= =?utf-8?B?MGQxb0FTWm9hVVBNZVlNL1g4RWRtZVNIWVZpR0h4ejRpaGlWMlZldnAxTENB?= =?utf-8?B?aG9veFVCdGlJMUNnWWFSaEhUaHE4ZFZScWFQUk5ZZ0tZc1VQRU9xV1Z2c0lz?= =?utf-8?B?M29BYnQzcDViNWlqZXVlMTROR29kL2M0WkNaUmdGcUY4QTVNMk9ycHZtazR3?= =?utf-8?B?UGFJV2N4d25ZaHJrbjNtRy94TnlEbDRIMTYxSG1vSzhJd3U5bXhTRkhjVWk2?= =?utf-8?B?TG9WTlVuMlRqTmVYK1FMbGc0WEFvNE1BYWRaL0wyTXZCUWJhRmsvMVRaVkNv?= =?utf-8?B?bHdCUkliKzBGeWlsVDRMbklSc1ptckJWR3BONWRUTTlmaE1ScW02UldTNE90?= =?utf-8?B?dHVCL0Q4b1ZqM3NCTkI2SVVGWFgzVWE5L0dYVFNPOGpWU1RXUW55WGs3dkg1?= =?utf-8?B?WmlNVWwrcW9GZ1JEWTFSYmtWOHdnL2hkQVcwNU5FY2VVbGRZYTlxcFBFa1B4?= =?utf-8?B?ZTY2QWNEakJvcjlsR09WLzhTVHdOb3NzV3FJNExDNWJoNkZpdE5raFBPbXBM?= =?utf-8?B?NzNhV0xnREkybjExU2NQbnNkYkRTbkZvRUp0dkllNEh1dnluUVRZTFYxMnlN?= =?utf-8?Q?1I+dabj89Uj0P?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB32077F99EB6206C6BF8D2BDFC0079BYAPR11MB3207namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bb5618ce-5e89-4715-003a-08d9375f4790
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2021 22:27:41.0676 (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: KkV/aF5ywdyuHvj8yMo4TGYGItYTe4A1yfIB8PcFsQuL5GOXW0uin2aL6doYbtge4nCQoEm/Dph+f91ITzJ30g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3750
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1ahxrMzbhyYnw_IV6-sy5qN6bWE>
Subject: Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jun 2021 22:27:50 -0000

And then when the attribute length is equal, you'll need another tie-breaker.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org> On Behalf Of Jakob Heitz (jheitz)
Sent: Thursday, June 24, 2021 3:20 PM
To: Robert Raszuk <robert@raszuk.net>; John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: dwalton76@gmail.com; idr@ietf. org <idr@ietf.org>
Subject: Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking

Then the code would have to compute the attribute length for each path, carry it along and pass it to the bestpath compare function.
For what? To increase convergence time?
Because simple byte length will not be good enough and people will start arguing that
an extended community is just as valuable as a regular community and count the number of communities
rather than bytes and then the tunnel attribute is longer and on and on.
I vote for path-id.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Robert Raszuk
Sent: Thursday, June 24, 2021 1:40 PM
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:jgs=40juniper.net@dmarc.ietf.org>>
Cc: dwalton76@gmail.com<mailto:dwalton76@gmail.com>; idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] Bug in RFC 7911 (add-paths) and tie-breaking

John,

> because it’s technically possible to receive two routes for the same destination, from the same peer, with different path-id, and with all tie-break metrics the same

While this is not about risk of loops, those paths may possibly contain different optional attributes otherwise they would be rather duplicates.

More specifically one of them may contain additional optional attributes while the other may not.

Perhaps with add-paths while we are at this discussion it may make sense to choose the path with a longer list of BGP path attributes as such path may be more useful to receivers.

Only then when the number of such attributes  is the same fall to path_id as tie-break.

Thx,
Robert


On Thu, Jun 24, 2021 at 8:15 PM John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Hi Folks,

Claudio recently pointed out a bug in RFC 7911 to the authors, and we thought we should let the WG know. The gist of the bug is that the tie-breaking process is underspecified, because it’s technically possible to receive two routes for the same destination, from the same peer, with different path-id, and with all tie-break metrics the same (all the way down to peer address). My guess — but it’s only a guess, I haven’t checked — is that implementations may mostly have chosen to prefer the first path received.[*] But the only thing we can say with confidence is “it’s underspecified and therefore implementation-dependent.”

When I worked through this, my conclusion was that whatever option an implementation chooses should be safe, since by definition the paths are equivalent all the way down. I don’t see a way to form a loop even if every router in the network makes arbitrary — and conflicting — choices in this situation, since by definition of IGP distance, if a given router A makes an arbitrary choice, none of its neighbors when presented with the same set of routes will make a conflicting arbitrary choice, since the options are:

- The peer is closer to both destinations, in which case it can make any choice it wants, the traffic will not loop back to A,
- The peer is further from both destinations, in which case it can make any choice it wants, the traffic will not loop back from A,
- The peer is closer to one and further from the other destination, in which case it isn’t faced with a dilemma, it will choose the closer (and the traffic won’t go back towards A).

I guess if you’re in a network that doesn’t have IGP distances at all (maybe everything is static routed?) or if IGP distances don’t follow the usual rules of IGP “physics”, then you could create a problem. But those are pathological cases where we’d expect BGP not to work very well anyway.

Claudio suggested that path-id would be a good final tie-break; that makes sense to me. We could do a quick update to 7911 to standardize this new tie-break, we could do a bis of 7911 to include the new tie-break, or we could just leave things as they are, relying on my argument above that says there is no strong need to standardize a tie-break since any choice is OK.

For the moment, this is just an FYI for the WG. Thanks very much to Claudio for pointing out the bug!

—John

[*] You may notice that it’s possible to have two such paths packed into the same update in some circumstances, which makes the choice even more arbitrary since it’s pretty notional to say one has arrived before the other.
_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr