[Bier] Re: [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05
"Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com> Mon, 04 November 2024 17:16 UTC
Return-Path: <gunter.van_de_velde@nokia.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 1821CC1DA1ED; Mon, 4 Nov 2024 09:16:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level:
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.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 isSjzbtD9PjJ; Mon, 4 Nov 2024 09:16:41 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2061.outbound.protection.outlook.com [40.107.22.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 181D5C23A858; Mon, 4 Nov 2024 09:16:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ehJVfAn0domUWP4R8uIHBNEXAl7jMorjQAThlXDWEPt3XWd0anaWvDIuTIotDdSIHWOEesHckjKZbeifoLFA61IEciDK6hu3mkSGcAsaolMxHX7E2Itv4Su7zBhcLaOzuMwzwRNcWcHx8o+X9MGlVW+6dpzrAHEzkJSIgjGvEiH7QlMVYyhf1J83YKQdLyeSeIHBAI+1n29bbA8hUQA0521YZBeQA9clAgMRK9o53PCoIFRGV5H5mgr2pXv6lq3aDnMuVV6sBLWs7TLKZx1F0IR5b/TUoTmulKXJXQfwWGVtnSIXQoDYCoaTYoTShYgMEGJXrP8a8vCsAEgkiZQg0Q==
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=8Q8NKkNQDIBwzsSxXprX9wJqL7RZe82Bw3jU5z4X/S0=; b=J/tQcMgsPHx/lqYM3vXnuqWBN9/hCVxmNLVi0qbQib0puiyYT3bdjf+AAbrh6yAmCmrI9KAcMHS1zlwEDrY/QZCMlob7gMmJCcNqMbLU/No77YdiGhQVkJA7rEj5m3QhKpxMrBhghU2pYmVh3GPIeUm2pNmTW5AvTRVHvJW27idt7R1DpXkTSMhfPwqTZBzlJD+vuwKyISNAIhomKsfWGxyIWM9/45OtDlvDBmLCNtN0qPhKADzjmqAObmHa/6bip0swbfOQzT215dT7GkJcd40WQI35nRlgGggRdIGq1mm42T/ds+yXn2yuYSYJm8jNWlVteCs8mbsH76XOWAuUWQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8Q8NKkNQDIBwzsSxXprX9wJqL7RZe82Bw3jU5z4X/S0=; b=YSmeWeh0O6DCL4zqy+DB8O0vL02Ev1EdX5AAwtSgjpPjS5xrF52cUCGiBzsUIBAV43aMchhv/DWCcJfSBjb7meww7sI6DXbF7v0GjLZ3aJlG86wnKmzZkjPrkwfgMTsJh5iXA+dNVhDyWM8JM4fQREM0NxAFMs5+7irNo+D+pkwOcn5M7+e3dzUrDsctVwcfS82+x8bafsUNI4dLUAEv7+B/GymkBRNyyk3Bsf++hZK3+DnwxH2S4tl4tQ9hLLTJTcHnG6oy/C8+BJxNbMUBUWnEOUt+vx+hSzaPPfWRpesZJcofQzXX2tyrmPn2As333bI3n90CYUD1pAscYe5MbA==
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com (2603:10a6:20b:470::16) by AM7PR07MB6280.eurprd07.prod.outlook.com (2603:10a6:20b:142::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8114.30; Mon, 4 Nov 2024 17:16:19 +0000
Received: from AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e]) by AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e%5]) with mapi id 15.20.8114.028; Mon, 4 Nov 2024 17:16:19 +0000
From: "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>
To: Tony Przygienda <tonysietf@gmail.com>
Thread-Topic: [Bier] [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05
Thread-Index: AdqKcZP33ZkxqkMKTF28yyE8RAQqqCkZu0OAAAEfEdA=
Date: Mon, 04 Nov 2024 17:16:19 +0000
Message-ID: <AS1PR07MB858971900CA2D839575F63A4E0512@AS1PR07MB8589.eurprd07.prod.outlook.com>
References: <AS1PR07MB8589A23805E5B18D7560762DE0072@AS1PR07MB8589.eurprd07.prod.outlook.com> <6835D83C-09DC-4C31-A210-5195DC885C2F@gmail.com>
In-Reply-To: <6835D83C-09DC-4C31-A210-5195DC885C2F@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS1PR07MB8589:EE_|AM7PR07MB6280:EE_
x-ms-office365-filtering-correlation-id: bdac6b22-60dd-4fb6-4a12-08dcfcf46640
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|376014|1800799024|8096899003|38070700018;
x-microsoft-antispam-message-info: aNdcnmN53g6MBRM5P0/i11BuUh6fioD/sUFQXx+S9p6ZyZ2AkPj/ZQUsihO3Dx3sx5nTHhUnE4GyG+Lsu4Gsa7wbMdoRCvbST5IXOzfgvB5uX43VNdRqPVLws1Me1p2y7TZq5IOEA3dHuDSTrHxCTRIlZYSir1FaHL6SsA7V8cPHnH6ndQu/weK8vVX3fH5uqMeXUKkbVMg87Keeu3cm3HKsBiW1YfvgSnf1gDRnHXmQl+cv0ygm+cCh3o8p0OUyMq/UOKYgNdURp+1Ay01JsEFlNWD7kxLsfEgkiEZ1vjKT6Sfu7Q2dDS5CaIM3AICWxcA1Mvrw3mk66QKnbc2SlIBn84iAL+WTCfmN2PBrm33LYtVGWun+rchDpLktj/WSqcRVwCybyHaJSulaBOuiA4ADQx9QbslrhxJLEkQVY+giL4vSoOI/xBi/oEYhfwtPDC7vV9FHjsLQUzHG6mvB1hqnciSx5zrxq951VnUrd0rH0khUoa9EjYs/Gb3PTHnEAqZAo+LVEi9wqqWRhtbf5OUdWK63SPwnDaTbBnX3WhzbcJwN06QeJI50NtiRbMp+vSse4xPAUIDDoTkQiEp7bJLX+TwSOeXavmMNgWPNFNOiv6b/O2Jv5+qIVRRCzuChP00IcS5PAZAJSWT5y9lkVFY/8Iu1mbh5oPCX8lUPJC/wMTbEzoZs8eWKiYLoUvKCkyAl3osSr46htYv00G11YlUfhEfeWZQq5+2qy1qG+pHU4IAzjWES2yumT/fzXEhc5rv5UMnT0srAFqFqK2twy09O3QvurkQskJplNhIkXB1g0uK8+00viK/iX2EMQcYd1PjBRorr0WjT9gaENMxRMtlXMHTF+ekYixqZaxg97y/9uAXu1S/vzju30XP8kd9jMraUCo8c6AmtSQv/yIJmuOVzS00ijWUM9bNrdGFklpazd4LHlmtXOHxbob5yssd+ey6ZkRXIhKRrZi/kfjzHeOYlFBfb5nZRKkSY6+iOL9BBoK+MXFCabcm/GtjYbN/rjx4DCU+48ZndJSK1Rdi/o9+bQDaGkOVVwEXhtKcXe2hrtT5jIzbU+vNxW5Vqd71qJJuKEkPSf8qxK75ZKeSGdquJbUDmfXZh+KE0MMpFcVwS1JwjeeFGTwhhfRgdAIxVBt6apHdUFL8VKtW13PcTYiD9HD/Iud8BFYarhlwVMTCvhwQSihJiKGscJaUIzgtE5gfEqh5A7ZArALlq+HVOV1li8VSu/4mLVH3Jn9wB0exZ8f2Oq8y8qQBf/HUOyT+PaCNybGKLAsx7ZLKT7X75Axx+vn0QqTZroMtuyi4+TvlQYs8LRwnl41xKpIQIPxyolW0jwrhFov6fjpX7+cYf/w==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS1PR07MB8589.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024)(8096899003)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: qDwtJqee5ItVqddC/jW1H7bOKkGruYVaydjTQdZqR9w9llzbvoc9efeRunVfcBNevgx+jDJvlhxNQrl51kqZEqSMKtRiKE3nMOlQRX2vniZq86DTDx2QIWlfjB6Jt4+7ixK3i5V83spaVFmPteCS1l68FE3iW+hzq+BLGW5z1rfhKyY2kzODsS0Lp8ELaM8eVa5SLaDIOUEq/XZbr7KaEfqdXeMweOLJo18CHtz5j4cNYBmSotURxsIjqU+ovgVg7Mf7xHcYM8hCFF8N97iEQPUDriJbcMF++nfVoQvAMBuBxrF+I1hZERFxn32xEqFPYtWXajNqsWa5MEzYJUyo01NSg4CDo6mTJd6GQsjXgPon+8F1O3avT7UOCW8bE4eVvaRqpqZp9EhsKRkwn6Wdmi7SkJqXJBEsOLKwufWQILStmMhbPufqeHGd23+204qeFaX6qW/r4oGYFW+KU1pE3K3NzFuf2mxb2EHgvRGYg6yphiRG7S3zJHhE287YoXOnsxTG97wWHnI2/02MY9hQWU08zRxcarqQZn512a/hGoVP5zdAVpVp+68NQdnMwPppUZpOM/o+p3g9pzHuw4vOjTUbKYEZsxstB0mlWQVx0MBnsBk/sz/pViJX7hdNgPVDaYke6MTpN12NlYrWOrtbCGa38f1bW+L/cs5Mhf9jiRcHbHBy4bqBi3vLjMRSk8Lk9S8go+7VoPHSogU+zAHh7QpKTwYB0mWoSxdkzx6n9WSRIzrtvxbxdnGFJlt1WgaF2ChoOyuOSWiNbybwv5fHT0/SKBT/csKFfenf6ZNHsjufcCHYR6Vlbt+x9KvoXtonDf353wt4ZHhu31nwOW+hGKOeKkWuZO4MHis+NRrq3wEHs8ZLa1uy7zUdFCA03rUKUWLvitQ/MOk1f9v7EqxlSWPBMUziqU8PklEQH4FwISu9i4wTikKqvi0jqCaWJ3Hz0UQj57IgbIX5M0WhDz25xW9ycuYoyR+ENnZLb7SvAGu2PL/+StRnza4ikdMCu0KapIFte1Qk+6eSQJ+mLPjryW8mj/jVbszqhxE/Imoe8tDMtcZh6g8bCrGPjgm0WNg8aM17bKoV9nrQeRweoJHLaWgXOU8NxhtJS+kUK6pVuHZK8+1Hd7I8qoH2O5S3TrRg4pKTQjujFDs7Jju70JpsxEKlsIhw59m8SNv25HGcy7a6I9ThS7ZJ1/WQjD02R8IRRgPSus7TC75v+CsyMhw2KXXMYSt34mblE5IN9AwsjebKWm0W10D9g3YU795UT4ajjXlpS9DZA4QRwoVXDVvCmIFsYZ8M+wxum253ara+sbhssAqw4QHiGAV6UxkkIMVqtqmTuA5qWnfm9aLaPfB3j5dKGrQuVxjXs/eb804dYXk9xIii3Ef1/JuD8SOFfmyHqQL366OTj42oNKsl11zB1x6jJoJiLPyN4lkmNPkW8aS42ujypu12VsYjMR3r37mVy+wvfxny/J+sxwgBmtWnZMO7quUMgZ3lxrL5nnAI6+T47w4FOoscsMBlR5tC7ps8YnjrY6Zb6ZxtFSZrtRuTNbAEYE8DW8ctbZIPP7+I/F/jgFgIeIftqgaIgTmBh4V6Ocvfps7K3N4qrHAk7VujAg==
Content-Type: multipart/alternative; boundary="_000_AS1PR07MB858971900CA2D839575F63A4E0512AS1PR07MB8589eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS1PR07MB8589.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bdac6b22-60dd-4fb6-4a12-08dcfcf46640
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2024 17:16:19.7084 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HgbZfuO809PAJ/URAGyaGd/BAznQG2742TIYwveNWt1I+kS6Ehqzc/ZvGQ5HGeTCHbezy4ILYQoobJYzxD96HAcy/WyiNfJWTUIpIY1IIc0=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6280
Message-ID-Hash: DYXQSPYX5XUDKY6QGOCN47WA4FGY3IAA
X-Message-ID-Hash: DYXQSPYX5XUDKY6QGOCN47WA4FGY3IAA
X-MailFrom: gunter.van_de_velde@nokia.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: "draft-ietf-bier-tether@ietf.org" <draft-ietf-bier-tether@ietf.org>, BIER WG <bier@ietf.org>
X-Mailman-Version: 3.3.9rc6
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/uEQ9Jzud_BrZUoea9cY-YxGPYuc>
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>
It should be back now. There is abug in the system that when a document goes from IESG back to the WG it gets wrongly marked as dead. The secretariat fixed this for us and the document is back in the list. G/ From: Tony Przygienda <tonysietf@gmail.com> Sent: Monday, November 4, 2024 4:42 PM To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com> Cc: draft-ietf-bier-tether@ietf.org; BIER WG <bier@ietf.org> Subject: Re: [Bier] [draft-ietf-bier-tether] Shepherding AD document review of draft-ietf-bier-tether-05 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. BTW the draft seems to have vanished in the BIER WG document tracker for some reason On 9 Apr 2024, at 12:32, Gunter van de Velde (Nokia) <gunter.van_de_velde=40nokia.com@dmarc.ietf.org<mailto:gunter.van_de_velde=40nokia.com@dmarc.ietf.org>> wrote: # 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"? 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/ In general there is ongoing effort to be conservative about any IGP encoding, however especially with ISIS are TLV resources often constrained. 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. 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? 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) What is the impact of technologies as LFA/BFD/ECMP impact BIER Tether topology? 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). 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. 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. 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. 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? 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. 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. 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? 129 2. Additional Considerations [minor] this is odd titled section. The section title is "Additional Considerations", but there is no section about "Considerations"? 135 Additionally, the helper BRFx can be a transit helper, i.e., it has [minor] s/BRFx/BFRx/ 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? 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? 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 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? 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 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. 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 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. 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. 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/ [major] referencing to the comments from Les. 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. [minor] no figure number is provided? 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)? 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. 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? 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/ 271 3.2. BGP Signaling [major] Can BGP signaling not be seen as another ecoding in addition to the IGP encodings? 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? [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? 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. [minor] is there any impact upon how the BIER-SPF is modified using the received BGP derived BIER information. [major] are there no BGP code points or encodings specified? _______________________________________________ BIER mailing list BIER@ietf.org<mailto:BIER@ietf.org> https://www.ietf.org/mailman/listinfo/bier
- [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)