Re: [Bier] AD Review of draft-ietf-bier-pim-signaling-11
Alvaro Retana <aretana.ietf@gmail.com> Tue, 20 July 2021 20:18 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 B02363A30B9; Tue, 20 Jul 2021 13:18:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 viNbyhi8HLVt; Tue, 20 Jul 2021 13:18:29 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 BD50D3A30BB; Tue, 20 Jul 2021 13:18:27 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id qa36so14782893ejc.10; Tue, 20 Jul 2021 13:18:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=oQ0xjYEFYTaGxAgL6O8FdngyOO2EoDOAxjx9TistG20=; b=nZA/96G6Xndh24kLf5cZDEORjQwESPo4OhxudgrPJxQWZYwbK8b3wm2mAy2WHbLrSa pglRpjf2AiBL29+PZ+JBDQffESe6dRK+L2ZqU5vxC7bUFhuR8LrMln3kQHTVw6wLn8I3 Nu3Q+kQYJxao5WNtKDr7U2HHaqgqTmKHBn2TRsbRR+sZg3SiANf8sGLfd8tJOpb+ZKMU HArF/rceZrMhOlxbdj/AoIM1ufGcAVEcA9E+Wa5LFXmriQ4SGr1AGJQGYmwfXUKJH6lT 1pf9hc87xP7RCDvsgP9PiYikOXbWB05VfoLjy7EZMyKr8FS3C2YLJSMsRvJ+yMvBAwEj d6NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=oQ0xjYEFYTaGxAgL6O8FdngyOO2EoDOAxjx9TistG20=; b=fTskH5JjjgAYn87p0ugd+HeaOd2TcP2lTo/EJplPz/y/XPCj3Apzoc3GH+/2mFz833 aV8acf9AN1kGB/g73DDGpVMzyuwbIblDTVX3CDT7Slmhj2fNjuW7exr3T0sUu8jNeELA ZP4Od3WqKJavn2oUKPmj9YAzEARN3vdEOM0huxJau3W9O3VHEmIUdlSJKVRU1m8d8SGn 5pqrxxSgii2lKaL4ZC0E0Ed2gvv8AbdfFDX1PXpMxELglc1ymhESRkdrI5hDwIuJiD0m Up/T8LwSQwSwf4Yo0sKR1E/TVWkVW9Habhwl9fYt/YeP+ONg+/WHJJTqX92t2P9FJkFc uUxA==
X-Gm-Message-State: AOAM53052SwUned1Lm8+8m4tFxnVNaeust/7c6eMVURq7lYQHnPVd8Q3 yl8AcHL2uBFRJb3EIJzZHuapjkYkHd7inWVgWeQdn5HYdRs=
X-Google-Smtp-Source: ABdhPJw9RbCRzRdG1u0tuN8DNkrmSlfriSEV1XwIBwB9FrLbVahlyTpl9hiVw5TDvSGJHM2A2S738plpkMPNFR3kUVY=
X-Received: by 2002:a17:906:7716:: with SMTP id q22mr11015543ejm.457.1626812305056; Tue, 20 Jul 2021 13:18:25 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Jul 2021 16:18:24 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAMMESsxi--FSuZrsbxFs3vCXdyv9vp8C9e0iyjNVERNffUrB1g@mail.gmail.com>
References: <CAMMESsxi--FSuZrsbxFs3vCXdyv9vp8C9e0iyjNVERNffUrB1g@mail.gmail.com>
MIME-Version: 1.0
Date: Tue, 20 Jul 2021 16:18:24 -0400
Message-ID: <CAMMESsyXbqU4NN8MOY4bo0Mh40FMM96tTCbYrYHsBrjahJh59Q@mail.gmail.com>
To: draft-ietf-bier-pim-signaling@ietf.org
Cc: pim@ietf.org, Nabeel Cocker <nabeel.cocker@gmail.com>, BIER WG <bier@ietf.org>, BIER WG Chairs <bier-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f266205c793c1bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/-dzZ3JJhQea2CCn6bcwdu8xrJDo>
Subject: Re: [Bier] AD Review of draft-ietf-bier-pim-signaling-11
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 20:18:36 -0000
Ping! On June 21, 2021 at 3:27:22 PM, Alvaro Retana (aretana.ietf@gmail.com) wrote: Dear authors: Thank you for your work and the patience through the publication process. I just finished reading this document -- it still needs work! In general, tightening up the specification is needed -- this is a Standards Track document! Also, as written, this document is not compliant with rfc7761 -- I included most of my concerns about this point in §3.1.3.1 (search for line 338). There are some process issues (listed in increasing severity) that I need the Chairs'/Shepherd's input on: (1) 6 authors are listed in the front page, but rfc7322 recommends a limit of 5. Chairs: Can you please provide justification for going over the limit? [In general, I think that 6 is an ok number -- we just need to cross the T's...] (2) I didn't see a specific request from the Chairs asking the pim WG to review, or them being cc'd in any of the WGLCs. Did I miss it? Given the amount of PIM content in this document, that interaction should have already happened. I realize that there's a significant overlap in participation between the two WGs, so I'm cc'ing pim on this message and will forward the IETF LC when we get to that stage. (3) This document replaces draft-hfa-bier-pim-signaling, but that linkage had not been indicated in the datatracker when Publication was requested. The main issue with this oversight is that draft-hfa-bier-pim-signaling has two IPR declarations [1]. The Shepherd's writeup says that no IPR had been filed against this document. Also, I didn't find an IPR poll in the archives. I have added the link between this document and draft-hfa-bier-pim-signaling. To address this issue, I need the Chairs to please poll the authors about any non-declared IPR. Please cc the WG (in case anyone else needs to declare something) and include a link to the existing disclosures. Once each author has individually replied, I need the Shepherd to update the writeup. [1] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bier-pim-signaling Finally, I have a general question about the need/applicability for this work. This is just for my own education: What is the advantage/difference between using the specification in this document and unicast-tunneling the PIM messages to the corresponding node (EBBR)? I see the discovery of the EBBR as one of the differences, but that discovery is outside the scope of this document -- IOW, the same procedures could be used to discover the target node without the additional BIER machinery. Again, I'm just curious. I suspect other reviewers may have similar questions. Thanks! Alvaro. [Line numbers from idnits.] ... 18 Abstract [nit] The First two paragraphs could be merged to provide continuity. 20 Consider large networks deploying traditional PIM multicast service. 21 Typically, each portion of these large networks have their own 22 mandates and requirements. 24 It might be desirable to deploy BIER technology in some part of these 25 networks to replace traditional PIM services. In such cases 26 downstream PIM states need to be signaled over BIER Domain toward the 27 source. [nit] s/over BIER Domain/over the BIER Domain 29 This draft explains the procedure to signal PIM joins and prunes 30 through a BIER Domain, as such enable provisioning of traditional PIM 31 services through a BIER Domain. [minor] s/explains/specifies [minor] s/ joins and prunes / Join/Prune messages /g Please make sure, throughout the document, that the rfc7761 terminology is followed. [nit] s/as such enable/enabling the ... 98 1. Introduction 100 Consider large networks deploying traditional PIM multicast service. 101 Typically, each portion of these large networks have their own 102 mandates and requirements. [minor] The Introduction is an exact copy of the Abstract. That in itself is not necessarily a bad thing. However, you might want to take the time here to maybe explain about what the different "mandates and requirements" are that would result in needing to signal PIM through the BIER domain. [This is related to my question at the top about the need/applicability.] ... 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as describe in [RFC2119]. [major] Please use the template from rfc8174. 119 2.1. Definitions 121 Some of the terminology specified in [RFC8279] is replicated here and 122 extended by necessary definitions: [major] Please don't replicate the terminology -- this way we can avoid the terms falling out of sync or being defined/understood differently. Instead, make it clear what the expectations are: Suggestion> An understanding of the BIER architecture [RFC8279] and the related terminology is expected. New terms are ok in this section. Extensions not so much because they may change the definition of a term in rfc8279, but a clarification is ok. ... 153 BBR: 155 BIER Boundary router. A router between the PIM domain and BIER 156 domain. Maintains PIM adjacency for all routers attached to it on 157 the PIM domain and terminates the PIM adjacency toward the BIER 158 domain. 160 IBBR: 162 Ingress BIER Boundary Router. An ingress router from signaling point 163 of view. It maintains PIM adjacency toward the PIM domain and 164 determines if PIM joins and prunes arriving from PIM domain need to 165 be signaled across the BIER domain. If so it terminates the PIM 166 adjacency toward the BIER domain and signals the PIM joins/prunes 167 through the BIER core. 169 EBBR: 171 Egress BIER Boundary Router. An egress router in BIER domain from 172 signaling point of view. It terminates the BIER packet and forwards 173 the signaled joins and prunes into PIM Domain. [major] I would have expected for the IBBR/EBBR to be defined as specific types of a BBR, but the definition doesn't do so. For example, the BBR "Maintains PIM adjacency for all routers", as does the IBBR, but the EBBR doesn't. IOW, it looks like the EBBR is not a BBR. Please review and update the definitions. ... 193 3. PIM Signaling Through BIER domain ... 208 As per figure 1, the procedures of PIM signaling is done at the BIER 209 boundary router. The BIER boundary routers (BBR) are connected to 210 PIM capable routers toward the PIM domain and BIER routers toward the 211 BIER domain. PIM routers in PIM domain continue to send PIM state 212 messages to the BBR. The BBR will create PIM adjacency between all 213 the PIM routers attached to it on the PIM domain. That said the BBR 214 does not propagate all PIM packets natively into the BIER domain. 215 Instead when it determines that the PIM join or prune messages needs 216 to be signaled through the BIER domain it will tunnel the PIM packet 217 through the BIER network. This tunneling is only done for signaling 218 purposes and not for creating a PIM adjacency between the two 219 disjoint PIM domains through the BIER domain. [] Suggestion> Figure 1 illustrates the operation of the BIER Boundary router (BBR). BBRs are connected to PIM routers in the PIM domain and BIER routers in the BIER domain. Each BBR determines if a PIM Join or Prune message needs to be signaled through the BIER domain and tunnels it through the BIER network if so. This tunneling is only done for signaling purposes and not for creating a PIM adjacency between the two disjoint PIM domains through the BIER domain. 221 The terminology ingress BBR (IBBR) and egress BBR (EBBR) are relative 222 from signaling point of view. [minor] s/are relative from signaling/is relative only from a signaling 224 The ingress BBR will determine if an arriving PIM join or prune needs 225 to be signaled across the BIER domain. While the egress BBR will 226 determine if the arriving BIER packet is a signaling packet and if so 227 it will generate a PIM join/prune packet toward its attached PIM 228 domain. [minor] The first sentence is redundant with the text above. 230 The BFER and BFIR are BBR from datapath point of view. It should be 231 noted the new procedures in this draft are only applicable to 232 signaling and there are no changes from datapath point of view. [minor] I think that mixing the term BBR (defined in this document for signaling purposes) with BFIR/BFER (at this point) may cause unnecessary confusion. Suggestion> The new procedures in this document are only applicable to PIM signaling. There are no changes to the datapath. 234 3.1. Ingress BBR procedure 236 IBBR will create PIM adjacency to all PIM routers attached to it 237 toward the PIM domain. [] Suggestion> The IBBR maintains a PIM adjacency [RFC7761] with any PIM router attached to it on the PIM domain. 239 When a PIM join or prune for certain (S,G) arrives, the IBBR first 240 determines whether the join or prune is meant for a source that is 241 reachable through the BIER domain. As an example, this source is 242 located in a disjoint PIM domain that is reachable through the BIER 243 domain. If so the IBBR will try to resolve the source via an EBBR 244 closest to the source. 246 The procedure to find the EBBR (BFIR from datapath point of view) can 247 be via many mechanisms explained in more detail in upcoming section. [major] "certain (S,G)" It is not until §5 that you mention the use of the mechanisms with ASM. The text throughout the document feels as if the operation applies *only* to SSM becasue of the specific used of "source". Please mention the applicability earlier so the reader doesn't have to make assumptions. Including something in the Introduction would be ideal -- maybe move a part of §5 there. Also, some of the text will have to be updated to reflect the use of the source or RP. [major] Related. The mechanisms in this document work to join/leave the RPT, but not for a source to send Register messages to an RP across the BIER domain. Given that the Register messages are unicast, they should make it to the RP without additional changes, right? It would be good if this was explained somewhere. [major] "mechanisms explained in more detail in upcoming section" There are examples later on, but not a more detailed explanation. In fact, §3.1.1/Appendix A/§3.1.2 declare the EBBR discovery to be out of scope. I think that declaring this part of the specification out of scope is ok, mostly because finding the path towards the source/RP is a well-known process in PIM. The difference is that the RPF neighbor (EBBR in this case) will usually not be directly connected. I wonder if the process can be described using "RPF", with the caveats that the RPF neighbor is the EBBR and RPF interface is the BIER tunnel towards it. [] Suggestion -- to replace the last two paragraphs (and eliminate §3.1.1/3,1,2)> When a PIM Join or Prune message is received, the IBBR determines whether the Source or RP is reachable through the BIER domain. The EBBR is the BFR through which the Source or RP is reachable. In PIM terms [rfc7761], the EBBR is the RPF Neighbor, and the RPF Interface is the BIER "tunnel" used to reach it. The mechanisms used to find the EBBR are outside the scope of this document -- some examples are provided in Appendix A. If the lookup results in multiple EBBRs, then the EBBR closest to the source should be preferred. The selection algorithm should ensure that all signaling for a particular (S,G) or RP is forwarded to a single EBBR. For example, the selection can be round robin or use the lowest EBBR IP address. 249 After discovering the EBBR and its BFR-ID, the IBBR will include a 250 new PIM Join Attribute in the join/prune message as per [RFC5384]. 251 Two new "BIER IBBR" attributes are defined and explained in upcoming 252 section. The PIM Join Attribute is used on EBBR to obtain necessary 253 BIER information to build its multicast states. In addition the IBBR 254 will change the PIM signaling packet source IP address to its BIER 255 prefix address (standard PIM procedure). It will also keep the 256 destination address as the well known multicast IP address. It then 257 will construct the BIER header. The signaling packet, in this case 258 the PIM join/prune packet, is encapsulated in the BIER header and 259 transported through BIER domain to EBBR. [] It took me a while to correlate the "a new PIM Join Attribute in the join/prune message as per [RFC5384]" with the fact that the attribute is defined in this document (not rfc5384). Also, I am not able to find the "two new "BIER IBBR" attributes...in upcoming section". I see that the Join Attribute can be either IPv4 or IPv6 -- is that what you meant by 2 attributes? Suggestion (to replace the first 3 sentences)> After discovering the EBBR and its BFR-id, the IBBR MUST use the BIER Info Vector (Section 3.1.3) PIM Join Attribute [rfc5384]. The EBBR uses this attribute to obtain the necessary BIER information to build its multicast state. The signaling packet, in this case a PIM Join/Prune message, is encapsulated in the BIER Header and forwarded through the BIER domain to the EBBR. The source address of the PIM packets MUST be set to belong to the local BFR-prefix. The destination address MUST be set to ALL-PIM-ROUTERS [rfc7761]. There was an interesting suggestion on the list [1] -- I didn't see a reply. [1] https://mailarchive.ietf.org/arch/msg/bier/58OIQ_9JbIiUWPrR_Yo7J47GMc8 261 The IBBR will track all the PIM interfaces on the attached PIM domain 262 which are interested in a certain (S,G). It creates multicast states 263 for arriving (S,G)s from PIM domain, with incoming interface as BIER 264 "tunnel" interface and outgoing interface as the PIM domain 265 interface(s) on which PIM Join(s) were received on. [minor] "arriving (S,G)s" I guess you mean "arriving Join messages"... ... 288 3.1.3. PIM Signaling packet construction at IBBR [nit] s/at IBBR/at the IBBR [] Let's separate the definition of the new attribute from its use. IOW. in §3.1.3 specify the attribute (in general -- independent of the application), and use §3.1.3.1 to indicate the use and packet construction. The title in §3.1.3 should then be: The BIER Info Vector PIM Join Attribute 290 To ensure all necessary BIER information needed by EBBR is present in 291 the BIER signaling message, a new PIM Join Attribute [RFC5384] is 292 used. EBBR can use this attribute to build its multicast states, as 293 described in EBBR procedure section. This new PIM join Attribute is 294 added to PIM signaling message on the IBBR. Its format is as follow: [minor] Note that the name of this attribute is not mentioned until §7. :-( BTW, do you want to keep the name as "BIER Info Vector" or expand it to "BIER Information Vector"? Suggestion> The BIER Info Vector PIM Join Attribute [rfc5384] is defined as follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |F|E| Type=tbd | Length | Addr Family | BIER info 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... [major] s/Type=tbd/Attr_Type That is the name in rfc5384. 302 Figure 2: PIM Join Attribute 304 F bit: The Transitive bit. Specifies whether this attribute is 305 transitive or non-transitive. MUST be set to zero. This attribute 306 is ALWAYS non-transitive. [] NEW> F-bit: Transitive Attribute, as specified in [rfc5384]. MUST be set to zero as this attribute is always non-transitive. [major] What should the receiver do if the F-bit is set? 308 E bit: End-of-Attributes bit. Specifies whether this attribute is 309 the last. Set to zero if there are more attributes. Set to 1 if 310 this is the last attribute. [] NEW> E-bit: End of Attributes, as specified in [rfc5384]. 312 Type: TBD assign by IANA. [] NEW> Attr_Type: TBD 314 Length: The length in octets of the attribute value. MUST be set to 315 the length in octets of the BIER info +1 octet to account for the 316 Address Family field. For IPv4 AF Length = 7+1 For IPv6 AF Length = 317 19+1. [] NEW> Length: length of the value field, as specified in [rfc5384]. MUST be set to the length of the BIER Info field + 1. For IPv4 the length is 8, and 20 for IPv6. [major] What should a receiver do if the length is not set correctly with respect to the AF? 319 Addr Family: Signaled PIM Join/Prune address family as defined in 320 [RFC7761]. [] NEW> Addr Family: PIM address family, as specified in [rfc7761]. [major] What should a receiver do if the received AF is not IPv4 or IPv6? 322 BIER Info: IBBR Prefix (IPv4 or IPv6), SD, bfr-id as per below figure [minor] Move the definition of the fields to be after the figure. NEW> BIER Info: This field is described in Figure 3. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 ~ IBBR Prefix IPv4 or IPv6 ~ 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | subdomain-id | BFR-ID | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 3: PIM Join Attribute detail [major] What is the IBBR prefix? I guess it is the IBBR's BFR-prefix. [major] What should the receiver do if the BFR-prefix is not routable? [major] s/subdomain-id/sub-domain-id Use SD in the figure to make sure it fits. [major] s/BFR-ID/BFR-id/g [major] What should a receiver do if the BFR-id doesn't match the BFIR-id in the BIER Header? [major] What should the receiver do if multiple instances of this attribute are received? [major] Are there any considerations related to the interaction with other PIM Join attributes? For example the Vector attribute. I am asking both from the point of view of the IBBR receiving other attributes from the PIM domain, *and* the IBBR including/forwarding them through the BIER domain. If any of the received attributes are transitive, should they be forwarded through the BIER domain? 334 3.1.3.1. BIER packet construction at IBBR [nit] s/at IBBR/at the IBBR 336 The BIER header will be encoded with the BFR-id of the IBBR(with 337 appropriate bit set in the BitString) and the PIM signaling packet is 338 then encapsulated in the packet. [minor] I think the whole process can be summarized in a single paragraph -- no need for the figure or the definitions below. Suggestion> The BIER Header is used according to the specification in [rfc8296] for a BIER packet to be sent from the IBBR to the EBBR. The PIM Join/Prune message is encapsulated in it including the BIER Info Vector PIM Join Attribute (Section 3.1.3). [major] Compliance with rfc7761. Even though it is not explicitly mentioned until §5, I want to talk about not sending Hellos and the overall compliance with rfc7761 here. TL;DR: as written, not sending Hello messages is not compliant with rfc7761. rfc7761/§4.3.1 says this: Note that neighbors will not accept Join/Prune or Assert messages from a router unless they have first heard a Hello message from that router. Thus, if a router needs to send a Join/Prune or Assert message on an interface on which it has not yet sent a Hello message with the currently configured IP address, then it MUST immediately send the relevant Hello message without waiting for the Hello Timer to expire, followed by the Join/Prune or Assert message. This text requires (*MUST*) a Hello *before* sending a Join/Prune. Later, in rfc7761/§4.5 the text is a little more lenient (even contradictory): In general, a PIM Join/Prune message should only be accepted for processing if it comes from a known PIM neighbor. A PIM router hears about PIM neighbors through PIM Hello messages. If a router receives a Join/Prune message from a particular IP source address and it has not seen a PIM Hello message from that source address, then the Join/Prune message SHOULD be discarded without further processing. This text recommends (*SHOULD*) discarding a Join/Prune if no Hello has been received. This opens a very small door to process the Join/Prune... As we all know, a requirement is stronger than a recommendation. It is very hard for me to consider how this document can work around not sending the required Hello *and* still claim to be compliant with rfc7761. One possible way forward is to also send PIM Hellos through the BIER domain. This would immediately bring this document in compliance with rfc7761 and remove other concerns (below). The other option is to not send PIM Hellos through the BIER domain. There are several points that then have to be addressed: - What about rfc7761? Focus on a strong justification to ignore the recommendation in §4.5. - What capabilities are expected the BBRs to have? What are the effects of those expectations not being met? - How does the EBBR determine the PIM availability of the IBBR? IOW, not using Hellos means that the EBBR cannot determine whether the IBBR (more explicitly, its PIM functionality) is still available. - There are other potential security issues. For example, any node can send Joins/Prunes with irrelevant information causing traffic to unnecessarily traverse the network. This is not a new threat for PIM (even a known neighbor can do that), but in this case the attack surface is expanded. [major] The issue of the MTU of the BIER tunnel was brought up during WGLC [1], but I didn't see a resolution. FWIW, I agree with Stig's observation that if a significant amount of state is to be carried in the Join/Prune, then it is important to be aware of the effective MTU through the BIER domain. There's some text in §4.4.1/rfc7761 that could be repurposed here. [1] https://mailarchive.ietf.org/arch/msg/bier/-YBAPXTXOKXfkOqcD36_54F1_Bo ... 368 3.2. Signaling PIM through the BIER domain procedure [minor] This section seems unnecessary as it states the obvious. It is ok to leave it in for completeness. I do think however that the second paragraph is not needed at all as it just repeats (without using the exact same language) what is already specified in rfc8279. 370 Throughout the BIER domain the BIER forwarding procedure is on par 371 with [RFC8279]. No BIER router will examine the BIER packet 372 encapsulating the PIM signaling packet. As such there is no 373 multicast state built in the BIER domain. [minor] s/on par with /according to 375 The packet will be forwarded through the BIER domain until it reaches 376 the BER with matching BFR-ID as in the BIERHeader.Bitstring. EBBR 377 will remove the BIER header and examine the PIM IPv4 or IPv6 378 signaling packet further as per EBBR Procedure section. 380 3.3. EBBR procedure 382 EBBR will remove the BIER header and determine this is a signaling 383 packet. The Received PIM join/prune Signaling packet is processed as 384 if it were received from neighbors on a virtual interface, (i.e. as 385 if the pim adjacency was present, regardless of the fact that there 386 is no adjacency). [nit] s/EBBR will remove/The EBBR removes [minor] s/BIER header/BIER Header/g 388 The EBBR will build a forwarding table for the arriving (S,G) using 389 the obtained BFIR-id and the Sub-Domain information from BIER Header 390 and/or the PIM join Attributes added to the PIM Signaling packet. In 391 short it tracks all IBBRs interested in this (S,G). This is 392 explained in section 4.1. [nit] s/The EBBR will build/The EBBR builds [major] "forwarding table" rfc7761 refers to the state process using a TIB (indirectly referring to a multicast forwarding table); please use consistent explanations with the existing RFCs. [minor] "arriving (S,G)" Maybe something like "membership information" from the PIM Join/Prune messages. [minor] s/using the obtained BFIR-id and the Sub-Domain information from BIER Header and/or the PIM join Attributes added to the PIM Signaling packet./using the information obtained from the IBBR (in the BIER Header and the PIM Join/Prune message). [minor] "explained in section 4.1" §4.1 is just paragraph. Instead of pointing the user there, please move that text here. However, it seems to me that the next paragraph is redundant with anything that §4.1 says, so it may not be needed at all. 394 The multicast state on EBBR will contain PIM domain incoming 395 interfaces, according to PIM specification and outgoing interfaces 396 based on the above procedure to build the forwarding table. [minor] NEW> The multicast state on the EBBR contains interfaces on the local PIM domain as incoming interfaces. The outgoing interface is set to the BIER "tunnel" used to reach the IBBR. 398 It should be noted EBBR will maintain PIM adjacency toward the PIM 399 domain and all PIM routers which are connected to it. At this point 400 the end-to-end multicast traffic flow setup is complete. [] Suggestion> The EBBR maintains a PIM adjacency [RFC7761] with any PIM router attached to it on the PIM domain. At this point the end-to-end multicast traffic flow setup is complete. ... 413 4.2. Datapath traffic flow 415 When the multicast data traffic arrives on the BFIR (EBBR) the router 416 will find all the interested BFERs for that specific (S,G). The 417 router then constructs the BIERHeader.BitString with all the BFER 418 interested in the group and will forward the packet to the BIER 419 domain. The BFER(s) will accept the packets and remove the BIER 420 header and forward the multicast packet as per pre-built multicast 421 state for (S,G) and its outgoing interfaces. [] NEW> When multicast data traffic arrives on the BFIR (EBBR) it forwards, through the BIER domain, the traffic to all interested IBBRs following the procedures specified in [RFC8279]. The BFER(s) (IBBR(s)) also follow the procedures in [rfc8279] and forward the multicast packet through its outgoing interface(s). 423 5. PIM-SM behavior 425 The procedures described in this document can work with Any-Source 426 Mutlicast (ASM) as long as static Rendevous Point (RP) or embedded RP 427 for IPv6 is used. Future drafts would cover Bootstrap Router (BSR) 428 and more complicated SM discovery mechanisms. [minor] s/can work with/can be used with [nit] s/as static/as a static [major] Please add a Normative reference to rfc3956. [minor] The last sentence is not needed, please remove it. 430 It should be noted that this draft only signals PIM Joins and Prunes 431 through the BIER domain and not any other PIM message types including 432 PIM Hellos or Asserts. As such functionality related to these other 433 type of massages will not be possible through a BIER domain with this 434 draft and future drafts might cover these scenarios. As an example 435 DR selection should be done in the PIM domain or if the PIM routers 436 attached to IBBRs are performing DR selection there needs to be a 437 dedicated PIM interface between these routers. [major] As mentioned before, not including Hellos may cause some issues (including not conforming to rfc7761). It is not clear to me that the justification ("such functionality related to these other type of massages will not be possible") applies to Hellos. What about the capabilities, what is expected? How does the IBBR know if the EBBR even supports Join attributes?? [minor] The example doesn't apply to sending messages over the BIER domain. 439 In case of PIM ASM Static RP or embedded RP for IPv6 the procedure 440 for leaves joining RP is the same as above. It should be noted that 441 for ASM, the EBBRs are determined with respect to the RP instead of 442 the source. [major] Instead of including this explanation, update the specification part of this document to take into account the ASM case. 444 6. Applicability to MVPN [] This section starts by saying that "With just minor changes, the above procedures apply to MVPN", but the description goes into more that "minor changes" (including a potential "more complicated label allocation scheme") and points at other details not properly specified. If you want to include the MVPN case, then this section will need more details, references, etc. Personally I would suggest removing it. ... 478 7. IANA Considerations 480 In the "PIM Join Attribute Types" registry, IANA to assign a new 481 value [TBD] to the BIER Info Vector. [major] NEW> IANA is requested to assign a value (TBD) to the BIER Info Vector PIM Join Attribute from the PIM Join Attribute Types registry. 483 8. Security Considerations 485 The procedures of this document do not, in themselves, provide 486 privacy, integrity, or authentication for the control plane or the 487 data plane. For a discussion of the security considerations 488 regarding the use of BIER, please see [RFC8279] and [RFC8296]. 489 Security considerations regarding PIM protocol is based on [RFC7761]. [nit] s/[last sentence]/The security considerations for PIM [rfc7761] also apply. [major] Some of the risks introduced in this document are not new (forging a Join/Prune, for example), but can now be exploited in a different way (across a BIER domain). The effect may be more significant as it may result in traffic forwarded through the network without need; think congestion, use of resources, etc. The Prune may have the exact opposite effect. Note that you don't need to provide a solution, just mention that as in rfc7761 forging is an issue (but with the BIER domain increased scope). [major] I mentioned receiving a Join/Prune without a neighbor before. Note that rfc7761 recomments this in §6.2: A PIM router SHOULD provide an option to limit the set of neighbors from which it will accept Join/Prune, Assert, and Hello messages. Either static configuration of IP addresses or an IPsec security association MAY be used. Furthermore, a PIM router SHOULD NOT accept protocol messages from a router from which it has not yet received a valid Hello message. The recommendation to limit the set of neighbors should be highlighted in this document. In fact, I think it should be required. ... 496 10. References 498 10.1. Normative References 500 [RFC4607] "H. Holbrook, B. Cain, "Source-Specific multicast for 501 IP"", October 2016. [major] Unused reference. ... 507 10.2. Informative References ... 513 [RFC2119] "S. Brandner, "Key words for use in RFCs to Indicate 514 Requirement Levels"", March 1997. [major] This reference should be Normative. 516 [RFC5384] "A. Boers, I. Wijnands, E. Rosen, "PIM Join Attribute 517 Format"", November 2008. [major] This reference should be Normative. ... 526 [RFC7761] "B.Fenner, M.Handley, H. Holbrook, I. Kouvelas, R. Parekh, 527 Z.Zhang "PIM Sparse Mode"", March 2016. [major] This reference should be Normative. 529 [RFC8296] "IJ. Wijnands, E. Rosen, A. Dolganow, J. Yantsura, S. 530 Aldrin, I. Meilik, "Encapsulation for BIER"", January 531 2018. [major] This reference should be Normative. 533 [RFC8401] "Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 534 "BIER Support via ISIS"", June 2018. [major] Unused reference. 536 [RFC8444] "Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., 537 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 538 for Bit Index Explicit Replication"", June 2018. [major] Unused reference. 540 [RFC8556] "Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, 541 S.,Dolganow, A., and T. Przygienda, "Multicast VPN Using 542 BIER"", March 2018. [major] Unused reference. 544 Appendix A. 546 This appendix provides some examples and routing procedures that can 547 be used to determine the EBBR on IBBR. It should be noted, the PIM 548 domains can be either part of the same IGP area as BIER domain(single 549 area) or are stitched to the BIER domain via an ABR or ASBR routers. 550 As such on IBBR, there can be many different procedures to determine 551 the EBBR. Not all procedures are listed below. [nit] s/examples and routing procedures/examples of routing procedures [nit] s/EBBR on IBBR/EBBR at the IBBR [major] I think that talking about overlaps (or lack of) between PIM, BIER, and general flooding domains may raise significant questions related to the specification. Personally, I wouldn't go there. 553 A.1. SPF [major] SPF may be an understood reference to a link-state protocol, but it may not be properly understood by the casual reader. Please mention link-state protocols instead. ... 570 A.2.1. Static Route 572 On IBBR there can be a static route configured for the source, with 573 source next-hop set as EBBR BIER prefix. [nit] NEW> A static route to the source can be configured on the IBBR with the next-hop set as the EBBR's BFR-prefix. 575 A.2.2. Interior Border Gateway Protocol (iBGP) 577 Consider the following topology: 579 BBR BBR 580 EBBR IBBR 581 |--PIM Domain--|-----BIER domain-----|--PIM domain--| 582 S--( A )----------( B ) ---- ( C ) ---- ( D )----------( E )--h [nit] Using "BBR" on top of EBBR/IBBR is redundant. 584 Figure 5: Static Route 586 Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM 587 Domain routes are redistributed to the BIER domain via BGP. This 588 would include the Multicast Source IP address (S), which resides in 589 the PIM Domain. In such case BGP should use the same loopback 590 interface as its next-hop as the BBR prefix. This will ensure that 591 all PIM domain routes, including the Multicast Source IP address (S) 592 are resolve via BBR's BIER prefix id as their next-hop. When the 593 host (h) triggers a PIM join message to IBBR (D), IBBR tries to 594 resolve (S). It resolves (S) via BGP installed route and realizes 595 its next-hop is EBBR (B). IBBR will use this next-hop (B) to find 596 its corresponding BIER bit index. [minor] "BGP should use the same loopback interface as its next-hop as the BBR prefix" There is no relationship between BGP and the BFR-prefix. Suggestions> Figure 5 shows BGP enabled between the EBBR (B) and the IBBR (D), and it is used to distribute the routes from the the PIM Domain through the BIER domain, including the Multicast Source IP address (S). The peering address used for BGP should belong to the same block as the BFR-prefix if the EBBR to ensure that all routes from the PIM domain are resolved via the EBBR's BFR-prefix as their next-hop. 598 This procedure is inline with [RFC6826] mLDP in-band signaling 599 section [] I don't see the relevance of this sentence. Please take it out. [End of Review -11]
- [Bier] AD Review of draft-ietf-bier-pim-signaling… Alvaro Retana
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Alvaro Retana
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Jeffrey (Zhaohui) Zhang
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Alvaro Retana
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Bidgoli, Hooman (Nokia - CA/Ottawa)
- Re: [Bier] AD Review of draft-ietf-bier-pim-signa… Tony Przygienda