[Bier] AD Review of draft-ietf-bier-te-arch-10
Alvaro Retana <aretana.ietf@gmail.com> Tue, 20 July 2021 19:21 UTC
Return-Path: <aretana.ietf@gmail.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 8AF6F3A2F05; Tue, 20 Jul 2021 12:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Mt7XHs0nhMp8; Tue, 20 Jul 2021 12:21:39 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565603A2F02; Tue, 20 Jul 2021 12:21:38 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id c17so35874613ejk.13; Tue, 20 Jul 2021 12:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=koDHTnWOly/1Eq8DmYzZ6Bk1L+xuFCFWcOU7tWCknCM=; b=WsnR9PtQzClh7Sfdn2aN4UNBwt7HS+U/q248QRrIvQXI0GkR9Fs6Pk+Zi6eH7uHAiX LwJtnAqtj4b8Ue0qSUMWF6ByUpbKIgsx55/qpUv5vvaKNkV3lfT2P1mRQDCwlXgob6sx 5xOslMyXwGGHPyvOtU3mp5sBjMBVg7g6Tg1X8FW6GgJmq3u5K1pKiUm6Ic3pMHFjR023 1WoUaZkpE9rQjDwnJaVYXzuBj8gnNzAyz231S7WN1WINSIAWiOqXUVOuFMo8exDJvdDJ zRb23Eei7d/wkrAZ5vPaJKGbs+Uw97+r3P5ZeC+lxk4qPc5CvOdheAiGjTSjYL55p6jc Tmhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=koDHTnWOly/1Eq8DmYzZ6Bk1L+xuFCFWcOU7tWCknCM=; b=YB1pRnYITYWXML2TWs39MUStR0kZYjL4DNhOXLHIPMpVipUrWPGsxNDHaqla/0cD8n VBY7OsBQO4TkCPWKS9AT97NSRj3zLZ5ZNarQ1Wc+mW70QQ9tyAnaXdSHqK2lCr2OC36X tenoqqzj4mjuBrnefjLdZ5iXzzDQzDTKJmy2KFr+j3DIMG4jS3FV3t4SIEME1oTV2OYW mlNEgyrfJzYf8XxBivVQg/SHWGEwUbkSFWYbtLOBTcbr8+U6QlS+vZZwL31CsC4ECblG VmrdiiblQgEKy0q53Nqjs21hFqDrqPvkgKIYXm496b/VT3Pmsk1drx0TUrQbcT4wlVBN Q2vQ==
X-Gm-Message-State: AOAM530J+ZW1qO17o/1Wfq5zt519GO2ciPGI1uw+NxxYCGYTs41QEJta Pr5BjNmxEwSTr4IpqcNZQ/wS1ONu0PnRrj82KJH0aoQs/mA=
X-Google-Smtp-Source: ABdhPJw+qggs7vcHvlfH6Ssql+x86xxBWnns0wktewimsvhHNzk12QNY5PfBeBW5V+gKaDGUpCVdI/kN7sjE4JtzLcM=
X-Received: by 2002:a17:907:7293:: with SMTP id dt19mr34491900ejc.122.1626808891629; Tue, 20 Jul 2021 12:21:31 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Jul 2021 15:21:31 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
MIME-Version: 1.0
Date: Tue, 20 Jul 2021 15:21:31 -0400
Message-ID: <CAMMESsyGszotDPReWZKxCTZ3w6m_zz+3fhU0XUYMPo=DAS0d9w@mail.gmail.com>
To: draft-ietf-bier-te-arch@ietf.org
Cc: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, BIER WG Chairs <bier-chairs@ietf.org>, BIER WG <bier@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/O8hiYEay_fT7yZSeumyPivqmg7I>
Subject: [Bier] AD Review of draft-ietf-bier-te-arch-10
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: Tue, 20 Jul 2021 19:21:43 -0000
Hi! This is a quick review of -10. Most of the comments are minor or nits. Thanks! Alvaro. [Line numbers from idnits for -10.] ... 135 1. Overview 137 BIER-TE is based on architecture, terminology and packet formats with 138 BIER as described in [RFC8279] and [RFC8296]. This document 139 describes BIER-TE in the expectation that the reader is familiar with 140 these two documents. [minor] s/based on architecture, terminology and packet formats with BIER as described/based on the BIER architecture, terminology and packet formats with as described ... 180 o Section 5 describes operational considerations for the BIER-TE 181 controller, foremost how the BIER-TE controller can optimize the 182 use of BP by using specific type of BIER-TE adjacencies for 183 different type of topological situations, but also how to assign 184 bits to avoid loops and duplicates (which in BIER-TE does not come 185 for free), and finally how SI, sub-domains and BFR-ids can be 186 managed by a BIER-TE controller, examples and summary. [nit] s/by using specific type of BIER-TE adjacencies for different type of topological situations/by using specific BIER-TE adjacencies in different topological situations 188 o Section 6 concludes the technology specific sections of document 189 by further relating BIER-TE to Segment Routing (SR). [nit] s/of document/of the document ... 335 2.2. BIER-TE Topology and adjacencies ... 342 The BIER-TE Topology consists of the BIFTs of all the BFR and can 343 also be expressed as a directed graph where the edges are the 344 adjacencies between the BFR labelled with the BP used for the 345 adjacency. Adjacencies are naturally unidirectional. BP can be 346 reused across multiple adjacencies as long as this does not lead to 347 undesired duplicates or loops as explained further down in the text. [nit] s/between the BFR/between the BFRs ... 357 2.3. Relationship to BIER 359 BIER-TE is designed so that is forwarding plane is a simple extension 360 to the BIER forwarding plane, hence allowing for it to be added to 361 BIER deployments where it can be beneficial. [nit] s/is forwarding/its forwarding ... 370 1. The fundamental purpose of per-packet signaled packet 371 replication and delivery via a BitString. [nit] s/per-packet signaled packet replication/per-packet signaled replication ... 376 3. The supportable encapsulations, [RFC8296] or other (future) 377 encapsulations. [nit] s/supportable encapsulations, [RFC8296]/supported encapsulations [RFC8296] ... 412 1. BIRTs on BFR for BIER-TE are not required when using a BIER- 413 TE controller because the controller can directly populate 414 the BIFTs. In BIER, BIRTs are populated by the distributed 415 routing protocol support for BIER, allowing BFR to populate 416 their BIFTs locally from their BIRTs. Other BIER-TE control 417 plane or management plane options may introduce requirements 418 for BIRTs for BIER-TE BFR. [minor] Expand first occurrence of BIRT. 420 2. The BIER-TE layer forwarding plane does not require BFR to 421 have a unique BP and therefore also no unique BFR-id. See 422 for example See Section 5.1.3. [nit] s/require BFR/require a BFR ... 436 1. The BIER/BIER-TE packet header needs to allow addressing both 437 BIER and BIER-TE BIFT. Depending on the encapsulation 438 option, the same SD may or may not be reusable across BIER 439 and BIER-TE. See Section 4.3. In either case, a packet is 440 always only forwarded end-to-end via BIER or via BIER-TE 441 (ships in the nights forwarding). [nit] s/both BIER and BIER-TE BIFT/both the BIER and BIER-TE BIFTs 443 2. BIER-TE deployments will have to assign BFR-ids to BFR and 444 insert them into the BFR-id field of BIER packet headers as 445 BIER does, whenever the deployment uses (unchanged) 446 components developed for BIER that use BFR-id, such as 447 multicast flow overlays or BIER layer control plane elements. 448 See also Section 5.3.3. [nit] s/to BFR/to BFRs 450 2.4. Accelerated/Hardware forwarding comparison 452 Forwarding of BIER-TE is designed to easily build/program common 453 forwarding hardware with BIER. The pseudocode in Section 4.4 shows 454 how existing BIER/BIFT forwarding can be modified to support the 455 REQUIRED BIER-TE forwarding functionality, by using BIER BIFT's 456 "Forwarding Bit Mask" (F-BM): Only the clearing of bits to avoid 457 duplicate packets to a BFR neighbor is skipped in BIER-TE forwarding 458 because it is not necessary and could not be done when using BIER 459 F-BM. [major] s/REQUIRED BIER-TE forwarding/required BIER-TE forwarding In context, there is no normative action, just a statement of fact. Nonetheless, a reference to §4.6 would be nice. ... 501 3.2. The BIER-TE Control Plane ... 509 For BIER-TE, the control plane includes at minimum the following 510 functionality. [minor] It would be useful to point at the sections where each piece of functionality is described -- even if it is at just a high-level of granularity. ... 545 3.2.1. The BIER-TE Controller 547 Notwithstanding other options, this architecture describes the BIER 548 control plane as shown in Figure 3 to consists of: [nit] s/to consists/to consist 550 o A single centralized BIER-TE controller. [minor] Perhaps remove "single centralized" which gives the impression of single-point-of-failure/attack point -- where we all know that in general the controller may not be a single box, etc.. 552 o Data-models and protocols to communicate between controller and 553 BFR in step 1, such YANG/Netconf/RestConf. [?] Step 1? I think that you're referring to the list in the previous section -- please indicate there that they represent "steps". On second thought, it looks like only a couple of places refer back to the list as steps; maybe find an alternate way to refer to them. [minor] Only in "step 1"? There is some programmability-related work to be done in step 2. 555 o Protocols to communicate between controller and BFIR in step 2, 556 such as BIER-TE extensions for [RFC5440]. [minor] Same question...only step 2? It's not clear to me why (it any extensions are TBD) a PCE can't be used for step 1, and viceversa. ... 567 3.2.1.1. BIER-TE Topology discovery and creation 569 Step 1.1 includes network topology discovery and BIER-TE topology 570 creation. The latter describes the process by which a Controller 571 determines which routers are to be configured as BFR and the 572 adjacencies between them. [nit] s/as BFR/as BFRs ... 583 Dynamic creation of the BIER-TE topology can be as easy as mapping 584 the network topology 1:1 to the BIER-TE topology by assigning a BP 585 for every network subnet adjacency. In larger networks, it likely 586 involves more complex policy and optimization decisions including how 587 to minimize the number of BP required and how to assign BP across 588 different BitStrings to minimize the number of duplicate packets 589 across links when delivering an overlay flow to BFER using different 590 SIs/BitStrings. These topics are discussed in Section 5. [nit] s/number of BP/number of BPs [nit] s/assign BP/assign BPs ... 598 Communications between the BIER-TE Controller and BFRs (beside 599 topology discovery) is ideally via standardized protocols and data- 600 models such as Netconf/RestConf/Yang/PCEP. Vendor-specific CLI on 601 the BFRs is also an option (as in many other SDN solutions lacking 602 definition of standardized data model). [nit] s/standardized data model/standardized data models 604 3.2.1.2. Engineered Trees via BitStrings 606 In BIER, the same set of BFER in a single sub-domain is always 607 encoded as the same BitString. In BIER-TE, the BitString used to 608 reach the same set of BFER in the same sub-domain can be different 609 for different overlay flows because the BitString encodes the paths 610 towards the BFER, so the BitStrings from different BFIR to the same 611 set of BFER will often be different, and the BitString from the same 612 BFIR to the same set of BFER can different for different overlay 613 flows for policy reasons such as shortest path trees, Steiner trees 614 (minimum cost trees), diverse path trees for redundancy and so on. [nit] s/can different/can be different ... 640 3.3. The BIER-TE Forwarding Plane 642 The BIER-TE Forwarding Plane constitutes of the following components: [nit] s/constitutes of/is constituted by 644 1. On BFIR imposition of BIER header for packets from overlay flows. 645 This is driven by a combination of state established by the BIER- 646 TE control plane and/or the multicast flow overlay as explained 647 in Section 3.1. [nit] s/On BFIR/On a BFIR, [nit] s/of BIER header/of the BIER header 649 2. On BFR (including BFIR and BFER), forwarding/replication of BIER 650 packets according to their BitString as explained below and 651 optionally Entropy. Processing of other BIER header fields such 652 as DSCP is outside the scope of this document. [nit] s/On BFR/On a BFR [minor] "as explained below" A specific reference would be nice. [major] "Processing of other BIER header fields such as DSCP is outside the scope of this document." Better wording might be that it is unchanged. Is that the intent? 654 3. On BFER removal of BIER header and dispatching of the payload 655 according to state created by the BIER-TE control plane and/or 656 overlay layer. [nit] s/On BFER/On a BFER, ... 746 4.1. The Bit Index Forwarding Table (BIFT) ... 756 In [RFC8279], Figure 2, indices into the BIFT are both SI:BitString 757 and BFR-id, where BitString is indicating a BP: BFR-id = SI * 2^BSL + 758 BP. As shown in Figure 4, in BIER-TE, only SI:BP are used as indices 759 into a BIFT because they identify adjacencies and not BFR. [minor] I think that the formula makes things sound more complicated. Suggestion> Figure 2 of [rfc8279] uses both SI:BitString and BFR-id as indices into the BIFT. As shown in Figure 4 (below), in BIER-TE only SI:BP are used as indices into a BIFT because they identify adjacencies and not BFR. ... 835 4.2.3. ECMP ... 840 A BIER-TE "Equal Cost Multipath" (ECMP) adjacency has a list of two 841 or more non-ECMP adjacencies and a seed parameter. When a BIER-TE 842 packet is copied onto such an ECMP adjacency, an implementation 843 specific so-called hash function will select one out of the lists 844 adjacencies to which the packet is forwarded. This ECMP hash 845 function MUST select the same adjacency from that list for all 846 packets with the same entropy parameter. The seed parameter allows 847 to design hash functions that are easy to implement at high speed 848 without running into polarization issues across multiple consecutive 849 ECMP hops. See Section 5.1.7 for more explanations. [minor] s/non-ECMP/ECMP ... 861 4.3. Encapsulation / Co-existence with BIER ... 881 With MPLS, it is also possible to reuse the same SD space for both 882 BIER-TE and BIER, so that the same SD has both a BIER BIFT and 883 according range of BIFT-ids and a disjoint BIER-TE BIFT and non- 884 overlapping range of BIFT-ids. [minor] s/and according range of BIFT-ids/with a corresponding range of BIFT-ids, [nit] s/and non-overlapping/and a non-overlapping 886 When a fixed mapping from BSL, SD, SI is used without specifically 887 distinguishing BIER and BIER-TE, such as proposed for non-MPLS 888 forwarding with [RFC8296] in [I-D.ietf-bier-non-mpls-bift-encoding] 889 revision 04, section 5., then it is necessary to allocate disjoint 890 SDs to BIER and BIER-TE BIFT so that both can be addressed by the 891 BIFT-ids. The encoding proposed in section 6. of the same document 892 does not statically encode BSL or SD into the BIFT-id, but allows for 893 a mapping, and hence could provide for the same freedom as when MPLS 894 is being used (same or different SD for BIER/BIER-TE). [nit] s/5.,/5, [nit] s/BIER and BIER-TE BIFT/BIER and BIER-TE BIFTs ... 908 4.4. BIER-TE Forwarding Pseudocode ... 914 void ForwardBitMaskPacket_withTE (Packet) 915 { 916 SI=GetPacketSI(Packet); 917 Offset=SI*BitStringLength; 918 for (Index = GetFirstbit position(Packet->BitString); Index ; 919 Index = GetNextbit position(Packet->BitString, Index)) { 920 F-BM = BIFT[Index+Offset]->F-BM; 921 if (!F-BM) continue; [3] 922 BFR-NBR = BIFT[Index+Offset]->BFR-NBR; 923 PacketCopy = Copy(Packet); 924 PacketCopy->BitString &= F-BM; [2] 925 PacketSend(PacketCopy, BFR-NBR); 926 // The following must not be done for BIER-TE: 927 // Packet->BitString &= ~F-BM; [1] 928 } 929 } [nit] s/GetFirstbit position/GetFirstbitPosition [nit] s/GetNextbit position/GetNextbitPosition ... 974 This Forwarding Pseudocode can support the REQUIRED BIER-TE 975 forwarding functions (see Section 4.6), forward_connected, 976 forward_routed() and local decap, but not the RECOMMENDED functions 977 DNC flag and multiple adjacencies per bit nor the OPTIONAL function, 978 ECMP adjacencies. The DNC flag cannot be supported when using only 979 [1] to mask bits. [major] s/REQUIRED...RECOMMENDED...OPTIONAL/required...recommended...optional This text is not normative, just a description. ... 1144 4.6. BFR Requirements for BIER-TE forwarding 1146 BFR MUST support to configure the BIFT of sub-domains so that they 1147 use BIER-TE forwarding rules instead of BIER forwarding rules. Every 1148 BP in the BIFT MUST support to have zero or one adjacency. 1149 Forwarding MUST support the adjacency types forward_connected() with 1150 clear DNC flag, forward_routed() and local_decap. As explained in 1151 Section 4.4, these REQUIRED BIER-TE forwarding functions can be 1152 implement via the same Forwarding Pseudocode as BIER forwarding 1153 except for one modification (skipping one masking with F-BM). [minor] s/support to configure/support configuring [nit] s/clear DNC flag/a clear DNC flag [major] s/REQUIRED/required Not a normative statement. ... 1159 BIER-TE forwarding SHOULD support more than one adjacency on a bit. 1160 This allows to save bits in hub&spoke scenarios (see Section 5.1.5). [nit] s/hub&spoke/hub and spoke 1162 BIER-TE forwarding MAY support ECMP adjacencies to save bits in ECMP 1163 scenarios, see Section 5.1.7 for an example. This is a MAY 1164 requirement, because the deployment importance of ECMP adjacencies 1165 for BIER-TE is unclear as one can also leverage ECMP of the routing 1166 underlay via forwarded_routed adjacencies and/or might prefer to have 1167 more explicit control of the path chosen via explicit BP/adjacencies 1168 for each ECMP path alternative. [major] s/a MAY requirement/an optional requirement [minor] s/the deployment importance of ECMP adjacencies for BIER-TE is unclear as/for ECMP deployments using BIER-TE ... 1183 5.1.1. P2P Links 1185 On a P2P link that connects two BFR, the same bit position can be 1186 used on both BFR for the adjacency to the neighboring BFR. A P2P 1187 link requires therefore only one bit position. [nit] s/two BFR/two BFRs [nit] s/both BFR/both BFRs ... 1194 5.1.3. Leaf BFERs ... 1209 A leaf BFERs is one where incoming BIER-TE packets never need to be 1210 forwarded to another BFR but are only sent to the BFER to exit the 1211 BIER-TE domain. For example, in networks where Provider Edge (PE) 1212 router are spokes connected to Provider (P) routers, those PEs are 1213 Leaf BFERs unless there is a U-turn between two PEs. [nit] s/A leaf BFERs/A leaf BFER ... 1492 5.1.9. Reuse of bit positions (without DNC) ... 1544 Figure 17: Reuse of BP 1546 Reuse may also save BPs in larger topologies. Consider the topology 1547 shown in Figure 20. A BFIR/sender (e.g.: video headend) is attached 1548 to area 1, and area 2...6 contain receivers/BFER. Assume each area 1549 had a distribution ring, each with two BPs to indicate the direction 1550 (as explained before). These two BPs could be reused across the 5 1551 areas. Packets would be replicated through other BPs for the Core to 1552 the desired subset of areas, and once a packet copy reaches the ring 1553 of the area, the two ring BPs come into play. This reuse is a case 1554 of (B), but it limits the topology choices: Packets can only flow 1555 around the same direction in the rings of all areas. This may or may 1556 not be acceptable based on the desired path steering options: If 1557 resilient transmission is the path engineering goal, then it is 1558 likely a good optimization, if the bandwidth of each ring was to be 1559 optimized separately, it would not be a good limitation. [minor] s/Figure 20/Figure 17 1561 5.1.10. Summary of BP optimizations ... 1603 Note that the described list of optimizations is not exhaustive. 1604 Especially when the set of required path steering choices is limited 1605 and the set of possible subsets of BFERs that should be able to 1606 receive traffic is limited, further optimizations of BP are possible. 1607 The hub & spoke optimization is a simple example of such traffic 1608 pattern dependent optimizations. [nit] s/hub & spoke/hub and spoke ... 1757 5.3.3. Assigning BFR-id with BIER-TE 1759 BIER-TE forwarding does not use the BFR-id, not does it require for 1760 the BFR-id field of the BIER header to be set to a particular value. 1761 However, other parts of a BIER-TE deployment may need a BFR-id, 1762 specifically overlay signaling, and in that case BFR need to also 1763 have BFR-ids for BIER-TE SDs. [nit] s/BFR need/BFRs need 1765 For example, for BIER overlay signaling, BFIR need to have a BFR-id, 1766 because this BFIR BFR-id is carried in the BFR-id field of the BIER 1767 header to indicate to the overlay signaling on the receiving BFER 1768 which BFIR originated the packet. [nit] s/BFIR need/BFIRs need ... 1781 As explained in Section 5.1.3, leaf BFERs do not need such a unique 1782 local_decap() adjacency, likewise, BFIR who are not also BFER may not 1783 have a unique local_decap() adjacency either. For all those BFIR and 1784 (leaf) BFER, the controller needs to determine unique BFR-ids that do 1785 not collide with the BFR-ids derived from the non-leaf BFER 1786 local_decap() BPs. [nit] s/BFIR who are not also BFER/BFIRs that are not also BFERs [nit] s/BFIR and (leaf) BFER/BFIRs and (leaf) BFERs 1788 While this document defines no requirements how to allocate such BFR- 1789 id, a simple option is to derive it from the (SI,BP) of an adjacency 1790 that is unique to the BFR in question. For a BFIR this can be he 1791 first adjacency only populated on this BFIR, for a leaf-BFER, this 1792 could be the first BP with an adjacency towards that BFER. [nit] s/requirements how/requirements on how [nit] s/can be he/can be the 1794 5.3.4. Mapping from BFR to BitStrings with BIER-TE 1796 In BIER, applications of the flow overlay on a BFIR can calculate the 1797 (SI,BP) of a BFER from the BFR-id of the BFER and can therefore 1798 easily determine the BitStrings for a BIER packet to a set of BFER 1799 with known BFR-ids. [nit] s/set of BFER/set of BFERs ... 1817 If "independent branches" are used, the BIER-TE Controller can signal 1818 to the BFIR flow overlay for every BFER an SI:BitString that 1819 represents the branch to that BFER. The flow overlay on the BIFR can 1820 then independently of the controller calculate the SI:BitString for 1821 all desired BFER by OR'ing their BitStrings. This allows for flow 1822 overlay applications to operate independently from the controller 1823 whenever it needs to determine which subset of BFERs need to receive 1824 a particular packet. [nit] s/all desired BFER/all desired BFERs ... 1838 Communications between BFIR flow overlay and BIER-TE controller 1839 requires some way to identify BFER. If BFR-ids are used in the 1840 deployment, as outlined in Section 5.3.3, then those are the natural 1841 BFR identifier. If BFR-ids are not used, then any other unique 1842 identifier, such as the BFR-prefix of the BFR as of [RFC8279] could 1843 be used. [nit] s/BIER-TE controller/the BIER-TE controller [nit] s/identify BFER/identify the BFER [minor] s/BFR-prefix of the BFR as of [RFC8279]/BFR-prefix of the BFR [RFC8279] ... 2031 7. Security Considerations ... 2046 The reference model for the BIER-TE layer control plane is a BIER-TE 2047 controller. When such a controller is used, impairment of individual 2048 BFR in a domain causes no impairment of the BIER-TE control plane on 2049 other BFR. If a routing protocol is used to support forward_routed() 2050 adjacencies, then this is still an attack vector as in BIER, but only 2051 for BIER-TE forward_routed() adjacencies, and no other adjacencies. [nit] s/of individual/of an individual [nit] s/other BFR/other BFRs [EoR -10]
- [Bier] AD Review of draft-ietf-bier-te-arch-10 Alvaro Retana
- [Bier] HELP: truncated email (was: Re: AD Review … Toerless Eckert
- Re: [Bier] HELP: truncated email (was: Re: AD Rev… Pascal Thubert (pthubert)
- Re: [Bier] HELP: truncated email (was: Re: AD Rev… Alvaro Retana
- Re: [Bier] AD Review of draft-ietf-bier-te-arch-10 Toerless Eckert