[Bier] Re: Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 23 May 2024 17:45 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 06046C151710; Thu, 23 May 2024 10:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.474
X-Spam-Level:
X-Spam-Status: No, score=-14.474 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=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=unavailable 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 zawsgNLNhabf; Thu, 23 May 2024 10:45:27 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (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 2D435C14F691; Thu, 23 May 2024 10:45:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=104808; q=dns/txt; s=iport; t=1716486327; x=1717695927; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RNAQed++A+/hnYcFaom1Rik5zYH5xHqAiHTs8Tsd6iI=; b=SwnbRiHzz1FinbJ8LXwtjUaNuAvXLPyyZtii0NSKSDsLg3114YYucu2k cdNnHFHWyWd0IjICd6HMs8gwieVuyItLOZ68y05ieIBSQdnS8XreVEm+P Ct+W4cIvlhTDfjt2AiRhfdRNI4em0RyiA8ALztyynDBGT5qKCTTURkkHo k=;
X-CSE-ConnectionGUID: 8TOFfvUyRgGbXWIKk14mqA==
X-CSE-MsgGUID: M6wh6a1mS8Sqq7VnD8iJcQ==
X-IPAS-Result: A0AgAABAf09mmIgNJK1QChwBAQEBAQEHAQESAQEEBAEBZYEYBQEBCwGBQDFSegKBHEgEhFGDTAOFLYhuA5FDjEcUgREDUQUHCAEBAQ0BAS4BBw4EAQGFBgIWiDACJjYHDgECBAEBAQEDAgMBAQEBAQEBAQYBAQUBAQECAQcFFAEBAQEBAQEBHhkFDhAnhXQNhlkBAQEBAgEBARAIAQgKOwMBAggDBQcEAgEGAhEEAQEhAQIEAwICAiQLFAkIAgQBDQUIEweCXgGCHCUjAwEQlEuPUAGBQAKKKHqBMoEBghgFgU9B22oGgUgBiC0BJIExAgKIYycbgUlEgRQBQoFmgQI+gmEBAQIBgSgBBwsBIxUPBgqDJTqCLwSFCIkBIxWDD0GBGDqCJkd1ghgHARCCFwULgQ2BAVkPWQF0RhRCDoFMgUiHSFR3IgMmMyERAVUTFws+HQIWAxsUBDAPCQsmKgY5AhIMBgYGWTQJBCMDCAQDQgMgcREDBBoECwd1gXGBNAQTR4E3BoltDIF7gQwCBSEEJYFMKYEOFoJ6S2yBHQKCZ4F2DmGDT4EIglB0Y4EQgUeBZB1AAwttPTUGDhsFBIE1BaNaBDeCTAoFCy0uLjwBAw4UBRQIDgIgAjkgHRwYAQ0LGAURAh0LOpJEgzRJiypHjgWTBYF+CoQTjA6HHo44F4QFjH+YTWSYYyCNVpU8CgQYA4UFAgQCBAUCDwEBBoFrATNrcHAVO4IzAQEBMVIZD41/KwMNCRaDQoUUxVh4AgEBNwIEAwEKAQEDCYpoAQE
IronPort-PHdr: A9a23:83e5UxVjsGuFuBD1DQh8hLVszSfV8K02AWYlg6HPw5pHdqClupP6M 1OavLNmjUTCWsPQ7PcXw+bVsqW1QWUb+t7Bq3ENdpVQSgUIwdsbhQ0uAcOJSAX7IffmYjZ8H ZFqX15+9Hb9Ok9QS47lf1OHmnSp9nYJHwnncw98J+D7AInX2su20fu49ofcSw5JnzG6J7h1K Ub+oQDYrMJDmYJ5Me5x0k7Tr3lFcPgeyWJzcFSUmRu9rsvl9594+CMWsPUkn/M=
IronPort-Data: A9a23:vPZFU69p5ya1/2ayIYC+DrUDRn6TJUtcMsCJ2f8bNWPcYEJGY0x3n DYfXDjSP/6MMWLzLdEkPt/i9koFupeAndBhHQRr/i1EQiMRo6IpJzg2wmQcns+2BpeeJK6yx 5xGMrEsFOhtEzmE4E/ra+C9xZVF/fngbqLmD+LZMTxGSwZhSSMw4TpugOdRbrRA2bBVOCvT/ 4uiyyHjEAX9gWIsbzhPs/jrRC5H5ZwehhtJ5jTSWtgT1LPuvyF9JI4SI6i3M0z5TuF8dgJtb 7+epF0R1jqxEyYFUrtJoJ6iGqE5auK60Ty1t5Zjc/PKbi6uCcAF+v1T2PI0MS+7gtgS9jx74 I0lWZeYEW/FMkBQ8QgQe0EwLs1wAUFJ0O/7Blaxr/GC9ULpeUvT4tZtVR0zJKRNr46bAUkWn RAZADkJahbGjOWszffgDOJtnc8kasLsOevzuFk5kmqfVqhgGMuFGv6UjTNb9G9YasRmEvfYf MAUczVHZxXbaBoJMVASYH47tL343CCgLGUG+Dp5o4ISvXfTkgUo1YO9C8PMJeKMaZVUvE2h8 zeuE2PRWUxCa4fFllJp6EmEivXGkz++WY8OGviy9/NwxUGe2mweEjUXWEe15/6jhSaWUdNSM WQV9zYg668o+ySDRNjwRVizoHeFpAU0WtdMHas98g7l4q7d+BrcDWEAShZAZcAo8sgsSlQXO kShltftA3lkt6eYDCnb/baPpjT0Mi8QRYMfWcMaZVs5xPftvrwitB3gROZcMY2214HwABill lhmsxMCr7kUiMcK0YCy8lbGny+gq/D1ougduFy/soWNsFsRWWK1W7FE/2Q3+hqpEWp0ZlCFu H5BkM+E4aVVS5qMjyeKBu4KGdlFBspp0hWC3DaD/LF4q1xBHkJPm6gLvlmSw28yba45lcfBO hO7hO+ozMY70IGWRaF2eZmtLM8h0LLtE9/oPtiNMYMQPsAsKlPXpXs0DaJ144wLuBVz+U3YE crLGftA8V5FYUia5GPvGLdDi+NDKt4WnD6DH/gXMChLIZLFOSbKEu1aWLd/Rus496iD6B7E6 MpSMtDCyhNUFoXDjtr/r+YuwaQxBSFjX/je8pUPHsbae1YOMD96UZf5n+h+E7GJaowIzI8kC FnnBB8BoLc+7FWaQTi3hodLM+20As8j9yJhVcHuVH7xs0UejU+UxP53X7M8fKIs86poyvscc hXPU5/o7ihnItgfxwkgUA==
IronPort-HdrOrdr: A9a23:uJi+a6Ctu8xAbtblHejssseALOsnbusQ8zAXPh9KOH9om52j9/ xGws576fatskduZJhBo7y90KnpewK7yXcH2/hhAV7CZniohILGFvAZ0WKP+UyFJ8S6zJ8j6U 4CSdkxNDSTNykGsS+S2mDReLhQoqjjzEnrv5aj854Hd3ASV0gU1XYDNu/tKDwPeOApP+tfKL OsouB8i36Lf3MRYs6nBn8DcdTiirTw/q7OUFotPTJizBOBow+JxdfBfiRw2C1wbxp/hZMZtU TVmQ3w4auu99uhzAXH6mPV55NK3PP819pqHqW3+4goAwSprjztSJVqWrWEsjxwivqo8kwWnN 7FpAplF9hv6knWYnq+rXLWqkrdOXcVmj3fIG2j8D/eSP/CNXUH4g169MRkmy7img8dVRdHof t2NiyixsJq5Fj77VTADpDzJmJXfwyP0DsfeSp5tQ0EbWPYA4Uh9rD28C5uYeU9NTO/54Y9HO Z0CsbAoP5QbFOBdnjc+nJi2dq2Qx0Ib127q2U5y4SoOgJt7TtE5lpdwNZakmYL9Zo7RZUB7+ PYMr5wnLULSsMNd6pyCOoIXMPyUwX2MF7xGXPXJU6iGLAMOnrLpZKy6LIp5PuycJhNyJcpgp zOXF5RqGZ3cUPzDs+F2oFN73n2MSiAdCWoztsb64lyu7X6SrauOSqfSEo2m8/luPkbCt2zYY f7BHuXOY6UEYLDI/c/4+SlYegmFZA3arxghuoG
X-Talos-CUID: 9a23:FISJ5mxeLlPgLoLEU8hsBgVEJucLfGPg3U3fDEWINkdKS+TJTEa5rfY=
X-Talos-MUID: 9a23:fonR1woaCUDWHC+CPu4ezxQ8K8c26v2rMxA2iIxZhc+oZS1SMA7I2Q==
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 May 2024 17:45:25 +0000
Received: from alln-opgw-1.cisco.com (alln-opgw-1.cisco.com [173.37.147.229]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 44NHjPEX008194 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 23 May 2024 17:45:25 GMT
X-CSE-ConnectionGUID: BzR1+vLRSZeh8pdIMPLi6Q==
X-CSE-MsgGUID: oN5s01dUTmKdZvLBc0E2Hw==
Authentication-Results: alln-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=ginsberg@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.08,183,1712620800"; d="scan'208,217";a="30349203"
Received: from mail-dm6nam10lp2101.outbound.protection.outlook.com (HELO NAM10-DM6-obe.outbound.protection.outlook.com) ([104.47.58.101]) by alln-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 May 2024 17:45:24 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h5n5o37jZgXvn674gVAX5c18HgeprTyK3cHRpB7x+UFkvA+6iF28UbPhu2I/SbeSQa+3GIy+B+uRtZzl5GL6PXz9IhkKboVzUr92rvyfFwbID+Fzjsrvej7XEvTylGrAb5Lll2LKe+oLQ9f1VNX8PHPeApVYgAnVKwqIwprBwnI3MegKSDagcok4hgsGTToQp1xt52bNV4Vuph455UJcEAbn617zogwiktvuCz4momf8t2SgeI5AMp7RD0lxyFULXQeIlZG7Qa7O0w+PKiotJsx3om22N0/DQRcQHYuNx/vvWjppiPvxGKoXHV/7KjeFV+MwT4EMl62DJjdTaIN+kg==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RNAQed++A+/hnYcFaom1Rik5zYH5xHqAiHTs8Tsd6iI=; b=HSRa7oYqj3Q+n7X94jV8ipy+zPSd5PTI3BcQBSGqzbTYSyW+R2PxBO91nPI//czcHzFeXRbLACJif8SlSSqblD2D9AYtL95wbLUMJSAl+Tito2Exz3Gx+oA9OLSA51Tqvaql4PvFwHBjZm/IYymI63aBrT1Bprn4FiU7G38z6FA0KbIRL1xbeYxOze1xxwpdCOxF5NWxvg4OGXx1CUv3/DwBX9YJF84bUx+xlBvteUR/g3TtWU9Z93luuVXkNR22F1xl5lL5gdgjIi6Q4tahr75udcJo5MyoH3iMp7Vuzs7dJhSTN+xaHCAcUS8DUJ8iHUNnRE+/33kFv/mtgiI0Lg==
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 MN2PR11MB4694.namprd11.prod.outlook.com (2603:10b6:208:266::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7611.22; Thu, 23 May 2024 17:45:22 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::fe26:42d8:b3ff:c2c7]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::fe26:42d8:b3ff:c2c7%3]) with mapi id 15.20.7611.016; Thu, 23 May 2024 17:45:21 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "gunter.van_de_velde@nokia.com" <gunter.van_de_velde@nokia.com>
Thread-Topic: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard
Thread-Index: AQHaYBqs4F3cMQ17fkO+oCL+srdt/7Faj7NQgAQq6oCAABEwkIA7rXEAgAZHkKCAA522AIAAKZRAgADtDgCAADqNQA==
Date: Thu, 23 May 2024 17:45:21 +0000
Message-ID: <BY5PR11MB4337D25964B1106AC546291BC1F42@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <170800694057.2168.264514412767158496@ietfa.amsl.com> <BY5PR11MB433786495B233499026876BCC1032@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB95509197C56B33B6359783EED4002@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB4337B11B4CB33E0C73FB1A19C1002@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB9550565DA6093AED6DF29DB5D4ED2@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB4337608CF66B0BD1BD9E46D6C1E92@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB955056CC9F7D47CAB7AD11B0D4EB2@IA1PR05MB9550.namprd05.prod.outlook.com> <BY5PR11MB433714B6448C5E18AE1FC1FEC1F42@BY5PR11MB4337.namprd11.prod.outlook.com> <IA1PR05MB9550B4F5415A9000AF269A97D4F42@IA1PR05MB9550.namprd05.prod.outlook.com>
In-Reply-To: <IA1PR05MB9550B4F5415A9000AF269A97D4F42@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=5953b05b-f2a0-487a-baaf-6bfc326abdee; 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-04-08T13:33:14Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY5PR11MB4337:EE_|MN2PR11MB4694:EE_
x-ms-office365-filtering-correlation-id: 5c177b1a-96c7-41f1-5404-08dc7b501e3d
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230031|366007|376005|1800799015|38070700009;
x-microsoft-antispam-message-info: v1QLwtr6Jpr9G0uYzBTJZ3ZpABMnSZRT6IMX6QaLOUAx5sjrz0g1N2yYq1+/VyRo95e/o+lIbUzOdRMqi840JjcASs5i0svDmG4iQ1tm5RAgx9rfGVzK4feJDjkmQh/3h/GM0XHk2tejGnXqAdn6RkeJtXa22MnoseteZpV+8xuQIMUFSkdu0Ldu4ywAFe4BNgv2XAhd+J2LC2kWx7e/wLgHdQ8PkTfB7QUPmcvdPagYdm5w1t8I4DUV9Q+m/kvNDuK+stiBZaNp/AtMHuGdB1Sk5OYTTFced0ZNzaG1MGxg0C6GogpMhRcsZh0UzQi84aYgz+U/THxHRyaORQ/sSj24Pu+GFvXw5Yh/SzrZLDseZqpMseogRIHgHUeplxjGZLyU17750RxwsQhWGD1h0iTXByUrNTXmTIY4ABzoICHmgTIf0SoyFQ6l1voIk1AE1cR/g4a6XWYHDEW56chRwITQijOZs7UVtqLDAukxLrQ6vHwX7D0dSOPVYy+Ip3LJgUTKZ6sNzyC85fAhgSXReZ6SHgIQs6CdyON3LK4rWpJaLVxXoMNTTj9n/gMeZHeD8Gfd5Tc2sDwijKW8MT9QwadncXnhqwDs25elgKd/d+XGTWFELhepfax9b73JT0JVoO6PDYGo0ONUDQUyU3mshT1bmVj8qz98ePfdIVIC/Zk7uwpAtmFZO0W6lHhvH98w2RoeBdJWiqKBSdizM2Bj//aKfpM69fDLIVIvwVQwmO9Lc8slGBVKEa18tn1+uG0yN1SaBd1KmljhUFY2RunwhqEOHwWyq+oXV99421UpWgrcJUt4REwv6m9fKvfv3zGapFSVgJB3gvgd2k/8NQhfgKWJ9bpzBqjtQfHuOvffc4gG1BgyVckk0h5+jOXqohwNY3wOsSZyVC9HpLn8fByT78a5olCghatf894JSCNnF0c6Vd4UbOhwsTVPwklmNxUZtMo0TxdUJmRdC129oEgi2d7kvEb7gk24mqYePvYxGmR7UZTH65yQ/ssRjwScLJ9p66Qsm2WCmiKVkhOOXrjWbju0x6/Y35twP01udfi3JbSH+lUs46sFMgvqqh6MQKUwNwq7zdCfm5kCHEF/NBp4h3f9vIBOHrmcie9jcIYhmrAsh0UhFo7n4CWS7ve7PEX/a14rBdVv05lGi9cw3VEkWsP8bdisEyaORWO0nakTEaMnnGwHMHPW6CAvSkKwPOq7T4vTJHgW7ad6g8tAT6mnKXMw5HhiC+USMyjR/vJLlvaC6SF8Z+7/VqhCGlmpe73QTT2Ui01zHUEvoi3j3Y5XS/m9pE9BJOBgGCd21tBb5ks=
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:(13230031)(366007)(376005)(1800799015)(38070700009);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: svjoSOQC/OeyHe5ftVAqKasN05W6ePStTF0IGlNf6WjtkxNdE/nWZvnJ+vL5e13NxOQD5cMq3njrmb2fYPRZ3caokxr8KCBiLM0ushjgDeVehmN2v+dKy4GG8tH/mQX6zLcJ8QjAHErbIGraBNTPysoiouACGZ+aNyGDLvERuzOy/NIFmzQcWHmfKhmNITM28EUbNPoecOf60szLJxBEaEjFmnvP4g2P7eVDzv/oXnuda9t3yTY209YFcrLRt4YhEM9fq1USY+5nkvdHt1pnkDUVUlS4O8dCLBt87+E6q0UQiZwnGSnklx2+Ve1qTe3Bg/RxlbOax1OwXEgIerv4sfKLqHUseAISSNHqppXgxP3LZzukHX8J19koQfGOBBZUxxjs1bBInyo/0SG0cfs5z1Da9gqhdb0VtU9nC3UpCWVi7XOr+s7ERGoA1ts27WZOID45XxuNApd+QTIoFGtXOdE5P35OdX5BDj7oX7Xz3J4AJxIw7ihrzWeNYv2BJ9zJcUNSC2ZrqnVyW1yzpNwfO1YRB+rqvvpYfTQNlsugTKStE7n5QlX4dgvwyzM0KqKkKZx9fx9pP4j0//KpPu/te5YD8qFDch97ukVK7d6ZbkNtiMEs0z+tfr/VlFDT4JIr5DxGK6QlymWSuuaMSW4R1L/KJEwpW3olY8txqj5jfribLZ74YEs99SxA3BBSwhbrc2COoe99wUik30fT8Fa/UL5mkSZPGVtJt3WgftBy/V8UwlSWN7B/M1jMyho1upLqakPkEHgXhPdvZOiZwao6THenN/JJp+UcJVcKtd1c9Al6U5WRlkIk6069xCZeU346Q52oRZtRrfbdPMZsZZLnLy3T/zXhUS6bVBgXV+7iwqN4biB8xhd7CoNfDVaTcm3TlKCF8p5DJHT8xrV87hLutUxhiJ6QTXsP/f/u+XhVMEOE285PucUeVwXdPf0xlpiyF7oBmJ8hZRDmXFn50F33T1tt9JgZ9Qj4kXCKYDl1ljUo6XKIh8UNhFWjQMZsJmpr9xb/J6xNAleKGmcHvtxizQh5rfSl+yT3NHzsF0i156JAwwuPAe10koPFp7hJ+hyeE2X7vfB/tpHNeEeK/lMABbOw0Vat6U/ilVcEhLAq6pLwQ1wwJ7/C2yYAaoJT+pEAvt7qeWHfd8R/IGxXndF8ZWxeDjCKFw25pSn2AxZnU/wIwwvtmCy/U5m/ALeiH2hBu15hNxz/ht1VCcLbzxh1kz2X1Ga7Ege+XyfBZ4h3HyvuYlc05+9aBLoFAy6k5VbC8YMRjoLxhiFfG741AuGpsOe3L5t2cXVbR/2XxZ4SP9z3Ro96avdquoDY4T1ys5Wfa/OksH8Hcq7aLyvWEBGyKj6dgaSg0RHUhzyZfjvq4cEFhcNz1G2SX+Y3FP4cv+/Zh9TBF48csB8USFfxRLOaLyfM5WoG4qVYGp4Sgahblp0Fi3g9qO90Q2hpWl1hfWCDjSeqA7iepEQoBRuIzA7FF3eXLi8NGR/Y/ybnuc9T2kMFFRbxc1/Q9WCdtFA5z6vjJPC3BmpFzwG/HRzmgJM9FFrXh9vc5h0b6sV+hh7z7U504ASEHpZ603jSHHgLViJ8
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337D25964B1106AC546291BC1F42BY5PR11MB4337namp_"
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: 5c177b1a-96c7-41f1-5404-08dc7b501e3d
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2024 17:45:21.4435 (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: /TdH3a7sNwn7j+gs6/p0lub8eKNmNoQ3aGu3SHzmbM26EsqBtVSrYxFT/blPwkOvKlxIlqFugHPhRGthL8TLcA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4694
X-Outbound-SMTP-Client: 173.37.147.229, alln-opgw-1.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Message-ID-Hash: QMOODWW6OSUGDRQQH4YPVSRJGCAERVU2
X-Message-ID-Hash: QMOODWW6OSUGDRQQH4YPVSRJGCAERVU2
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: "andrew-ietf@liquid.tech" <andrew-ietf@liquid.tech>, "bier-chairs@ietf.org" <bier-chairs@ietf.org>, "bier@ietf.org" <bier@ietf.org>, "chen.ran@zte.com.cn" <chen.ran@zte.com.cn>, "draft-ietf-bier-tether@ietf.org" <draft-ietf-bier-tether@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Bier] Re: Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
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 – I find myself wondering why you are questioning my recommendation. In part, I believe it is because you haven’t implemented the functionality. The point about reachability is telling. If the internal BIER component wants to determine if a particular node is reachable, the internal data structures (e.g., RIB) aren’t going to have an entry for the IS-IS system id. They will, however, have an entry for the router address/router ID if it is reachable. And I don’t know why a helper node would want to advertise it can be a helper for a node that isn’t reachable. In any case, you have my recommendation. Feel free to consult other experts for their opinions. Les From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> Sent: Thursday, May 23, 2024 7:08 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>; last-call@ietf.org; gunter.van_de_velde@nokia.com Cc: andrew-ietf@liquid.tech; bier-chairs@ietf.org; bier@ietf.org; chen.ran@zte.com.cn; draft-ietf-bier-tether@ietf.org Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard Hi Less, We don’t need them to be routable. As I explained: Zzh3> The information is used during the post-SPF process – if a child of the SPF tree root does not support BIER, we try to see if it has a helper that can be used. The LSA/LSP for the child has the router/system-id in it, and the ID can be used to look up the helper. In an OSPF/ISIS network, each node has a router/system-id. When an operator provisions a helper to help a node that is not BIER capable, it is feasible and easy to enter the router/system-id of the helped node. Thanks. Jeffrey Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Sent: Wednesday, May 22, 2024 8:10 PM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; last-call@ietf.org<mailto:last-call@ietf.org>; gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard [External Email. Be cautious of content] (Top posting) Jeffrey – Why don’t we want to use OSPF router id/IS-IS system id? Because they are not routable IDs. Routers will not have forwarding entries for these identifiers – so it won’t be easy to determine whether these nodes are reachable. The OSPF Router Address and the IS-IS TE Router IDs were invented precisely to provide stable routable addresses for a node. They are now being used in numerous ways to identify the source of information e.g., https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7794.html*section-2.2__;Iw!!NEt6yMaO-gk!A9tsq_-gWYwF7KCZOhWKiZJoEiUtkcF43pnvONQQZpjzkZ60GGOCdqPKhsvOjqkhzbCOIzHO3pBmSehI$> https://www.rfc-editor.org/rfc/rfc9084.html#name-prefix-source-router-addres<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9084.html*name-prefix-source-router-addres__;Iw!!NEt6yMaO-gk!A9tsq_-gWYwF7KCZOhWKiZJoEiUtkcF43pnvONQQZpjzkZ60GGOCdqPKhsvOjqkhzbCOIzHO3laP4ZS2$> Your use case is best supported by using these identifiers. Les Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> Sent: Wednesday, May 22, 2024 2:31 PM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; last-call@ietf.org<mailto:last-call@ietf.org>; gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard Hi Les, Please see zzh3> beow. Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> Sent: Monday, May 20, 2024 10:40 AM To: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; last-call@ietf.org<mailto:last-call@ietf.org>; gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard [External Email. Be cautious of content] Jeffrey – Please find my responses inline. Look for LES2: Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>> Sent: Thursday, May 16, 2024 7:24 AM To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; last-call@ietf.org<mailto:last-call@ietf.org>; gunter.van_de_velde@nokia.com<mailto:gunter.van_de_velde@nokia.com> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard Hi Les, Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>> Sent: Monday, April 8, 2024 12:20 PM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; last-call@ietf.org<mailto:last-call@ietf.org>; IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard [External Email. Be cautious of content] Jeffrey - Thanx for the prompt response. (Better than me. 😊) Please see inline. Zzh2> Well this time it took me more than a month to get back. Sorry about that. Lots of catching-up on the backlog from business/vacation travels. Juniper Business Use Only > -----Original Message----- > From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang > Sent: Monday, April 8, 2024 7:03 AM > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; last-call@ietf.org<mailto:last-call@ietf.org>; IETF- > Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>> > Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; > chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> > Subject: Re: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER > Router To A BIER incapable Router) to Proposed Standard > > Hi Les, > > Thanks for your comments. Please see zzh> below for clarifications. > > > Juniper Business Use Only > -----Original Message----- > From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> > Sent: Friday, April 5, 2024 6:36 PM > To: last-call@ietf.org<mailto:last-call@ietf.org>; IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>> > Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; > chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> > Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER > Router To A BIER incapable Router) to Proposed Standard > > [External Email. Be cautious of content] > > > This draft is at a minimum underspecified and has some technical errors in the > encoding which should be addressed prior to publication. > > There is no discussion as to what the "address" should be in the proposed > "BIER Helped node" sub-sub-TLVs. > I would presume that what should be used is the "Router-ID" as specified in > the various protocols - but there is no mention of this and I think there should > be. > > Zzh> The draft does say the following: > > The Type is TBD1 (in the case of ISIS), TBD2 (in the case of OSPFv2), > of TBD3 (in the case of OSPFv3). The Value field starts with a one- > octet Priority field, followed by a one-octet Reserved field, and > * then the Address of the Helped Node (X). The Length is 6 for IPv4 > * and 18 for IPv6 respectively. > > Zzh> I can add "4 or 16 octets" to the following figure to make it explicit: > [LES:] MY confusion is not with the size of the addresses - it is with what addresses for a given node should be used. I would think you want to use advertised Router IDs - just asking for that to be mentioned. Otherwise, I do not know how you expect the various helper nodes to advertise the same address(es) for the same helped node. Zzh2> Good point; and I do need your advice on this one. Zzh2> For OSPF, it’s always 32-bit. For ISIS, I see three possibilities: system-id, IPv4 router-id and IPv6 router-id. Zzh2> The router-id concept is introduced into ISIS with TE. Is it a common practice now to always advertise an IPv4 and/or IPv6 router-id, w/ or w/o TE? Should I simply advertise the system-id in the helped-node sub-TLV? [LES2:] For IS-IS you should use the TE Router ID as defined in RFC5305, RFC6119 For OSPF you should use the Router Address as defined in RFC3630, RFC5329. Zzh3> What about using the 32-bit router-id for OSPF, and the 48-bit system-id in the ISIS case? Zzh3> The information is used during the post-SPF process – if a child of the SPF tree root does not support BIER, we try to see if it has a helper that can be used. The LSA/LSP for the child has the router/system-id in it, and the ID can be used to look up the helper. Zzh3> What do you think? Zzh3> Thanks. Zzh3> Jeffrey > 0 1 2 3 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Priority | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Address of the Helped Node (4 or 16 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > As there is provision for IPv4 and/or IPv6, this suggests that a given router > could send two such sub-sub-TLVs - one for each address-family. But there is > no discussion as to whether this is allowed nor is it discussed what would > happen if a given node advertised multiple such sub-sub-TLVs for the same > address family. > > Zzh> The draft does say the following, which should be clear? > > ... The helper node (BFRx) MUST advertise > one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in > the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in > the case of OSPF, one for each helped node: > [LES:] So, what Helper Nodes are advertising is really a list(sic) of the nodes for which they can act as helper. Your encoding is not optimized for that use. More on that below. Zzh2> That is a good point. > The name as defined in the IANA section is "BIER Helped Node" - but I would > think this was meant to be "BIER Helper Node". (I could argue that a more apt > name would be "BIER Tether Node".) > > Zzh> It is indeed "Helped Node". The Helper node advertises one sub-sub-TLV > for each helped node. [LES:] Ack - after a more careful reading I agree. I tend to think "helped node" is better than "tether > node" or "tethered node" for three reasons: > Zzh> a) the document uses "helper/helped" node throughout. > Zzh> b) seems to me that with "tether node" and "tethered node" it is not as > clear on which one is the helper > Zzh> c) somehow to me the wording "tether" implies directly connected; > though the document started with that scenario, it has been expanded to > include remote helpers. > > > The encoding defined in Section 3.1 needs to be made protocol specific. OSPF > typically pads things to a four byte boundary, but IS-IS does not - which means > the "Reserved" field should not be present for IS-IS. > > Zzh> It is for possible future extension purposes instead of padding. If you say > it is important to save bytes in ISIS signaling, I can remove it but otherwise I'd > like to keep it. Please let me know. [LES:] First, reserving space for possible expansion means we send more bytes than needed. I am not a fan. And since you don’t indicate what the reserved field might be (flags, op code of some sort, ...) the probability that you can add information w/o backwards compatibility issues may be low. The more flexible way of adding extensions would be to support sub-TLVs. Zzh2> I will remove the reserved field. Second, if what you are advertising is really a list of helped nodes, one can imagine a more efficient encoding where you can advertise multiple addresses in a single sub-TLV. To do that what you need is an AF indicator (so that the address length can be inferred) and then have a list of addresses. The AF indicator could either be done by having a flag in the encoding - or assigning separate code points for each address family. Zzh2> One helper helping multiple nodes is not a common situation. Still, I will take your advice to pack multiple ones into a single sub-TLV. Zzh2> We don’t need an AF indicator for OSPF (since the router-id is always 32-bit) or ISIS if we advertise system-id instead. [LES2:] I assume you will revisit this answer based on my reply above regarding the addresses to be used. As an aside, I am wondering what the push is for publishing this as an RFC. Have there been early deployments? I ask because if you do consider encoding changes, this would obviously impact any existing POCs - but given you did not have early allocation of code point I am wondering if that is a practical issue. Maybe move forward w an early allocation of code point, get some deployment experience, and then push for an RFC with better experience. Zzh2> While there is no deployment yet, the solution is sound and it is just a small extension to the Section 6.9 procedures in RFC8279. If I can get past the reviews by Chris, you, and Gunter, I will still prefer to proceed. Zzh2> I am happy to have a conference call to discuss the solution in more details. [LES2:] The hallmark of the IETF is that we define solutions which actually work. The way that is achieved is that we implement the proposed solutions BEFORE documents progress to RFC. This is not meant to imply that your idea cannot work. But how do we know if it works and if the encodings defined to support it are both sufficient and optimal? This is knowledge that we want to gain BEFORE standardization. Otherwise, we are likely to end up with early deployments which can constrain corrections in the encodings due to backwards compatibility considerations. I take your point (made in response to Gunter’s review) that performant BIER implementations depend on new ASICs. But this does not mean that we cannot implement POCs which operate at low scale but still allow us to refine the specification based on actual testing. I really think you should take the inputs received, focus on implementation, and come back to the WG with feedback based on the experience gained. No need to standardize an unproven solution prematurely. Les Zzh2> Thanks! Zzh2> Jeffrey Les > > I am not enamored of this technology - but at this time I will refrain from > commenting further as the WG seems to have decided to go forward. > But please address the comments above. > > Apologies for the lateness of these comments. > > Zzh> Thanks! > Zzh> Jeffrey > > Les > > > > -----Original Message----- > > From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of The IESG > > Sent: Thursday, February 15, 2024 6:22 AM > > To: IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>> > > Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>; > > chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org> > > Subject: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering > > A BIER Router To A BIER incapable Router) to Proposed Standard > > > > > > The IESG has received a request from the Bit Indexed Explicit > > Replication WG > > (bier) to consider the following document: - 'Tethering A BIER Router > > To A BIER incapable Router' > > <draft-ietf-bier-tether-04.txt> as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > last-call@ietf.org<mailto:last-call@ietf.org> mailing lists by 2024-02-29. Exceptionally, > > comments may be sent to iesg@ietf.org<mailto:iesg@ietf.org> instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > 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 file can be obtained via > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-iet> > > f-bier-tether/__;!!NEt6yMaO- > gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S > > 8Qz44ePY-vB12NTqD4fHt9pgsqPZaldvVYKmMJLu2$ > > > > > > The following IPR Declarations may be related to this I-D: > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3331/__<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/3331/__>;! > > !NEt6yMaO- > gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12NTqD4 > > fHt9pgsqPZaldvVYC2HqNh0$ > > > > > > > > > > > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org<mailto:BIER@ietf.org> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier> > > __;!!NEt6yMaO- > gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12N > > TqD4fHt9pgsqPZaldvVYLcO-qjO$ > > _______________________________________________ > BIER mailing list > BIER@ietf.org<mailto:BIER@ietf.org> > https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!BIfUCpxrA0AT2jNR8bR1jM2-oGiTE9sVzQNnWu0D0-059h4vwGobm758B_07PC9Q2PDcNDkNPSdqPJedUY6hKDSpNA7pbN8N$>
- [Bier] Last Call: <draft-ietf-bier-tether-04.txt>… The IESG
- Re: [Bier] Last Call: <draft-ietf-bier-tether-04.… Les Ginsberg (ginsberg)
- Re: [Bier] Last Call: <draft-ietf-bier-tether-04.… Jeffrey (Zhaohui) Zhang
- Re: [Bier] Last Call: <draft-ietf-bier-tether-04.… Les Ginsberg (ginsberg)
- [Bier] Re: Last Call: <draft-ietf-bier-tether-04.… Jeffrey (Zhaohui) Zhang
- [Bier] Re: Last Call: <draft-ietf-bier-tether-04.… Les Ginsberg (ginsberg)
- [Bier] Re: Last Call: <draft-ietf-bier-tether-04.… Jeffrey (Zhaohui) Zhang
- [Bier] Re: Last Call: <draft-ietf-bier-tether-04.… Les Ginsberg (ginsberg)
- [Bier] Re: Last Call: <draft-ietf-bier-tether-04.… Jeffrey (Zhaohui) Zhang
- [Bier] Re: Last Call: <draft-ietf-bier-tether-04.… Les Ginsberg (ginsberg)
- [Bier] Re: Last Call: <draft-ietf-bier-tether-04.… Jeffrey (Zhaohui) Zhang