From nobody Tue Jul 20 12:21:43 2021 Return-Path: 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 MIME-Version: 1.0 Date: Tue, 20 Jul 2021 15:21:31 -0400 Message-ID: To: draft-ietf-bier-te-arch@ietf.org Cc: "Gengxuesong (Geng Xuesong)" , BIER WG Chairs , BIER WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 19:21:43 -0000 Hi! This is a quick review of -10. =C2=A0Most of the comments are minor or nits= . Thanks! Alvaro. [Line numbers from idnits for -10.] ... 135 1. =C2=A0Overview 137 =C2=A0 BIER-TE is based on architecture, terminology and packet format= s with 138 =C2=A0 BIER as described in [RFC8279] and [RFC8296]. =C2=A0This docume= nt 139 =C2=A0 describes BIER-TE in the expectation that the reader is familia= r with 140 =C2=A0 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 =C2=A0 o =C2=A0Section 5 describes operational considerations for the = BIER-TE 181 =C2=A0 =C2=A0 =C2=A0controller, foremost how the BIER-TE controller ca= n optimize the 182 =C2=A0 =C2=A0 =C2=A0use of BP by using specific type of BIER-TE adjace= ncies for 183 =C2=A0 =C2=A0 =C2=A0different type of topological situations, but also= how to assign 184 =C2=A0 =C2=A0 =C2=A0bits to avoid loops and duplicates (which in BIER-= TE does not come 185 =C2=A0 =C2=A0 =C2=A0for free), and finally how SI, sub-domains and BFR= -ids can be 186 =C2=A0 =C2=A0 =C2=A0managed by a BIER-TE controller, examples and summ= ary. [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 =C2=A0 o =C2=A0Section 6 concludes the technology specific sections of= document 189 =C2=A0 =C2=A0 =C2=A0by further relating BIER-TE to Segment Routing (SR= ). [nit] s/of document/of the document ... 335 2.2. =C2=A0BIER-TE Topology and adjacencies ... 342 =C2=A0 The BIER-TE Topology consists of the BIFTs of all the BFR and c= an 343 =C2=A0 also be expressed as a directed graph where the edges are the 344 =C2=A0 adjacencies between the BFR labelled with the BP used for the 345 =C2=A0 adjacency. =C2=A0Adjacencies are naturally unidirectional. =C2= =A0BP can be 346 =C2=A0 reused across multiple adjacencies as long as this does not lea= d to 347 =C2=A0 undesired duplicates or loops as explained further down in the = text. [nit] s/between the BFR/between the BFRs ... 357 2.3. =C2=A0Relationship to BIER 359 =C2=A0 BIER-TE is designed so that is forwarding plane is a simple ext= ension 360 =C2=A0 to the BIER forwarding plane, hence allowing for it to be added= to 361 =C2=A0 BIER deployments where it can be beneficial. [nit] s/is forwarding/its forwarding ... 370 =C2=A0 =C2=A0 =C2=A0 1. =C2=A0The fundamental purpose of per-packet si= gnaled packet 371 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replication and delivery via a BitS= tring. [nit] s/per-packet signaled packet replication/per-packet signaled replicat= ion ... 376 =C2=A0 =C2=A0 =C2=A0 3. =C2=A0The supportable encapsulations, [RFC8296= ] or other (future) 377 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulations. [nit] s/supportable encapsulations, [RFC8296]/supported encapsulations [RFC= 8296] ... 412 =C2=A0 =C2=A0 =C2=A0 1. =C2=A0BIRTs on BFR for BIER-TE are not require= d when using a BIER- 413 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TE controller because the controlle= r can directly populate 414 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the BIFTs. =C2=A0In BIER, BIRTs are= populated by the distributed 415 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 routing protocol support for BIER, = allowing BFR to populate 416 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 their BIFTs locally from their BIRT= s. =C2=A0Other BIER-TE control 417 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 plane or management plane options m= ay introduce requirements 418 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for BIRTs for BIER-TE BFR. [minor] Expand first occurrence of BIRT. 420 =C2=A0 =C2=A0 =C2=A0 2. =C2=A0The BIER-TE layer forwarding plane does = not require BFR to 421 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have a unique BP and therefore also= no unique BFR-id. =C2=A0See 422 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for example See Section 5.1.3. [nit] s/require BFR/require a BFR ... 436 =C2=A0 =C2=A0 =C2=A0 1. =C2=A0The BIER/BIER-TE packet header needs to = allow addressing both 437 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BIER and BIER-TE BIFT. =C2=A0Depend= ing on the encapsulation 438 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 option, the same SD may or may not = be reusable across BIER 439 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and BIER-TE. =C2=A0See Section 4.3.= =C2=A0In either case, a packet is 440 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 always only forwarded end-to-end vi= a BIER or via BIER-TE 441 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ships in the nights forwarding). [nit] s/both BIER and BIER-TE BIFT/both the BIER and BIER-TE BIFTs 443 =C2=A0 =C2=A0 =C2=A0 2. =C2=A0BIER-TE deployments will have to assign = BFR-ids to BFR and 444 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 insert them into the BFR-id field o= f BIER packet headers as 445 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BIER does, whenever the deployment = uses (unchanged) 446 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 components developed for BIER that = use BFR-id, such as 447 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multicast flow overlays or BIER lay= er control plane elements. 448 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 See also Section 5.3.3. [nit] s/to BFR/to BFRs 450 2.4. =C2=A0Accelerated/Hardware forwarding comparison 452 =C2=A0 Forwarding of BIER-TE is designed to easily build/program commo= n 453 =C2=A0 forwarding hardware with BIER. =C2=A0The pseudocode in Section = 4.4 shows 454 =C2=A0 how existing BIER/BIFT forwarding can be modified to support th= e 455 =C2=A0 REQUIRED BIER-TE forwarding functionality, by using BIER BIFT's 456 =C2=A0 "Forwarding Bit Mask" (F-BM): Only the clearing of bits to avoi= d 457 =C2=A0 duplicate packets to a BFR neighbor is skipped in BIER-TE forwa= rding 458 =C2=A0 because it is not necessary and could not be done when using BI= ER 459 =C2=A0 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 =C2=A74.6 would be nice. ... 501 3.2. =C2=A0The BIER-TE Control Plane ... 509 =C2=A0 For BIER-TE, the control plane includes at minimum the followin= g 510 =C2=A0 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. =C2=A0The BIER-TE Controller 547 =C2=A0 Notwithstanding other options, this architecture describes the = BIER 548 =C2=A0 control plane as shown in Figure 3 to consists of: [nit] s/to consists/to consist 550 =C2=A0 o =C2=A0A 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 =C2=A0 o =C2=A0Data-models and protocols to communicate between contro= ller and 553 =C2=A0 =C2=A0 =C2=A0BFR in step 1, such YANG/Netconf/RestConf. [?] Step 1? =C2=A0I think that you're referring to the list in the previous section -- please indicate there that they represent "steps". =C2=A0On 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"? =C2=A0There is some programmability-related work to be done in step 2. 555 =C2=A0 o =C2=A0Protocols to communicate between controller and BFIR in= step 2, 556 =C2=A0 =C2=A0 =C2=A0such as BIER-TE extensions for [RFC5440]. [minor] Same question...only step 2? =C2=A0 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. =C2=A0BIER-TE Topology discovery and creation 569 =C2=A0 Step 1.1 includes network topology discovery and BIER-TE topolo= gy 570 =C2=A0 creation. =C2=A0The latter describes the process by which a Con= troller 571 =C2=A0 determines which routers are to be configured as BFR and the 572 =C2=A0 adjacencies between them. [nit] s/as BFR/as BFRs ... 583 =C2=A0 Dynamic creation of the BIER-TE topology can be as easy as mapp= ing 584 =C2=A0 the network topology 1:1 to the BIER-TE topology by assigning a= BP 585 =C2=A0 for every network subnet adjacency. =C2=A0In larger networks, i= t likely 586 =C2=A0 involves more complex policy and optimization decisions includi= ng how 587 =C2=A0 to minimize the number of BP required and how to assign BP acro= ss 588 =C2=A0 different BitStrings to minimize the number of duplicate packet= s 589 =C2=A0 across links when delivering an overlay flow to BFER using diff= erent 590 =C2=A0 SIs/BitStrings. =C2=A0These topics are discussed in Section 5. [nit] s/number of BP/number of BPs [nit] s/assign BP/assign BPs ... 598 =C2=A0 Communications between the BIER-TE Controller and BFRs (beside 599 =C2=A0 topology discovery) is ideally via standardized protocols and d= ata- 600 =C2=A0 models such as Netconf/RestConf/Yang/PCEP. =C2=A0Vendor-specifi= c CLI on 601 =C2=A0 the BFRs is also an option (as in many other SDN solutions lack= ing 602 =C2=A0 definition of standardized data model). [nit] s/standardized data model/standardized data models 604 3.2.1.2. =C2=A0Engineered Trees via BitStrings 606 =C2=A0 In BIER, the same set of BFER in a single sub-domain is always 607 =C2=A0 encoded as the same BitString. =C2=A0In BIER-TE, the BitString = used to 608 =C2=A0 reach the same set of BFER in the same sub-domain can be differ= ent 609 =C2=A0 for different overlay flows because the BitString encodes the p= aths 610 =C2=A0 towards the BFER, so the BitStrings from different BFIR to the = same 611 =C2=A0 set of BFER will often be different, and the BitString from the= same 612 =C2=A0 BFIR to the same set of BFER can different for different overla= y 613 =C2=A0 flows for policy reasons such as shortest path trees, Steiner t= rees 614 =C2=A0 (minimum cost trees), diverse path trees for redundancy and so = on. [nit] s/can different/can be different ... 640 3.3. =C2=A0The BIER-TE Forwarding Plane 642 =C2=A0 The BIER-TE Forwarding Plane constitutes of the following compo= nents: [nit] s/constitutes of/is constituted by 644 =C2=A0 1. =C2=A0On BFIR imposition of BIER header for packets from ove= rlay flows. 645 =C2=A0 =C2=A0 =C2=A0 This is driven by a combination of state establis= hed by the BIER- 646 =C2=A0 =C2=A0 =C2=A0 TE control plane and/or the multicast flow overla= y as explained 647 =C2=A0 =C2=A0 =C2=A0 in Section 3.1. [nit] s/On BFIR/On a BFIR, [nit] s/of BIER header/of the BIER header 649 =C2=A0 2. =C2=A0On BFR (including BFIR and BFER), forwarding/replicati= on of BIER 650 =C2=A0 =C2=A0 =C2=A0 packets according to their BitString as explained= below and 651 =C2=A0 =C2=A0 =C2=A0 optionally Entropy. =C2=A0Processing of other BIE= R header fields such 652 =C2=A0 =C2=A0 =C2=A0 as DSCP is outside the scope of this document. [nit] s/On BFR/On a BFR [minor] "as explained below" =C2=A0 A specific reference would be nice. [major] "Processing of other BIER header fields such as DSCP is outside the scope of this document." =C2=A0 Better wording might be that it is unchanged. =C2=A0Is that the intent? 654 =C2=A0 3. =C2=A0On BFER removal of BIER header and dispatching of the = payload 655 =C2=A0 =C2=A0 =C2=A0 according to state created by the BIER-TE control= plane and/or 656 =C2=A0 =C2=A0 =C2=A0 overlay layer. [nit] s/On BFER/On a BFER, ... 746 4.1. =C2=A0The Bit Index Forwarding Table (BIFT) ... 756 =C2=A0 In [RFC8279], Figure 2, indices into the BIFT are both SI:BitSt= ring 757 =C2=A0 and BFR-id, where BitString is indicating a BP: BFR-id =3D SI *= 2^BSL + 758 =C2=A0 BP. =C2=A0As shown in Figure 4, in BIER-TE, only SI:BP are used= as indices 759 =C2=A0 into a BIFT because they identify adjacencies and not BFR. [minor] I think that the formula makes things sound more complicated. Suggestion> =C2=A0 =C2=A0Figure 2 of [rfc8279] uses both SI:BitString and BFR-id as ind= ices into =C2=A0 =C2=A0the BIFT. =C2=A0As shown in Figure 4 (below), in BIER-TE only = SI:BP are used =C2=A0 =C2=A0as indices into a BIFT because they identify adjacencies and n= ot BFR. ... 835 4.2.3. =C2=A0ECMP ... 840 =C2=A0 A BIER-TE "Equal Cost Multipath" (ECMP) adjacency has a list of= two 841 =C2=A0 or more non-ECMP adjacencies and a seed parameter. =C2=A0When a= BIER-TE 842 =C2=A0 packet is copied onto such an ECMP adjacency, an implementation 843 =C2=A0 specific so-called hash function will select one out of the lis= ts 844 =C2=A0 adjacencies to which the packet is forwarded. =C2=A0This ECMP h= ash 845 =C2=A0 function MUST select the same adjacency from that list for all 846 =C2=A0 packets with the same entropy parameter. =C2=A0The seed paramet= er allows 847 =C2=A0 to design hash functions that are easy to implement at high spe= ed 848 =C2=A0 without running into polarization issues across multiple consec= utive 849 =C2=A0 ECMP hops. =C2=A0See Section 5.1.7 for more explanations. [minor] s/non-ECMP/ECMP ... 861 4.3. =C2=A0Encapsulation / Co-existence with BIER ... 881 =C2=A0 With MPLS, it is also possible to reuse the same SD space for b= oth 882 =C2=A0 BIER-TE and BIER, so that the same SD has both a BIER BIFT and 883 =C2=A0 according range of BIFT-ids and a disjoint BIER-TE BIFT and non= - 884 =C2=A0 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 =C2=A0 When a fixed mapping from BSL, SD, SI is used without specifica= lly 887 =C2=A0 distinguishing BIER and BIER-TE, such as proposed for non-MPLS 888 =C2=A0 forwarding with [RFC8296] in [I-D.ietf-bier-non-mpls-bift-encod= ing] 889 =C2=A0 revision 04, section 5., then it is necessary to allocate disjo= int 890 =C2=A0 SDs to BIER and BIER-TE BIFT so that both can be addressed by t= he 891 =C2=A0 BIFT-ids. =C2=A0The encoding proposed in section 6. of the same= document 892 =C2=A0 does not statically encode BSL or SD into the BIFT-id, but allo= ws for 893 =C2=A0 a mapping, and hence could provide for the same freedom as when= MPLS 894 =C2=A0 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. =C2=A0BIER-TE Forwarding Pseudocode ... 914 =C2=A0 =C2=A0 =C2=A0void ForwardBitMaskPacket_withTE (Packet) 915 =C2=A0 =C2=A0 =C2=A0{ 916 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SI=3DGetPacketSI(Packet); 917 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Offset=3DSI*BitStringLength; 918 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for (Index =3D GetFirstbit position(= Packet->BitString); Index ; 919 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Index =3D GetNextbit = position(Packet->BitString, Index)) { 920 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0F-BM =3D BIFT[Index+Of= fset]->F-BM; 921 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!F-BM) continue; = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0[3] 922 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BFR-NBR =3D BIFT[Index= +Offset]->BFR-NBR; 923 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PacketCopy =3D Copy(Pa= cket); 924 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PacketCopy->BitString = &=3D F-BM; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[2= ] 925 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PacketSend(PacketCopy,= BFR-NBR); 926 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// The following must = not be done for BIER-TE: 927 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Packet->BitString &= =3D ~F-BM; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[1= ] 928 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} 929 =C2=A0 =C2=A0 =C2=A0} [nit] s/GetFirstbit position/GetFirstbitPosition [nit] s/GetNextbit position/GetNextbitPosition ... 974 =C2=A0 This Forwarding Pseudocode can support the REQUIRED BIER-TE 975 =C2=A0 forwarding functions (see Section 4.6), forward_connected, 976 =C2=A0 forward_routed() and local decap, but not the RECOMMENDED funct= ions 977 =C2=A0 DNC flag and multiple adjacencies per bit nor the OPTIONAL func= tion, 978 =C2=A0 ECMP adjacencies. =C2=A0The DNC flag cannot be supported when u= sing only 979 =C2=A0 [1] to mask bits. [major] s/REQUIRED...RECOMMENDED...OPTIONAL/required...recommended...option= al This text is not normative, just a description. ... 1144 4.6. =C2=A0BFR Requirements for BIER-TE forwarding 1146 =C2=A0 BFR MUST support to configure the BIFT of sub-domains so that = they 1147 =C2=A0 use BIER-TE forwarding rules instead of BIER forwarding rules.= =C2=A0Every 1148 =C2=A0 BP in the BIFT MUST support to have zero or one adjacency. 1149 =C2=A0 Forwarding MUST support the adjacency types forward_connected(= ) with 1150 =C2=A0 clear DNC flag, forward_routed() and local_decap. =C2=A0As exp= lained in 1151 =C2=A0 Section 4.4, these REQUIRED BIER-TE forwarding functions can b= e 1152 =C2=A0 implement via the same Forwarding Pseudocode as BIER forwardin= g 1153 =C2=A0 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 =C2=A0 BIER-TE forwarding SHOULD support more than one adjacency on a= bit. 1160 =C2=A0 This allows to save bits in hub&spoke scenarios (see Section 5= .1.5). [nit] s/hub&spoke/hub and spoke 1162 =C2=A0 BIER-TE forwarding MAY support ECMP adjacencies to save bits i= n ECMP 1163 =C2=A0 scenarios, see Section 5.1.7 for an example. =C2=A0This is a M= AY 1164 =C2=A0 requirement, because the deployment importance of ECMP adjacen= cies 1165 =C2=A0 for BIER-TE is unclear as one can also leverage ECMP of the ro= uting 1166 =C2=A0 underlay via forwarded_routed adjacencies and/or might prefer = to have 1167 =C2=A0 more explicit control of the path chosen via explicit BP/adjac= encies 1168 =C2=A0 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. =C2=A0P2P Links 1185 =C2=A0 On a P2P link that connects two BFR, the same bit position can= be 1186 =C2=A0 used on both BFR for the adjacency to the neighboring BFR. =C2= =A0A P2P 1187 =C2=A0 link requires therefore only one bit position. [nit] s/two BFR/two BFRs [nit] s/both BFR/both BFRs ... 1194 5.1.3. =C2=A0Leaf BFERs ... 1209 =C2=A0 A leaf BFERs is one where incoming BIER-TE packets never need = to be 1210 =C2=A0 forwarded to another BFR but are only sent to the BFER to exit= the 1211 =C2=A0 BIER-TE domain. =C2=A0For example, in networks where Provider = Edge (PE) 1212 =C2=A0 router are spokes connected to Provider (P) routers, those PEs= are 1213 =C2=A0 Leaf BFERs unless there is a U-turn between two PEs. [nit] s/A leaf BFERs/A leaf BFER ... 1492 5.1.9. =C2=A0Reuse of bit positions (without DNC) ... 1544 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0Figure 17: Reuse of BP 1546 =C2=A0 Reuse may also save BPs in larger topologies. =C2=A0Consider t= he topology 1547 =C2=A0 shown in Figure 20. =C2=A0A BFIR/sender (e.g.: video headend) = is attached 1548 =C2=A0 to area 1, and area 2...6 contain receivers/BFER. =C2=A0Assume= each area 1549 =C2=A0 had a distribution ring, each with two BPs to indicate the dir= ection 1550 =C2=A0 (as explained before). =C2=A0These two BPs could be reused acr= oss the 5 1551 =C2=A0 areas. =C2=A0Packets would be replicated through other BPs for= the Core to 1552 =C2=A0 the desired subset of areas, and once a packet copy reaches th= e ring 1553 =C2=A0 of the area, the two ring BPs come into play. =C2=A0This reuse= is a case 1554 =C2=A0 of (B), but it limits the topology choices: Packets can only f= low 1555 =C2=A0 around the same direction in the rings of all areas. =C2=A0Thi= s may or may 1556 =C2=A0 not be acceptable based on the desired path steering options: = If 1557 =C2=A0 resilient transmission is the path engineering goal, then it i= s 1558 =C2=A0 likely a good optimization, if the bandwidth of each ring was = to be 1559 =C2=A0 optimized separately, it would not be a good limitation. [minor] s/Figure 20/Figure 17 1561 5.1.10. =C2=A0Summary of BP optimizations ... 1603 =C2=A0 Note that the described list of optimizations is not exhaustiv= e. 1604 =C2=A0 Especially when the set of required path steering choices is l= imited 1605 =C2=A0 and the set of possible subsets of BFERs that should be able t= o 1606 =C2=A0 receive traffic is limited, further optimizations of BP are po= ssible. 1607 =C2=A0 The hub & spoke optimization is a simple example of such traff= ic 1608 =C2=A0 pattern dependent optimizations. [nit] s/hub & spoke/hub and spoke ... 1757 5.3.3. =C2=A0Assigning BFR-id with BIER-TE 1759 =C2=A0 BIER-TE forwarding does not use the BFR-id, not does it requir= e for 1760 =C2=A0 the BFR-id field of the BIER header to be set to a particular = value. 1761 =C2=A0 However, other parts of a BIER-TE deployment may need a BFR-id= , 1762 =C2=A0 specifically overlay signaling, and in that case BFR need to a= lso 1763 =C2=A0 have BFR-ids for BIER-TE SDs. [nit] s/BFR need/BFRs need 1765 =C2=A0 For example, for BIER overlay signaling, BFIR need to have a B= FR-id, 1766 =C2=A0 because this BFIR BFR-id is carried in the BFR-id field of the= BIER 1767 =C2=A0 header to indicate to the overlay signaling on the receiving B= FER 1768 =C2=A0 which BFIR originated the packet. [nit] s/BFIR need/BFIRs need ... 1781 =C2=A0 As explained in Section 5.1.3, leaf BFERs do not need such a u= nique 1782 =C2=A0 local_decap() adjacency, likewise, BFIR who are not also BFER = may not 1783 =C2=A0 have a unique local_decap() adjacency either. =C2=A0For all th= ose BFIR and 1784 =C2=A0 (leaf) BFER, the controller needs to determine unique BFR-ids = that do 1785 =C2=A0 not collide with the BFR-ids derived from the non-leaf BFER 1786 =C2=A0 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 =C2=A0 While this document defines no requirements how to allocate su= ch BFR- 1789 =C2=A0 id, a simple option is to derive it from the (SI,BP) of an adj= acency 1790 =C2=A0 that is unique to the BFR in question. =C2=A0For a BFIR this c= an be he 1791 =C2=A0 first adjacency only populated on this BFIR, for a leaf-BFER, = this 1792 =C2=A0 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. =C2=A0Mapping from BFR to BitStrings with BIER-TE 1796 =C2=A0 In BIER, applications of the flow overlay on a BFIR can calcul= ate the 1797 =C2=A0 (SI,BP) of a BFER from the BFR-id of the BFER and can therefor= e 1798 =C2=A0 easily determine the BitStrings for a BIER packet to a set of = BFER 1799 =C2=A0 with known BFR-ids. [nit] s/set of BFER/set of BFERs ... 1817 =C2=A0 If "independent branches" are used, the BIER-TE Controller can= signal 1818 =C2=A0 to the BFIR flow overlay for every BFER an SI:BitString that 1819 =C2=A0 represents the branch to that BFER. =C2=A0The flow overlay on = the BIFR can 1820 =C2=A0 then independently of the controller calculate the SI:BitStrin= g for 1821 =C2=A0 all desired BFER by OR'ing their BitStrings. =C2=A0This allows= for flow 1822 =C2=A0 overlay applications to operate independently from the control= ler 1823 =C2=A0 whenever it needs to determine which subset of BFERs need to r= eceive 1824 =C2=A0 a particular packet. [nit] s/all desired BFER/all desired BFERs ... 1838 =C2=A0 Communications between BFIR flow overlay and BIER-TE controlle= r 1839 =C2=A0 requires some way to identify BFER. =C2=A0If BFR-ids are used = in the 1840 =C2=A0 deployment, as outlined in Section 5.3.3, then those are the n= atural 1841 =C2=A0 BFR identifier. =C2=A0If BFR-ids are not used, then any other = unique 1842 =C2=A0 identifier, such as the BFR-prefix of the BFR as of [RFC8279] = could 1843 =C2=A0 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 [RFC8= 279] ... 2031 7. =C2=A0Security Considerations ... 2046 =C2=A0 The reference model for the BIER-TE layer control plane is a B= IER-TE 2047 =C2=A0 controller. =C2=A0When such a controller is used, impairment o= f individual 2048 =C2=A0 BFR in a domain causes no impairment of the BIER-TE control pl= ane on 2049 =C2=A0 other BFR. =C2=A0If a routing protocol is used to support forw= ard_routed() 2050 =C2=A0 adjacencies, then this is still an attack vector as in BIER, b= ut only 2051 =C2=A0 for BIER-TE forward_routed() adjacencies, and no other adjacen= cies. [nit] s/of individual/of an individual [nit] s/other BFR/other BFRs [EoR -10]