[Bier] Re: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Fri, 04 October 2024 22:47 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2713C15155E; Fri, 4 Oct 2024 15:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.641
X-Spam-Level:
X-Spam-Status: No, score=-9.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYVnRpnZvYoh; Fri, 4 Oct 2024 15:47:50 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF817C14CF18; Fri, 4 Oct 2024 15:47:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=150380; q=dns/txt; s=iport; t=1728082069; x=1729291669; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qHWWpujavteZ3ybSOKgzxcb0moLnBiiLoeTJe3rjVgI=; b=bDzTImB5jhUIbil8TRO0fJbr+yrTMwYuY3Xjlnpm/SQTv0Sr8KZ/T2mg 85bczO6BTQvPgf8CbAcgvXaP+KIGH1BIMDlGJKgEt5QhpSi+L49QDEQX5 /P/aK0MhjQRSU+EeoiKuwurIpyEBr5pgSlcZm5/xPFKoff8IpzhUHQ7E7 A=;
X-CSE-ConnectionGUID: EPVFfawCQ+uh7ztsYEAZ+g==
X-CSE-MsgGUID: 5o10ndnSQXGoLXXD/0jaHg==
X-IPAS-Result: A0APAADSbwBnmJxdJa1aHAEBAQEBAQcBARIBAQQEAQFlgRcGAQELAYFAMSooewKBHEgEhFGBY4FpA4UtiHMDgROQNYYygTuEYRSBEQNWBwgBAQENAQE2DgQBAYITgT2BNwIWigECJjUIDgECBAEBAQEDAgMBAQEBAQEBAQEFAQEFAQEBAgEHBRQBAQEBAQEBATcFDjuFQQEGMw2GWwEBAQEDEggBCAo6BAENEAIBBgIRAQMBASEBBgMCAgIvFAMGCAIEAQ0FCBMHgl8BghxIAwEQlCmPXAGBQAKKKnqBMoEBg1oCEEHbbAaBSAGISgEqgTICDoN6AYR3JxuBSUSBFAFCgWYBSTg+gmEBAQIBF4EAEQELBwEHHBUPBgqDJTqCDSIEhk0MDxqDBj+BEjoCgRmBCS8WD4IdQwQEAQYBDoIPCyhkflcPVwFuPhJCDoFFgT1mFiVOVRCFTYE1gReEE4M3inhMBnUiAyYzIQIRAVUTFwsJBYk4CoF5fQUhKYFFJoEKFoJ1gTMRgQgCgleBZwkST4dnYoENgT6BWQFFgnNKJAuCIR5hOYE+BTgKP4JRa045Ag0CN4IoJGqCWoUbgj8dQAMLbT0UIQYOGwUEgTUFq2cENgGBWwFHgWgBJQcBNwcGAQEVGwwmAQMNGwcMCAgGAhsFAg0gARATCAUFExwRBgIKAwsTCgEDDQEBFwYBCAIJIg+SORQQR4MrizpHhBeJeJNQgT4KhBiMFo4ohzQXhAVMjDWGf5EhP2WFTpMoIoI0iyWVUgMPDIUIAgQCBAUCDwEBBoFoAThrcHAVGiGCMwEBMlIZD4kugwKBTy4NCRZ2AQIBBIJEhRS9E3gCOQIEAwEKAQEDCYwAgX0BAQ
IronPort-PHdr: A9a23:4qG3ohPM/34YIkDrvlgl6nc2WUAX0o4cdiYc7p4hzrVWfbvmptLpP VfU4rNmi1qaFYnY6vcRk+PNqOigQm0P55+drWoPOIJBTR4LiMga3kQgDceJBFe9LavCZC0hF 8MEX1hgl0w=
IronPort-Data: A9a23:5wMezKKm5ovzH/lHFE+R+5UlxSXFcZb7ZxGr2PjKsXjdYENS1GMBy zMdWTjSPvfZMDGmLdx3a9i09x4PsMeHy4BiGwUd+CA2RRqmiyZq6fd1j6vUF3nPRiEWZBs/t 63yUvGZcYZpCCWa/k79WlTYhSEU/bmSQbbhA/LzNCl0RAt1IA8skhsLd9QR2uaEuvDnRVrU0 T/Oi5eHYgP8g2Yoajh8B5+r8XuDgtyj4Fv0gXRmDRx7lAe2v2UYCpsZOZawIxPQKqFIHvS3T vr017qw+GXU5X8FUrtJRZ6iLyXm6paLVeS/oiI+t5qK23CulQRuukoPD8fwXG8M49m/c3+d/ /0W3XC4YV9B0qQhA43xWTEAe811FfUuFLMqvRFTvOTLp3AqfUcAzN1DNH8YM4QH0d80HGER5 +ADGR0kXFOM0rfeLLKTEoGAh+w5J8XteYgYoHwlkHfSDO0tRtbIRKCiCd1whWhrwJsRW6eFI ZNEN1KDbzyYC/FLElgWDok0kf2nrnL+aDZf7lmSoMLb5kCJkl0hjOWyaIu9ltqiGMIMxkCUo Fn/z0v+JiEqGJvHyzOl/Sf57gPItXimAN1JTuLQGuRRqFeSy3Y7CRAKWx28u/bRokKkUtxDb k0Z5iRrp6k/7gm3Q8X9UgeQoXOYsFgbQdU4LgEhwBuGxqyR6AGDCy1ZCDVAc9ch8sQxQFTGy 2NlgfvEPQJBvrSKYkve67fLvy+pCAU8HywNMHpsoRQ+3/Hvp4Q6jxTqR9llEbKogtCdJd0W6 27XxMTZr+tP5fPnx5mGEUb7byVAT6UloyYv7QnRG2mi9A48OciuZpej7h7Q6vMowGelorup4 iVsdyu2tbxm4XSxeMqlG7ll8FaBvKvtDdEkqQQzd6TNDhz0k5JZQahe4StlOGBiOdsedDnib Sf74FwLu84DZCfzNvMqOOpd7vjGK4C+TbwJsdiJP7JzjmRZLlfvENxGPBTJhju8yiDAb4lkZ MzKKa5A8kr2+Yw8kWLpHL1CuVPa7is/3mjUDYvq1Aiq1KHWZXieD9843KimMIgEAFe/iFyNq b53bpLSoz0GCbGWSneMq+Y7cwtVRUXX8Lir8aS7gMbZfFo/cIzgYteMqY4cl3tNxPkJyr6Wo S3mBie1CjPX3BX6FOlDUVg6AJvHVpdkpnV9NispVWtEEVB6CWpzxM/zr6cKQIQ=
IronPort-HdrOrdr: A9a23:EvuZbahkq+ZS6DQ9IaxHUYroxXBQX5p23DAbv31ZSRFFG/FwyP re/8jzhCWVtN9OYhAdcIi7Sde9qBPnmaKc4eEqTNGftXrdyRqVxeBZnMTfKlLbalfDH4JmpM Ndmu1FeaLN5DtB/IjHCWuDYqsdKbC8mcjC65a9vhJQpENRGt1dBmxCe3+m+zhNNXJ77O0CZe KhD6R81l2dUEVSRP6WQlMCWO/OrcDKkpXJXT4qbiRM1CC+yRmTxPrfCRa34jcyOgkj/V4lyw f4uj28wp/mn+Cwyxfa2WOWxY9RgsHdxtxKA9HJotQJKx334zzYJLhJavmnhnQYseuv4FElnJ 3nuBE7Jfl+7HvXYyWcvQbt4Q/9yzwjgkWSimNwwEGT4/ARdghKT/aptrgpNScxLHBQ+u2U5Z g7ml5xcaAnVC8o0h6Nv+QgHCsa5nZc6UBS4tL7yUYvELf3rNRq3NYiFIQ/KuZaIMr3hbpXYt VGHYXS4u1bfkidaG2ctm5zwMa0VnB2BRueRFMe0/blmQS+sUoJh3fw/vZv1Uso5dY4Ud1J9u 7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCbKSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdduXQpc0zjBMWS1NlA8wzLQm+6QTPxo/suqqRRq/n5Xv7mICeDQFchn4+ppOgeGNTSX7 KpNJdfE5bYXCLT8EZyrnvDsrVpWA4juZcuy6MGsnq107b2FrE=
X-Talos-CUID: 9a23:DZBaEWCnBEYjFUv6EwRfymAaE98OSz7AzCjCP1SJJE9bC7LAHA==
X-Talos-MUID: 9a23:qg9siAgma/BuFRT0ZpUZHsMpacAxu6KiDns0oboBn/m0GWsoOT69g2Hi
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2024 22:47:47 +0000
Received: from alln-opgw-1.cisco.com (alln-opgw-1.cisco.com [173.37.147.229]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 494MllBl029381 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 4 Oct 2024 22:47:47 GMT
X-CSE-ConnectionGUID: 0MtvgDVCQT6LqfmzjKU/Iw==
X-CSE-MsgGUID: 6L/SirMXQTCXdIC8dFHgUg==
Authentication-Results: alln-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com
X-IronPort-AV: E=Sophos;i="6.11,178,1725321600"; d="scan'208,217";a="38822352"
Received: from mail-co1nam11lp2171.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) ([104.47.56.171]) by alln-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Oct 2024 22:47:46 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=DIukjHMWyjKDFUinJP/Ew4jQfC0YcLUlcniMIZmxCfyz2Ws/WocfAhvnJ3OY61G5/uoerzgJkQk3RDlCskQRdkgfunTAjrdMBPaWPveX2RFWLdGiEciMLONzo7R4+7+8/+SVYPsuMQgAANjPNryCFeoieyjdJLhUwDptz+IWYheagWSM2VyVGuLtU4yyHYw5lz1xgwX8xjLRsPCQe9/gp57ZHBBcah+6KKCaWuL/H9zgnTfz7mBR+OqySREIAWYiXYq/WPlmivlGpf4Z49PqRJXe9J3ogsLu7emC3lsvOnv+gCngstSTWLLPNFO9BruPNteSCjp/LLSaJjjMdHyRUg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=qHWWpujavteZ3ybSOKgzxcb0moLnBiiLoeTJe3rjVgI=; b=H1efXYhLWt4juOkEG+qaKLzygVapqBif+U+3aqzt56dAe7qHlqtoD8cX0rKYmoIBdjbb1/USf30iL9sz/2rwuyKdjwNE9vNydJAEn4m0OERUkIg1dfReoj8Bd/Qb7GKVpfaMOqYnG3HsHLn5i0AB0w5QZ0M9iFrmC6G2erSdF8OvtjlgFdkxdnwI21GVnt7BuDNrbhAljoCJskIMYtFtHFG4wEzHlFPmFbkzzMawz/49IdI0L3/Py3BJvvxrwqbLsNrC4NTSX16yqoFUZKHOI43ijC1ggl+pC4r1jEO7yeVYgVmVpQBDwsATm9yTUE90TWPCqa7C2XQnru+L76eqBw==
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
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by PH7PR11MB7571.namprd11.prod.outlook.com (2603:10b6:510:27e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.18; Fri, 4 Oct 2024 22:47:43 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::fe26:42d8:b3ff:c2c7]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::fe26:42d8:b3ff:c2c7%7]) with mapi id 15.20.8026.017; Fri, 4 Oct 2024 22:47:43 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>, "draft-ietf-bier-tether@ietf.org" <draft-ietf-bier-tether@ietf.org>
Thread-Topic: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05
Thread-Index: AdqKcZP33ZkxqkMKTF28yyE8RAQqqAYqrmLQGz2LuKAA6MKoAABQz4lAAAayEWAAY6EnIAACqb9g
Date: Fri, 04 Oct 2024 22:47:43 +0000
Message-ID: <BY5PR11MB4337E8A35B9BFCFC79EFA5B8C1722@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <AS1PR07MB8589A23805E5B18D7560762DE0072@AS1PR07MB8589.eurprd07.prod.outlook.com> <IA1PR05MB95508B3A4531CACDA306CEC9D4ED2@IA1PR05MB9550.namprd05.prod.outlook.com> <IA1PR05MB9550340958309915A21A142ED46A2@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB4337DBE84B3896A90FEBE94DC1772@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB95509CB6351AFDB98DA9F830D4702@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB4337C4B4F111426399B04E05C1702@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB955027DF3A50BAFB7C77221FD4722@IA1PR05MB9550.namprd05.prod.outlook.com>
In-Reply-To: <IA1PR05MB955027DF3A50BAFB7C77221FD4722@IA1PR05MB9550.namprd05.prod.outlook.com>
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_ActionId=63128975-ff0a-4536-bd87-004c2199705a;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2024-05-10T20:54:51Z;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY5PR11MB4337:EE_|PH7PR11MB7571:EE_
x-ms-office365-filtering-correlation-id: 3864a13d-b3ae-413f-22ec-08dce4c68f35
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018;
x-microsoft-antispam-message-info: D012TSIiqxKhrkW9Hz8/82zXXSMhAyhJJW7kEKqHSVRFpKCw4H7Gs1Z29S+zsunvWps5Ahp9ikZ43z5DXLE3dN456+bvIfKKJu/Z2jXcBzxBVjW9nvJKVCjrQd8g3tNeS7M2WROn9h+lQflpxBEPiQ15GBfxttQOZutI1CWpyYylvTMcnIjQzyl4bzguJ5JmJM8E3DjugKES9JvnNP0juILQniEUZKVaJyHCLXnpkxNp93JA8YAMCviUjRbf/5MaTXfde0uUQBC0nU25SL/OX/J33gh0cj5zoDFZp4xz4I4MCjhBa15GuQfJNFhtl3jjqH5I1W4i46DhrNe/XDNCTINAcFlPHBkTbW8q9SQpnwiaXMA8WO5zuKXgD3N11WsTkZzLqN4axMSY2Rebb9MCqrCCOH3ATVdArwp8nbPW5TApfk0UlVF0p+5/3heTE6QruNbeagm/K6DVw/gcXnoQaD6TGDzPeptDtLnpah3U8VfqlBj1aT4n0D6BDqd9f/lrv+ov0h67+edGhD3rNj9bcKFMwRYVcJU1hapJ/JpD642RCV2gN5hL5+2KOnGcHeO9BSiyDmG4rUkJ5E1JMGR0wWS4i+OF02arStapbBh/xrn7Nz3w6kcWuXJXY3Z0Xu4yQWqF1X5x8CHgPFVh/5bUR2kR8j5ojz/fdBXeEwOdVmbslZ7RnJKlDGaTUKoXS3VBQ4nh5RGI1VpSpYkN+MpkhGGBFrCHU4mT5hvpqfn6DmlbTzTo10wt55Xufb0KvW3odYG7X08+pqALGObPK0iNLxuSrUFhm2JezyIBqZGtcTceqmgVFUCYzpSLodESHp8wOhs6DbAWvdVG0t0HdK7xeRaXx0EKXCZ7jOZ/lYXPBi08FyC91VJvjXuGCoxWRfbeMnPTw1biJsyWDJR2lVtERHOoBW8KnuXJeAUOUWTupmip94UQBUHyN2g3jHp+dtdybsBGxJ+eja3fRxZoYgtnGJaNGzPurswA09rlK0HDdXNJjSYT4WbpnBIvNywQPKR72Nvn2ei8ZgAwW+CM7PU7bEAZgHtK3J4aWqLtoWWdrcv8cIl5BRTWfOwD3jkIkR3HWJzt7l7sNX/QqL/QH2tjH261x2evHWIQ4SN+OsWZzflZjIwuFA4lad0Zo3Hu7d12iwx1M/Cw1/MMpg7Enk+7DXUfUFEXgmsmltWuCXMWpab18aQC/F+9EjQSqjd+5u2dtkUElTvKYlp3Xp2RHPFujVPwRPFMCux8iBfKqKmOv3l3QVpKgNVn8sroK5ZW1daZM6NGRbzxKRA4kz9lIOREBLwi6d0wAvhIGcYGIIxLmtLeK7hp6md+Fg5Nyqu3/IOHEZEX/G3ITEQA/LLl0025Cg==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BY5PR11MB4337.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: lBgDJpNk1LWw0J/8SK1ycHiDnF2puAcZjHZ7VYKFxbhqlt2sCvw+9QUPZpZqDONHGECJwVaMd3qWspFdJAfnA4aaBaw+9jCI9iNV2WiraaY1j55ccJZGEPhU4o9wkEyiFFBdjjGyS4IvKU2ab0mRc9jXOxqf87GO9fFjYuEeFulfTp3dWbaLcTuInsTM8BBwHdmNQOK2MXVqg5xuEUnA4QCof/LslBeBrd/T5xhR9dfwqdm6RW9k5soA/GZ3QoSUfvK+/9zIhuRGRBQxyflfz1z+wuHqgG7mYUsrImD8O6WiJUGBHh++oAsdf+/lw7U8sxJVnGYufdzm5ItS+KrZkb4JY/AW25fBm7E337EILG7854DK++U2kDF10lEOH8Iq4WF90dN2dD0RPbg1QYQ+cYFw5fmLb4XKzxwH337jlo6BQycm/i67EZYeDkpX7KWhZn2ec55Q1MrgUk0gCZAJM3uVzCwGtbCGOLHRy84yKseuP0Uk262K21P7juUygeZqS8ifn/nxsudtLg1GRaXjOAJX8f/iurs6Cj7LM4vAicXVpbdC+eqY9di0eWUB8ABdkLh79q29Wf2piC6XfGUmnlcd/0H9d1pojaKpG8yPm2jwZQZTXB7301tx/HJAqbUtJUopVDJA+rL9s9vjqqQpUkk/WDXKTUMLWnTMd1gI/30B3BaAhuF+BQZ6uvAKaF2w/KOE8ehEaJMtEwpofokkfALOZJ0GOkQlK+SYxX871y9BHq7jOMihCe5BjdtCRcGMFrsU17uOnO0L1zNLLHEu73+HVKWaYCBJ6HqrX3MpD/21fZSu48tekfGHl2wDOfPly0rOhjxYtsPPzPVRgHB3uTvqhs+wd6tshNRu3SVP2lnGjbSL9ArrMG7Zixt3iIEhqjRVeKgw95fWUspB9d9zL4U2Ih8L66z4hRH46N73mxzUT0S1L9DVIpBJ6vMutmxMzZKRHOF+/scO+mIgzcBzZrpx94GpxKy8KDFYk15ncVJVMdL7lrnKJBlp9RXc1q9fZhzSB+z4uXIgB+yh8Y22mStFJWDesPfzJgYx5cyhup58AgGMPnNtbWuJterBZSBEVd7XottodsQ1sr78zn/FNVrMJiZS3RV1E/Qir18PWIbVy7TTZAvL0wMgjIYI9STJJDVsopj2hLGqlZbteBDosdD0XjUEzV2DMLNuMrMrEdh1C2ldWEFh6kNueVIS5Yy2ymxIt5FEMfYTT16F76ucOb5gjBxQt2gkbtvHup1fDco3T6vE6tGvYF5hKcL2khV2XPZH4Ji60seNiljQFAkAKP+uaYZgOT/WxbZMxlwWSXKkx1b1a7IbwRJyGnmM3aYabA0V7RsJNFYor4NaiC2DHJWcTuv0mB+CQxTe2sdR/En9aN07ddmNmHa9STzgHn1Jd80CfjY5G297seoKE2mWW+6esjsODgdR1CLKL905aBiVO5rnjbRprQ690vYS8NU6jHn0x2gypOkJzxLYPWq5CBh9v15I6UuwcHNMiA2Zuo37A6TN5YoflM0jE8t9t8jFXgO1ml78jcOIdEyBbxi16+HNGp5pmuCirD0lY/fXCv0jp+OvKHEZaMnLLxLpc1vZ
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337E8A35B9BFCFC79EFA5B8C1722BY5PR11MB4337namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3864a13d-b3ae-413f-22ec-08dce4c68f35
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2024 22:47:43.6996 (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: bVG8331R9arxOc2z24oYQyKtlOwIHRSiDG0vQ/tH8dm2jrsSbcPxqb0C60uYk5ZxMoR9K56uE+O/jsi/gvrqMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB7571
X-Outbound-SMTP-Client: 173.37.147.229, alln-opgw-1.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Message-ID-Hash: 2NJHEUGZOXXQTEQ6LSLFAQ6IBZELOPLW
X-Message-ID-Hash: 2NJHEUGZOXXQTEQ6LSLFAQ6IBZELOPLW
X-MailFrom: ginsberg@cisco.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bier.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: BIER WG <bier@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [Bier] Re: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/7Hl4vOXCrh0IGJkKUH8WogM5-2Y>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Owner: <mailto:bier-owner@ietf.org>
List-Post: <mailto:bier@ietf.org>
List-Subscribe: <mailto:bier-join@ietf.org>
List-Unsubscribe: <mailto:bier-leave@ietf.org>
Jeffrey – Top posting… First, there are some issues with the availability of the document. 1)It isn’t visible on the BIER WG Documents page 2)Neither the HTML nor the diff URLs provided in the announcement message for V7 work: https://datatracker.ietf.org/doc/html/draft-ietf-bier-tether-07 https://author-tools.ietf.org/iddiff?url2=draft-ietf-bier-tether-07 This may be because neither the HTML nor the TXT files are available from the Datatracker page. Hopefully you or the WG chairs can straighten this out. As far as the ECMP discussion, I think we are not understanding each other. The changes you have made in that section don’t address my concerns. I am asking how an operator would decide that they prefer to use a single helper vs ECMP helpers? Don’t tell me that is based on priority – that’s a circular argument. 😊 If we use the example of OSPF Designated Router, typically the operator doesn’t care who becomes DR. And this is easy to achieve because the preference logic guarantees a single winner even if the operator uses a default priority for all routers. Here, you require an operator to actively manage the priorities of the helpers even when ECMP is not desired. Maybe you have a good reason for this (i.e., you think ECMP should be preferred by default) – but nothing in the draft suggests why that should (or should not) be the case. Apologies for belaboring a small issue – just wanted to make one more attempt to at least reach a common understanding. Thanx. Les From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> Sent: Friday, October 4, 2024 2:30 PM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com>; draft-ietf-bier-tether@ietf.org Cc: BIER WG <bier@ietf.org> Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 Hi Les, Please see zzh> below. I have posted the -07 revision. Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Sent: Wednesday, October 2, 2024 5:51 PM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 [External Email. Be cautious of content] (BTW, is there a reason why this draft does not appear on the WG Documents page??? https://datatracker.ietf.org/wg/bier/documents/<https://urldefense.com/v3/__https:/datatracker.ietf.org/wg/bier/documents/__;!!NEt6yMaO-gk!HjREalKmNQ2Ao7PVrowxL0y2p12uHXYmTo8s9fmMp5QuqAtiqNTr6zOD-09GyEEuAmecmrp2mYQ59DDV$> ) Jeffrey – Thanx for the response and the kind words. One additional(not urgent) comment from me. As regards ECMP, what I find strange is the inconsistency between the equal priority cases and the unequal priority cases. As there is no guidance as to how the helper would choose a priority value, I am left to wonder how a node would make the choice between advertising a high priority (and thereby make it likely that ECMP would NOT be used) versus advertising some arbitrary value which might be likely to be the same on all routers. Is there some advantage in your mind to using/not using ECMP? Zzh> It is just like using or not using ECMP in regular routing – there are pros and cons and a router may choose to make use all the ECMP paths or just some of them. Zzh> I noticed that I already have the following text in Section 3: .. To allow multiple helpers to help the same non-BFR, the "I am X's helper" advertisement carries a priority. BFR1 will choose the helper advertising the highest priority among those satisfying the loop-free condition described above. When there are multiple helpers advertising the same priority and satisfying the loop-free condition, any one or multiple ones could be used solely at the discretion of BFR1. Zzh> I also updated relevant text in Section 4.1: If there are multiple helpers advertising the same highest priority, ECMP through some or all of those equal-priority helpers MAY be used. Alternatively, any one of them MAY be used. Zzh> For the priority consideration, the red text above should provide a clue, but now I have added the following to the operational consideration section: In the case of using multiple helpers for one helped node, the helpers may be provisioned with the same or different priorities, depending on which one should be preferred. Your analogy to routing isn’t fully appropriate. IN case of routing, there is a metric value (based on some link attribute such as bandwidth) which determines the preference. Here, there is nothing equivalent. Zzh> To me, the priority is equivalent to the metric 😊 I’d like to see more determinism here. Zzh> The priority is the first order, and then one can use ECMP or not – just like in the unicast routing case, the metric is the first order and then ECMP (through some or all paths) may or may not be used. Zzh> Thanks. Zzh> Jeffrey Les Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> Sent: Wednesday, October 2, 2024 11:43 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 Hi Les, Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Sent: Tuesday, October 1, 2024 12:06 AM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 [External Email. Be cautious of content] Jeffrey – Thanx for he updated version. In regards to Section 4.1 IGP Signaling, you have addressed my comments – but I note that you say: “When there are more than one helper nodes for a helped non-BFR node, the helper advertising a higher priority MUST be preferred. If there are multiple helpers advertising the same priority, ECMP through those equal-priority helpers MAY be used.” In the equal priority case, ECMP is one way of handling this – but I find it logically inconsistent with how you handle the different priority case – where you require ONLY the higher priority helpers to be used. A more consistent approach would be to use the system id/router id as a tiebreaker – where typically the higher value is preferred. Zzh> If two have the same highest priority, either ECMP through both or pick one based on a tie-breaker or just pick a random one can all be practical approaches. The draft chooses ECMP but that does not conflict with using the highest priority one – just like in the normal routing case you always pick the best path but when you have equally best paths you can do ECMP or just pick one. Zzh> I will add the option of using one of the helpers. As you provide no guidance as to how the helper assigns a priority value, it seems likely that equal priority case would be the most common result – which means most of the time ECMP would be used. Is this really what you want? I have previously expressed concern as to whether this functionality has been implemented. That concern was also expressed by Adrian. Is there any implementation experience? If not, I repeat my concern – I do not understand why the document needs to go forward before implementation experience is gained. That decision is, of course, up to the WG. Zzh> As of now there is no implementation. I can wait since it is obviously a concern, but I am glad that we went through the process – in which I got good suggestions from experts like you. Zzh> Thanks. Zzh> Jeffrey Les Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> Sent: Thursday, September 26, 2024 5:54 AM To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>; Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 Hi Gunter, I realized that I had not posted the revision that I shared back in May. I also realized that I completely missed Adrian’s review. Sorry for dropping the ball. I have posted the -06 revision that I believe addressed all the issues. Thanks. Jeffrey Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang Sent: Wednesday, May 15, 2024 10:56 PM To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>; 'Les Ginsberg (ginsberg)' <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: RE: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 Hi Gunter, Thanks for your thorough review and detailed report. It took me a while to catch up all the work that piled up after some business/vacation travel since IETF119 – pardon my late response. Please see zzh> below and the attached diff/draft (not posted yet). I will reply to Les separately and copy you on some points mentioned below. From: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com>> Sent: Tuesday, April 9, 2024 7:32 AM To: draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 [External Email. Be cautious of content] # Gunter Van de Velde, RTG AD, comments for draft-ietf-bier-tether-05 In the absence of an earlier shepherding AD review pertaining to the draft-ietf-bier-tether document, please find my review comments for discussion. These comments are shared prior to the document being considered for IESG Telechat. In reviewing this document, I start with a broad overview of its current status, followed by a detailed discussion of critical technical points. I conclude with an analysis performed by idnits, which includes annotations for both [minor] and [major] comments. This structured approach helps to ensure that all aspects of the document are thoroughly examined and addressed. Summary: ======== The abstract of this document reads: This document specifies optional procedures to optimize the handling of Bit Index Explicit Replication (BIER) incapable routers, by attaching (tethering) a BIER router to a BIER incapable router. The document is not overly long and appears not overly complex. However the document reads relative light on formal specification. Additional strict formal usage using BCP14 language to prescribing operations, the code points and the spf modification will provide better specification. The shepherd writeup (4 July 2022) suggest document shepherd reviewed draft-ietf-bier-tether-01. Implementations: no existing and known future Implementations. idnits: no substantial issues shown Looking at the email archive, only very few discussions about this document happened on the list Many thanks to Dan Romascanu (OPSDIR), Wes Hardaker (SECDIR) and Joel Halpern (GENART) reviews. I encourage the document authors to consider the feedbacks and observations provided. Key Technical Issues: ===================== Due to no existing or known future implementations would experimental not be more appropriate IETF track then "proposed standard"? Zzh> Lack of existing implementations should not lead to the experimental track. Zzh> BIER deployment has been hindered by the chicken-and-egg problem: the requirement of new or programmable ASIC (at least for important replication points) causes operators to back off their demand, which in turn throttles back vendor’s implementation pace. Zzh> Nonetheless vendors and the BIER WG have continued their investment in this multicast technology breakthrough (which sticks to the #1 principle of Segment Routing), and its prime time is actually coming (BIER hardware and software implementations from multiple major vendors have demonstrated interoperability). Zzh> With that, more and more BIER features including brownfield deployment features like this one, will be implemented and they will further help the deployment of BIER. I can say confidently that there will be future implementations coming. The comments on the email list from Les about encodings has significant impact: https://mailarchive.ietf.org/arch/msg/last-call/tUy5jdA2z62BmvpP-TC-_k-rIws/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/last-call/tUy5jdA2z62BmvpP-TC-_k-rIws/__;!!NEt6yMaO-gk!BbtrDwXln23VzkcWBkS5a12kcq45c_jKug1tMCeg_PLOurdSu6ZeoxMbXKqapvG-rzShdsEHz3R9luw8rOjhZwuDrhc$> In general there is ongoing effort to be conservative about any IGP encoding, however especially with ISIS are TLV resources often constrained. Zzh> I acknowledge that Les has a good point in the encoding efficiency. However, one helper helping multiple non-BFRs should not be common so the problem is not too bad. Still, I can fix that per Les’ suggestion. Zzh> BTW, sometimes it takes formal LCs/reviews to get critical reviews like Les’ and yours, but I am confident that the solution is sound (it follows the same TI-LFA principles). IANA code points: why are early code points not considered? It would help to grow experience with the solution before requesting final code point allocations. It seems especially when encoding descriptions seem not fully firm at the moment. Zzh> That’s probably because there are no implementations yet. Operational guidelines: light specification details about troubleshooting and network behaviour due to diverged paths between multicast and unicast. For example, what is the impact on ping/traceroute and other multicast operational tools, convergence impact expectations? What addresses should be used as the helped address? is it possible that unicast SPF has race condition with the BIER topology SPF? etc. if BGP is used, any risks for the recursive lookups to go wrong? Zzh> BIER ping/traceroute will follow BIER paths – independent of unicast ping/traceroute. I did not think of discussing this, and an operator who deploys tether should not be surprised to see BIER ping/traceroute taking a different path. Traditional multicast ping/traceroute is (s,g)-based at the flow overlay and not applicable here. Zzh> More about some other points above in the responses below. Security implications: As indicated in the security directorate review it would help the document to add proof points why there are no additional security concerns compared to BIER architecture and OSPF/ISIS/BGP extensions for BIER signaling. (it is for example possible to insert the TLV on a rogue node and add all loopback addresses of the router in the area) zzh> I can add that; but if there is a rogue node, it can do all kinds of damages, right? Other than preventing rogue nodes, what protection do we have? What is the impact of technologies as LFA/BFD/ECMP impact BIER Tether topology? Zzh> BFD/ECMP are agnostic here. BIER Tether is essentially doing TI-LFA for BIER packets as stated in the document: … In fact, BFR1 tunneling packets to X's helper is not different from sending packets to a LFA backup. Please find in next section a set of review comments [minor] and [major] Detailed review using the idnits rendering of the draft: ======================================================== 17 This document specifies optional procedures to optimize the handling 18 of Bit Index Explicit Replication (BIER) incapable routers, by 19 attaching (tethering) a BIER router to a BIER incapable router. [major] this is incorrect. The draft specifies in addition to operational procedures a few IGP TLVs (code points and IGP encodings). Zzh> You’re right; fixed. 76 Consider the scenario in Figure 1 where router X does not support 77 BIER. [minor] It will be more clear if it is more explicit that this paragraph is the explanation of the observed problem space. A few paragraphs later the term solution is used. For readability it woul de nice to first get description of the problem space, followed by the naturally by the solutin discussion. Zzh> That’s exactly how the paragraphs are structured. The first two paragraphs point out the problem (inefficiency if BFR1 tunnels to BFR2/3/4/n directly), and the third paragraph (starting with “A solution”) describes a better solution (“tethering”). 94 A solution to the inefficient tunneling from BFRs is to attach 95 (tether) a BFRx to X as depicted in Figure 2: [major] The wording "A solution" implies that there are other solutions to the problem possible. However, these are not discussed in the document. Zzh> There may be other solutions but I am not aware of one. Even if there were, they are outside the scope of this document, and I thought starting with “A solution” would be fine. In the email archives there have been comments questioning why draft-ietf-bier-tether solution is better as placing for example a BIER router in the forwarding path close to the helped BFR? The 'why' is tethering better as the other solutions is unclear and undocumented. Zzh> The three paragraphs after Figure 2 are there to explain why tethering is the better solution: instead of BFR1 tunneling many copies to BFR2..n, it tunnels one copy to BFX which is local to X with a fat pipe. 111 For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to 112 be announced in Interior Gateway Protocol (IGP) as a forwarding 113 adjacency so that BFRx will appear on the Shortest Path First (SPF) 114 tree. This needs to happen in a BIER specific topology so that 115 unicast traffic would not be tunneled to BFRx. Obviously this is 116 operationally cumbersome. [minor] an alternative is to place the BFRx into the IGP forwarding path? Is the multicast traffoc expected of lesser valume as the unicast traffic? Maybe the unicast traffic volume can be neglected compared to the multicast traffic? Zzh> In the Figure 2, BFR2 is inline between BFR1 and BFER2, BFR3 is inline between BFR1 and BFER3, and so on so forth. But as the 2nd paragraph in section 1 explained, that would require BFR1 to tunnel three copies through X, which may not be good (the BFR1-X link could be limited/expensive). In this case, tethering a BFFx to X with a local fat pipe helps. You can think of BFRx being a BIER line card on X but they are actually separate nodes with separate control planes. Zzh> It could be that router X cannot be replaced for some reasons, and the accumulative tunneled BIER traffic through the BFR1-X link is not acceptable, so tethering a small BFR to X is a good alternative here. 118 Section 6.9 of BIER architecture specification [RFC8279] describes a 119 method that tunnels BIER packets through incapable routers without 120 the need to announce tunnels. However that does not work here, 121 because BFRx will not appear on the SPF tree of BFR1. [minor] style rewrite: "Section 6.9 of the BIER architecture specification [RFC8279] delineates a methodology for tunneling BIER packets through incapable routers without the need to explicitely announce tunnels. Nonetheless, this method is inapplicable in the current context, as BFRx is not a node in the SPF tree rooted at BFR1. Zzh> Done. 123 There is a simple solution to the problem though. BFRx could 124 advertise that it is X's helper and other BFRs will use BFRx (instead 125 of X's children on the SPF tree) to replace X during its post-SPF 126 processing as described in section 6.9 of BIER architecture 127 specification [RFC8279]. [major] simple is subjective language. The need for code points, IGP signalling, usage of multicast only router (=unicast stealth router) and topological BIFT abstraction is not that simple. This section is an opportunity to present and defend that the tether solution is the most optimal solution for the presented use-case. Zzh> When the out-of-path BFRx is desired to help the BIER-incapable X, the only alternative way to get it to work is advertise BFR1-BRFx Forwarding Adjacency *for multicast purposes only*. That is explained in the following paragraph: For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to be announced in Interior Gateway Protocol (IGP) as a forwarding adjacency so that BFRx will appear on the Shortest Path First (SPF) tree. This needs to happen in a BIER specific topology so that unicast traffic would not be tunneled to BFRx. Obviously this is operationally cumbersome. Zzh> The tethering solution simplifies that. 131 While the example shows a local connection between BFRx and X, it 132 does not have to be like that. As long as packets can arrive at BFRx 133 without requiring X to do BIER forwarding, it should work. [minor] what example is being referenced. From a style perspective it is unclear what 'should work' means in a proposed standard document. Maybe more formal writing is appropriate? Does "should work" mean it behaves as architected or does not behave as architected. What are the conditions it would not work as intended? Zzh> The example in Figure 1. I updated it to “The scenario in Figure 1”. Zzh> I meant the tethering concept/mechanism/solution works. Please see if the new text is fine. 129 2. Additional Considerations [minor] this is odd titled section. The section title is "Additional Considerations", but there is no section about "Considerations"? Zzh> The previous section “considers” the simple scenario 😊 It was implicit “considerations” and this section considers more scenarios. 135 Additionally, the helper BRFx can be a transit helper, i.e., it has [minor] s/BRFx/BFRx/ Zzh> Fixed. 137 connected to X), as long as BFRx won't send BIER packets tunneled to 138 it back towards the tunnel ingress. Figure 3 below is a simple case: [minor] a use-case or a network topology? a little more context helps readability on how expected multicast flows wil be steered through the topology. How would this impact security and operational implications? Zzh> I changed it to “example topology” and added a short paragraph after the figure. Please see the new text below. Additionally, the helper BFRx can be a transit helper, i.e., it has other connections (instead of being a stub helper that is only connected to X), as long as BFRx won't send BIER packets tunneled to it back towards the tunnel ingress. Figure 3 below is an example topology: ------ BFR2 ------- BFER2 / BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 | | BFRx ------ BFR4 ------- BFER4 \ ------ BFR5 ------- BFER5 Figure 3: A Safe Transit Helper BFR1 will tunnel one copy to BFRx, who will tunnel to BFR2/BFR3 and send natively to BFR4/BFR5 respectively. Zzh> BTW, here BFRx is an inline helper of X wrt BFR4/5 but not wrt BFR2/3. Zzh> There should be no security/operational impact. 151 In the example of Figure 4, there is a connection between BFR1 and 152 BFRx. If the link metrics are all 1 on the three sides of 153 BFR1-X-BFRx triangle, loop won't happen but if the BFRx-X metric is 3 154 while other two sides of the triangle has metric 1 then BFRx will 155 send BIER packets tunneled to it from BFR1 back to BFR1, causing a 156 loop. [major] This description truely provides an indication that when tether is used, that there is divergence between unicast and multicast topologies. How would LFA and other fast convergence race conditions impact during instabity? Zzh> When there are BIER incapable routers in the network and you don’t want to tunnel to their downstream BFRs directly, divergence is unavoidable. Zzh> There is no race condition here – the BIER route calculation is an additional step after the unicast route calculation. 174 Notice that this SPF calculation on BFR1 with BFRx as the root is not [minor] unsure what "this spf" referes towards. more formal language will help to understand the example better Zzh> It refers to the SPF mentioned in the short paragraph immediately preceding this sentence. 174 Notice that this SPF calculation on BFR1 with BFRx as the root is not 175 different from the SPF done for a neighbor as part of Loop-Free 176 Alternate (LFA) calculation. In fact, BFR1 tunneling packets to X's 177 helper is not different from sending packets to a LFA backup. [minor] What is the point that is being proved with the comparison to LFA style SPF calculation? Zzh> The point is that the SPF (rooted at BFRx) will avoid loops, and that is the same way how LFA avoids loops. Zzh> I changed the last sentence slightly to be more specific. 176 … BFR1 tunneling BIER packets to X's 177 helper BFRx is like tunneling unicast packets to an LFA backup. 179 Also notice that, instead of a dedicated helper BFRx, any one or 180 multiple ones of BFR2..N can also be the helper (as long as the [minor] upper or lower case n vs N? seems that there is disreptency between diagram and text zzh> Fixed. 185 highest priority among those satisfying the loop-free condition 186 described above. When there are multiple helpers advertising the 187 same priority and satisfying the loop-free condition, any one or 188 multiple ones could be used solely at the discretion of BFR1. [major] The node BFR1 silently implies that it is the upstream node of the BIER uncapable router (the helped node). This is nowhere defined or specified. Zzh> I now clarified it as the very beginning of the document. 192 The situation in Figure 5 where a helper BFRxy helps two different 193 non-BFRs X and Y also works. It's just a special situation of a 194 transit helper. [minor] what does "also works" exactly mean? formal description of the outcome will helps Zzh> I mean the mechanism works for the situation where a single helper helps two different non-BFRs. I updated the text. 192 The situation in Figure 5 where a helper BFRxy helps two different 193 non-BFRs X and Y also works. It's just a special situation of a 194 transit helper. [minor] THis is becoming very complex and no longer simple. What are the operational implications and how to troubleshoot this now that unicast and multicast topology are looking vastly different. Zzh> It’s actually not complicated – it is nothing special compared to the base case and does not need additional/special code to handle it. Zzh> After BFR1 finishes the SPF calculation, it finds that the two children X and Y do not support BIER and they have a helper BFRxy. It first replaces X with BFRxy on the SPF tree. Then it replaces Y with BFRxy (which is already on the tree) – the replacement of Y with BFRxy is no different from replacing it with different helper. 214 The procedures in this document apply when a BFRx is tethered to a 215 BIER incapable router X as X's helper for BIER forwarding. [minor] It would help to formally give the BIER incapable router a name to refer to from documentation perspective. Zzh> X is the name 😊 I could change it to R1, but I don’t see a difference between X and R1, and I’d need to use BFRr1 or BFR_R1 to indicate its helper which is not as clean. 219 Suppose that the BIER domain uses BIER signaling extensions to ISIS 220 [RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise 221 one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in 222 the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in 223 the case of OSPF, one for each helped node: [minor] s/suppose/when/ Zzh> “Suppose” seems to be better? I see it is used in extensively in other documents. I can change it to “Consider”. “When” does not read well here. [major] referencing to the comments from Les. Zzh> I will reply separately to Les and copy you. In addition, having explicit sections for ISIS and OSPF and OSPFv3 will be beter to formalize and document the code-points and associated TLV descriptions. Zzh> The BIER Helped Node sub-TLV format is identical for ISIS/OSPF/OSPFv3. In my view, it is better to just do it once instead of repeating three times. [minor] no figure number is provided? Zzh> Fixed. 225 0 1 2 3 226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | Priority | Reserved | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Address of the Helped Node | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [major] WHat is this address of the helped node? is that a interface address? is that a loopback? is it a router id? does it have to be a stable address? does the address have to exists on the router? must the address be UP and ENABLED and PINGABLE on the router? What if multiple helped node addresses are added all over the network (for an attach for example)? Zzh> A routable address or router/system-id on the helped node. There are some details involving IPv4/IPv6 and ISIS system-ID. Let me check with Les (I’ll copy you). 243 At step 2, the removed node is added to an ordered list maintained 244 with each child that replaces the node. If the removed node already 245 has a non-empty list maintained with itself, add the removed node to 246 the tail of the list and copy the list to each child. [major] The text at section 6.9 is written formally. if the intent is to change the step 2 with alternate logic prescribing when and how to insert the BIER helper node. Most correct would be to rewrite using formal BCP14 language the complete 'step 2' for the tether use case. (RFC8279 section6.9) 2. If one of the child nodes does not support BIER, BFR-B removes that node from the tree. The child nodes of the node that has just been removed are then re-parented on the tree, so that BFR-B now becomes their parent. Zzh> Please see if the new text is fine. 268 If the above procedure finishes without finding any helper, then the 269 original BFR next hop via a tunnel is used to reach the BFER. [minor] Is this statement also not part of the process that tether modifies the BIER-SPF? Zzh> Please see the new text. 273 Suppose that the BIER domain uses BGP signaling 274 [I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises [minor] s/suppose/when/ Zzh> Please see earlier response. 271 3.2. BGP Signaling [major] Can BGP signaling not be seen as another ecoding in addition to the IGP encodings? Zzh> No “helped node” signaling is used. Please see updated text. 273 Suppose that the BIER domain uses BGP signaling 274 [I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises 275 BIER prefixes that are reachable through them, with BIER Path 276 Attributes (BPA) attached. There are three situations regarding X's 277 involvement: [minor] what does "them" reference? Zzh> It refers to BFR1..n. I changed “advertises” to “advertise”. [minor] not sure what the BIER prefix is. Is that a special NLRI used for signalling BIER BitString? [minor] three situations are mentioned, but only 2 follow? Zzh> I changed them to BFR-Prefix (a term in RFC8279), and expanded the terminology section. Zzh> Changed “three” to “two”. 286 To make tethering work well with BGP signalling, the following can be 287 done: [major] what does "work well" mean? please explain using BCP14 langue how the technology and encodings will work. Zzh> Please see the new text. [minor] is there any impact upon how the BIER-SPF is modified using the received BGP derived BIER information. Zzh> There is no SPF here. It’s BGP and relies on each hop to update BPA. [major] are there no BGP code points or encodings specified? Zzh> There is no need. I updated the procedures to make it clearer. Zzh> Thanks! Zzh> Jeffrey
- [Bier] [draft-ietf-bier-tether] Shepherding AD do… Gunter van de Velde (Nokia)
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Jeffrey (Zhaohui) Zhang
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Jeffrey (Zhaohui) Zhang
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Les Ginsberg (ginsberg)
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Jeffrey (Zhaohui) Zhang
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Les Ginsberg (ginsberg)
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Jeffrey (Zhaohui) Zhang
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Les Ginsberg (ginsberg)
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Jeffrey (Zhaohui) Zhang
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Les Ginsberg (ginsberg)
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Tony Przygienda
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Gunter van de Velde (Nokia)
- [Bier] Re: [draft-ietf-bier-tether] Shepherding A… Gunter van de Velde (Nokia)