Re: [Bier] Éric Vyncke's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)
Toerless Eckert <tte@cs.fau.de> Fri, 28 January 2022 17:07 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 80BAE3A085B; Fri, 28 Jan 2022 09:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYJIan01g2ME; Fri, 28 Jan 2022 09:07:21 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BAD3A07AA; Fri, 28 Jan 2022 09:07:18 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 380C858C4B2; Fri, 28 Jan 2022 18:07:12 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 33ECE4EA4BD; Fri, 28 Jan 2022 18:07:12 +0100 (CET)
Date: Fri, 28 Jan 2022 18:07:12 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-bier-te-arch@ietf.org, bier-chairs@ietf.org, bier@ietf.org, Xuesong Geng <gengxuesong@huawei.com>, aretana.ietf@gmail.com
Message-ID: <YfQiwM1fTLLzDjlB@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <162997945236.17470.12540819726342245988@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/tS97LXdGN5A0PiVw4Yf8j4kRm8I>
Subject: Re: [Bier] Éric Vyncke's No Objection on draft-ietf-bier-te-arch-10: (with COMMENT)
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jan 2022 17:07:26 -0000
Thanks, Eric Vyncke Detailed replies for your comments below inline. It should resolve all your concerns. These have been integrated into draft rev -12 which the authors feel is ready for RFC editor. Full diff from -11 to -12: http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-11.txt&url2=https://www.ietf.org/archive/id/draft-ietf-bier-te-arch-12.txt Diff with just the deltas for comments by Eric Vyncke, Eric Kline, Martin Vigoroux and Lars Eggert http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/toerless/bier-te-arch/c88c22d82f8e17e66929e2f0d82ca02680b8fe0e/draft-ietf-bier-te-arch.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/ca1c4ec15302e5287c0bd60b9f14d2c58428e50f/draft-ietf-bier-te-arch.txt Thanks again for your review. Toerless On Thu, Aug 26, 2021 at 05:04:12AM -0700, Éric Vyncke via Datatracker wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-bier-te-arch-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. As I am back from vacations, I > am afraid that I had only browsed quickly through this dense document, please > accept my apologies for that. Please also note that I am not familiar with BIER. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > -- Abstract -- > I find the statement "Co-existence of BIER and BIER-TE forwarding in the same > domain is possible, for example by using separate BIER sub-domains (SDs)" quite > an oxymoron as co-existence in a single domain requires splitting the domain > into sub-domains. Suggest to rather mention sharing the BIFT-id address space > among BIER and BIER-TE. "BIER sub-domains" is not referring to a non-BIER-specific / generally applicapple operator method such as splitting up the network of one administrative domain into (virtually) non-overlapping sub-topologies of routers! If it was that, then i think that would be a tautology, not an oxymoron though. Instead, BIER sub-domains are a fundamental architectural/protocol element of BIER, mentioned 120 times in rfc8279. Each BIER packet belongs to a particular BIER sub-domain, so the sub-domain value must somehow (explicitly or implicitly) be signlled with the BIER packet. Typically this is via the bift-id field of the rfc8296 BIER header. The BIFT-id is just an rfc8296 construct, mentioned in rfc8279 only 5 times in reference to rfc8296. Therefore, the BIER-TE arch is also trying to refer primarily to the BIER architecture component sub-domain, and to the bift-id only in reference to rfc8296. Aka: I am sure BIER sub-domain is the right choice here. > In the statement "BIER-TE can also be a good fit to support multicast path > steering in Segment Routing (SR) networks" s/can also be a good fit/is shown to > be a good fit/ ? Even if section 6 is really light on the topic. Explicit suggestions how to improve section 6 welcome. The line of thought why it would be a good fit is IMHO very simple: SR is source routing with an in-packet path. BIER-TE is source-routing of multicast with of an in-packet tree. I thought the text does actually elaborate that well! I can not write "is shown", because that would require IMHO deployment experience of SR together with BIER. Instead we even had some animosity between SR and BIER proponents, and the text actually tries to start bridging that gap. > -- Section 1 -- > Please expand "BIFT" and "BFR" at first use as other BIER terms are expanded. Done. Thanks. *sigh*. I am sure i went through "first use - expand" more than once, but then its easily forgotten on individual review fixes later on. I wish there was a better tool for this problem. I went a bit more through the text trying to find cases where i may not have done this correctly (forgot quotes around expansion when defining abbreviation). > -- Section 2.4 -- > The blanket/broad statement that "Forwarding of BIER-TE is designed to easily > build/program common forwarding hardware with BIER." is it applicable to all > hardware handling BIER ? Or is it vendor specific ? Changed text to "is designed with the intent to easily". Of course, i do not know all the proprietary HW optimizations that may be done to implement BIER, so i can only judge from the efforts done on the design side: Primarily the goal was to have as few changes as possible betwen the rfc8279 BIER pseudocode and the MANDATORY BIER-TE pseudocode in this draft (the first pseudocode). That pseudocode should be even easier to implement than the BIER variant, because it removes the sequential dependencies between replications: BIER pseudocode updates a variable used across all replications, making e.g.: (distributed) egress linecard implementations more expensive. The optional features like ECMP, DNC and multiple adjacencies for a single bit-position are moderate additional complexity that should be able to attach to a shared core forwarding/replication code. But beyond that, the biggest argument in favor of "designed with intent to easily..." is the fact that BIER-TE continues to use the same fixed-length bitstring that BIER uses. This actually leads to all the complex options to reduce the number of total bits required to represent some part of the netork topology, shown primarily through section 5 (controller procedures to assign bits, bit-types) and the optional BIER-TE adjacencies that go along with that. If we would dare to go beyond the fixed-length/flat bitstring of BIER, then we would end up with much easier BIER-TE+?, which is what draft-eckert-bier-cgm2-rbs actually proposes). But that overall simplification/scalability enhancements come at the price of more complex forwarding plane parsing of the structured bitstring in the per-packet forwarding plane. > -- Section 3.2.1 -- > As BIER-TE is basically centralized in a control, "such YANG/Netconf/RestConf" > is a little hand waving. Does the BIER WG have already started work on this > control protocol ? Small correction: A centralized BIER-TE controller is just the "reference model" for the BIER-TE control plane (section 2.2 point 2.2). There is no reason to not implement at least a decentralized control plane, such as has been done historically for RSVP-TE: every headend-LSR (BFIR) calculating the path/trees for which it is the headend. For BIER-TE this would be quite attractive as an RSVP-TE/P2MP replacement - removes all the unwanted per-LSP signalling in the network. The text just does not discuss because it would be a lot of additional text, so arguably not the best thing to do for a generic architecture document. BIER (rfc8279) also only discusses the fully distributed (IGP) model, even though there may now be interest in a centralized controller option as well. Some thing (IGP is "reference model" for BIER). To your question: yes, there is now draft-ietf-bier-te-yang, and some other drafts for a bier-te control plane (with IGPs), e.g.: draft-chen-bier-te-isis > -- Section 4.2.3 -- > What is the "entropy parameter" ? where is it defined ? (to repeat myself, I am > not a BIER expert) if the entropy is part of the BIER header then strong > suggestion to s/entropy parameter/value of the entropy field of the BIER > header/. Great catch. I now actually copied the improved correct text almost straight out of rfc8279: | If the packet's encapsulation contains an entropy field, the entropy field SHOULD | be respected; two packets with the same value of the entropy field SHOULD be sent on | the same adjacency. (only difference is "adjacency" instead of "interface"). > -- Section 4.3 -- > Do the authors have an idea on how to share the BIFT-id address space among > BIER (which is decentralized AFAIK) and BIER-TE (which is centralized) without > overlapping and keeping the separation during all operations (including when > nodes/links appear/disappear) ? This is pretty independent of whether the control plane is centralized, decentralized or distributed for BIER and/or BIER-TE. Maybe think about it like co-existance of IP unicast and IP multicast. There we simply split up the IP address space. In BIER/BIER-TE it would be most easy to split up the sub-domain address space. For example the BIER and BIER-TE SD ranges could be configured on each BFR. When using rfc8296 encap, typically the SD value will be encoded and/or mapped to the bift-id. When using it with MPLS, the bift-id is actually an MPLS label, and the IGP is used to signal to the BFR neighbors the binding between label range and sub-domain. So far that exists for BIER, but draft-chen-bier-te-isis for example proposes the same for BIER-TE. And we work on/need YANG models as well.. Topology changes with MPLS are just like any other label re-binding in MPLS. When not using MPLS, but e.g.: BIER directly over ethernet, the SD could be a fixed part of the bift-id, so there would be no dynamic re-signaling required. > -- Section 6 -- > While discussing about SR, did the WG think about using RFC 8986 network > programming to achieve the same results as BIER-TE ? There is no stateless multicast/replication functionality in SR RFCs, and specifically RFC8986 is i think a red-herring, because we wanted solutions working for not only IPv6, but also MPLS (like BIER). And as far as i see it, RFC8986 is actually primarily about ingres/egres PE stuff, but not midpoint SIDs, which something like replication would be. So RFC8986 is to me more like another layer of the solution. It comes in very handy as part of the BIER packet payload header to support all the different services on top of BIER(-TE) replication. If we wanted to do something like BIER/BIER-TE with the approach of SRv6, we would need to encapsulate a whole tree in some modified SRH header, but with 128 bit per entry instead of 1 bit as we do in BIER/BIER-TE. That approach was never considered to be attractive by the BIER-WG because of what many of the early contributors learned from ca. year 2000 Small Group Multicast (SGM) (US Patent 7,978,718) (pretty much the same idea with IPv4 addresses). > Unsure whether the note about "BIER itself" brings any value in this BIER-TE document. > Unsure what the last § has to do with segment routing. > To be honest, this section is really light and the document would gain by > removing it. I am sorry that you feel that way. I really want this section to be useful to operators, and i think it basically is, but of course it can always be improved. Let me try to motivate to you better: SR is the most widely used or planned unicast forwarding technology in service provider networks. These too are the primary networks that BIER/BIER-TE targets (i think there are a lot more additional networks like in IoT, but we have too little participation of those entworks in IETF yet to know enough about the operational realities there). SR operators are naturally asking the question how BIER/BIER-TE relates to SR. Given how we can not simply rename BIER to SR-Multicast, we need to technically explain how it actually can very well fit the goal and designs of SR networks. And given how these questions on relationship where not answered so far for BIER either, this section also had to include a paragraph about BIER. Given the scope of this document (architecture), i think it is therefore appropriate to have such a more inspirational overview/comparison than either nothing or a deep/detailled technical review. My hope of course is that by mean of simply putting what BIER/BIER-TE does into the SR perspective it also helps operators coming from SR to easier understand the rest of the document and its benefits. > == NITS == > > Please use the all uppercase "YANG" rather than "Yang" as it is an acronym. Done. > -- Section 2.3 -- > s/that is forwarding plane is a simple extension/that its forwarding plane is a > simple extension/ ? Ack. Thanks a lot for the review! Hope my replies are satisfactory even though of our difference of opinion on some core point! Cheers Toerless
- [Bier] Éric Vyncke's No Objection on draft-ietf-b… Éric Vyncke via Datatracker
- Re: [Bier] Éric Vyncke's No Objection on draft-ie… Toerless Eckert