Re: [Bier] AD Review of draft-ietf-bier-pim-signaling-12

["Bidgoli, Hooman (Nokia - CA/Ottawa)" <[e-mail]>]

Hi Alvaro

Inline
Thanks
Hooman

-----Original Message-----
From: Alvaro Retana <[e-mail]> 
Sent: Thursday, August 5, 2021 6:13 PM
To: [e-mail]; Bidgoli, Hooman (Nokia - CA/Ottawa) <[e-mail]>
Cc: Nabeel Cocker <[e-mail]>; [e-mail]; BIER WG <[e-mail]>
Subject: AD Review of draft-ietf-bier-pim-signaling-12

Dear authors:

Thanks for the document update.  Instead of replying to the -11-related thread, I am providing an updated review of -12.

When addressing the comments below, I expect an inline reply to this message, especially to any points/comments that you might not agree with or want to discuss further.  That will make my review of any changes easier/faster.  Note that there wasn't a detailed reply to my previous review so I ended up repeating some comments below.


My main issue with this document remains the compliance with rfc7761
-- or lack of it.  In short, this document can't rely on parts of
rfc7761 and not others without explicitly changing the behavior, even if it is for BIER-specific cases only.

On one hand...  I understand that a PIM adjacency is not formed over the BIER domain.  *But* PIM packets and processes are used.  For example, §3.1 talks about sending a PIM packet encapsulated in BIER -- if it is a PIM packet then it must follow rfc7761.  This includes defining a new PIM Join Attribute.


HB> how about if we change it to "signaling packet" and in a paragraph explain these signaling packets have PIM join,prune packet formats? Would that remove the confusion?
not sure how else to explain this, there is no PIM packet transmission, there are signaling packet transmission. These signaling packets are chosen to be pim packet and TLVs so we don't have to reinvent the wheel. It is as simple as that. We just want to signal the joins/prunes of <S,G>s over the BIER domain and reusing an already existing packet format made our life very easy. This is implemented and is working flawlessly.

On the other hand...  Because you're not really running PIM through the BIER domain, then the information only needs to "look like" a Join/Prune + BIER Information.  IOW, if it's not PIM then we don't need it to be PIM (i.e. comply with rfc7761).   As I understand it, this is the intent: reuse some of the packet formats so it looks like PIM.

HB> yes you got it, exactly. So as suggested would rewording to "signaling packets" clear the confusion? 

However, as written, the document says: "we're using PIM, but we really aren't".  The exceptions to the behavior (see my rfc7761-related questions) are not clearly defined -- except for a non-normative mention of the fact that no adjacency is formed.  One way forward is to be explicit about the changes/exceptions of running PIM (sending Join/Prune) across a BIER domain: for example, consider this a "new interface" (the "BIER interface") that has specific characteristics/requirements/exceptions.  You would also need to specify that the new Join Attribute can only be used on this type of interface.  With these exceptions, an IP packet with a protocol/next header of PIM can be used.

[My comments below are based on how the document is currently written.]

The other way forward would be to specify the information to be carried, which would *look like* a Join/Prune + BIER Information (but not be PIM, as in rfc7761), and how it is carried over the BIER domain.  Instead of the Proto field in the BIER Header pointing at IP (and then at PIM), you can define a new Next Protocol Id called "Group Information".  This gets you away from having to comply with rfc7761.

In summary, you can't reuse rfc7761 without complying with it.

HB> sorry this is not clear, I don't think at any place we are using rfc7761 in the BIER core or trying to comply with it in the BIER core. Why is not possible to choose a existing packet format and reuse it for purpose of singling a desire? We are doing this in many other WGs where we are using a existing unicast packet like PCE SR Policy and just reuse that packet type for another purpose by modifying it or adding new flags etc... This makes the implementation much more easier and bug free.

I hope that my concerns are clearer.

We should plan a call to talk this over.  It would be nice to have the Shepherd + Authors, but any combination works for me.  Please find a time that works for you -- here's my calendar:
https://doodle.com/mm/alvaroretana/book-a-time
HB> sure I book some thing next week 


Thanks!

Alvaro.


[Line numbers from idnits.]


...
18	Abstract
...
27	   This draft specifies the procedure to signal PIM join/prune messages
28	   through a BIER Domain, as such enabling the provisioning of
29	   traditional PIM services through a BIER Domain.  These procedures are
30	   valid for forwarding PIM join/prune messages to the Source (SSM) or
31	   Rendezvous Point (ASM).

[] "join/prune messages"

The name of the messages (from rfc7761) is "Join/Prune", not "join/prune", "join and prune", or any other variation.  Please be consistent with existing terminology throughout the whole document!


[minor] SSM should be expanded -- but this is the only place where it is used, so perhaps you don't need it at all.


[minor] ASM should be expanded -- there are other mentions, but it may not be necessary at this point.


[minor] Please be consistent about how you refer to the source.  To be aligned with rfc7761: s/Source/source/g


...
94	1.  Introduction

96	   It might be desirable to simplify/upgrade some part of an existing
97	   network to BIER technology, removing any legacy multicast protocols
98	   like PIM.  This simplification should be done with minimum
99	   interruption or disruption to the other parts of the network from
100	   singling, services and software upgrade point of view.  To do so this
101	   draft is specifies procedures for signaling multicast join and prune
102	   messages over the BIER domain, this draft is not trying to create
103	   FULL PIM adjacency over a BIER domain between two PIM nodes.  The PIM
104	   adjacency is terminated at BIER edge routers and only join/prune
105	   signaling messages are transported over the BIER network.  It just so
106	   happened that this draft chose signaling messages to be in par with
107	   PIM join/prune messages.  These signaling messages are forwarded
108	   upstream toward the BIER edge router on path to the Source or
109	   Rendezvous point.  These signaling messages are encapsulated in a
110	   BIER header.

[nit] s/draft is specifies/draft specifies


[minor] s/this draft is not trying to create FULL PIM adjacency over a BIER domain between two PIM nodes./while not creating a PIM adjacency through the BIER domain.


[?] "It just so happened that this draft chose signaling messages to be in par with PIM join/prune messages."

I don't understand what you're trying to convey here, but it's probably related to the fact that you're using PIM and not using PIM... (see above)


[minor] Suggestion:

OLD>
   These signaling messages are forwarded upstream toward the BIER edge
   router on path to the Source or Rendezvous point.  These signaling
   messages are encapsulated in a BIER header.

NEW>
   The signaling messages are encapsulated in a BIER header and forwarded
   towards the BIER edge router on the path to the Source or Rendezvous
   Point (RP).


...
120	2.1.  Definitions
...
126	   BBR:

128	   BIER Boundary router.  A router between the PIM domain and BIER
129	   domain.  Maintains PIM adjacency for all routers attached to it on
130	   the PIM domain and terminates the PIM adjacency toward the BIER
131	   domain.

133	   IBBR:

135	   Ingress BIER Boundary Router.  An ingress router from signaling point
136	   of view.  It maintains PIM adjacency toward the PIM domain and
137	   signals join/prune messages across the BIER domain to EBBR as needed.

139	   EBBR:

141	   Egress BIER Boundary Router.  An egress router in BIER domain from
142	   signaling point of view.  It maintains PIM adjacency to all upstream
143	   PIM routers.  It terminates the BIER signaling packets and creates
144	   necessary PIM join/prune messages into PIM Domain.

[] Suggestion>

   BBR:

   BIER Boundary Router.  A router between the PIM domain and the BIER
   domain.  Maintains a PIM adjacency with the all the attached PIM
   routers.

   IBBR:

   Ingress BBR.  An ingress router from the signaling point of view.  It
   signals Join/Prune messages across the BIER domain to the EBBR, as
   needed.

   EBBR:

   Egress BBR.  An egress router from the signaling point of view.  It
   originates any needed PIM Join/Prune messages into the PIM Domain.


146	3.  PIM Signaling Through BIER domain

[nit] s/Through BIER/Through the BIER


...
161	   Figure 1 illustrates the operation of the BIER Boundary router (BBR).
162	   BBRs are connected to PIM routers in the PIM domain and BIER routers
163	   in the BIER domain.  PIM routers in PIM domain continue to send PIM
164	   state messages to the BBR.  The BBR will create PIM adjacency between
165	   all the PIM routers attached to it on the PIM domain.  Each BBR
166	   determines if a BIER Signaling Join or Prune message needs to be
167	   transmitted through the BIER domain.  This draft has chosen these
168	   BIER signaling messages to be PIM join/prune message, as such an
169	   implementation could chose to tunnel actual PIM join/prune messages
170	   through BIER network.  This tunneling is only done for signaling
171	   purposes and not for creating a PIM adjacency between the two
172	   disjoint PIM domains through the BIER domain.

[nit] s/in PIM domain/in the PIM domain


[nit] s/BBR will create PIM adjacency between/BBR creates a PIM adjacency to

There are several places where you write in the future tense.  Given that this is a specification, please do it in the present: the BBR creates.  I think I may have caught most of the instances in other comments below, but please take a look.


[major] "This draft has chosen these BIER signaling messages to be PIM join/prune message, as such an implementation could chose to tunnel actual PIM join/prune messages through BIER network."

If an implementation chooses to do anything other than what is specified here then it won't be compliant with this document.  If you're going to mention other options then we'll need to have operational guidance on when to use this new mechanism if others are available.

I realize I asked the question -- and to be honest, simply tunneling the actual PIM messages seems easier to me -- but I also have no issues with the WG taking this path.

In summary, I would remove mention of other options to keep the document to the point.  If asked later in the process be ready to answer. :-)


...
177	   The egress BBR will determine if the arriving BIER packet is a
178	   signaling packet and if so it will generate a PIM join/prune packet
179	   toward its attached PIM domain.

[nit] s/egress BBR will determine...and if so it will generate/egress BBR determines...and if so it generates


[minor] s/packet/message


181	   The new procedures in this draft are only applicable to signaling and
182	   there are no changes from datapath point of view.

[nit] s/from datapath point of view/from the datapath point of view


184	3.1.  Ingress BBR procedure
...
189	   When a PIM Join or Prune message is received, the IBBR determines
190	   whether the Source or RP is reachable through the BIER domain.  The
191	   EBBR is the BFR through which the Source or RP is reachable.  In PIM
192	   terms [RFC7761], the EBBR is the RPF Neighbor, and the RPF Interface
193	   is the BIER "tunnel" used to reach it.  The mechanisms used to find
194	   the EBBR are outside the scope of this document and there can be many
195	   mechanism depending on if the source or RP are in same area or
196	   autonomous system (AS) or in different area or AS -- some examples
197	   are provided in Appendix A.

[] "and there can be many mechanism depending on if...area or AS"  I think that this piece of text is superfluous because the mechanisms were just declared out of scope, so it may raise more questions...


199	   If the lookup for source or rendezvous point results into multiple
200	   EBBRs, different IBBRs could choose different EBBRs for the same
201	   flow.  As long as a unique IBBR chooses a unique EBBR for the same
202	   flow.  On downstream these EBBRs will send traffic to their
203	   corresponding IBBRs.

[nit] s/for source/for the source


[nit] s/rendezvous point/RP/g

For consistency and simplicity.


[nit] s/results into multiple/results in multiple

[] Suggestion>
   If the lookup for the source or RP results in multiple EBBRs, an IBBR
   must chose a single EBBR for a specific flow.  Different IBBRs may choose
   different EBBRs for the same flow.  The EBBRs will send downstream traffic
   to their corresponding IBBRs.


205	   After discovering the EBBR and its BFR-id, the IBBR MUST use the BIER
206	   Information Vector (Section 3.1.1) which is a PIM Join Attribute type
207	   [RFC5384].  The EBBR uses this attribute to obtain the necessary BIER
208	   information to build its multicast state.  The signaling packet, in
209	   this case a PIM Join/Prune message, is encapsulated in the BIER
210	   Header and forwarded through the BIER domain to the EBBR.  The source
211	   address of the PIM packets MUST be set to IBBR local BFR-prefix.  The
212	   destination address MUST be set to ALL-PIM-ROUTERS [RFC7761].

[nit] s/IBBR local BFR-prefix/the IBBR's local BFR-prefix


...
220	3.1.1.  New Pim Join Attribute, BIER Information Vector

[] No need to keep repeating "new": this document specifies it and it will not be new soon. ;-)

Suggestion>   BIER Information Vector PIM Join Attribute


222	   The new PIM Join Attribute " BIER Information Vector" is defined as
223	   follow based on [RFC5384]

[] Suggestion>
   The BIER Information Vector PIM Join Attribute [rfc5384] is defined as
   follows:


225	      0                   1                   2                   3
226	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
227	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
228	     |F|E|Attr_Type  |     Length  |  Addr Family    | BIER info
229	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

231	                        Figure 2: PIM Join Attribute

[minor] s/PIM Join Attribute/BIER Information Vector


233	   F bit: Transitive Attribute, as specified in [RFC5384].  MUST be set
234	   to zero as this attribute is always non-transitive.  If EBBR receives
235	   this attribute type with the F bit set it must discard the Attribute.

[major] s/If EBBR receives this attribute type with the F bit set it must discard the Attribute./If the F bit is set, the receiving EBBR MUST discard the attribute.


...
241	   Length: Length of the value field, as specified in [RFC5384].  MUST
242	   be set to the length of the BIER Info field + 1.  For IPv4 the length
243	   is 8, and 20 for IPv6.  Incorrect length value compare to the Addr
244	   Family must be discarded.

[major] s/Incorrect length value compare to the Addr Family must be discarded./If the value doesn't correspond to the Addr Family the receiving EBBR MUST discard the attribute.


246	   Addr Family: PIM address family as specified in [RFC7761].
247	   Unrecognized Address Family must be discarded.

[major] "Unrecognized Address Family must be discarded."  The registry contains many more AFs beyond IPv4/IPv6 what the router may recognize.
rfc7761 doesn't restrict the use to IPv4/IPv6.  Is there any use for an AF that is not IPv4/IPv6?  I don't think there is one.  This document then has to specify any constraints.


249	      0                   1                   2                   3
250	      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
251	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
252	     ~                 IBBR Prefix IPv4 or IPv6                      ~
253	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
254	     | sub-domain-id |        BFR-id                 |
255	     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

257	                    Figure 3: PIM Join Attribute detail

[minor] s/PIM Join Attribute detail/BIER Info field detail


259	   BIER Info: IBBR's BFR-prefix (IPv4 or IPv6), sub-domain-id, BFR-id

[major] Please describe (as above) these additional fields.


[] The flow of the text worked better with the figure *after* the Bier Info is introduced.


[major] What should the receiver do if multiple instances of this attribute are received?


261	3.1.1.1.  BIER packet construction at the IBBR

263	   The BIER header will be encoded with the BFR-id of the IBBR(with
264	   appropriate bit set in the BitString) and the PIM signaling packet is
265	   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.  You should also be able to remove §3.2.

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).


...
284	   BIERHeader.Proto = PIM Addrress Family

[] The nomenclature BIERHeader.* may be obvious, but it is not defined anywhere.  It is not used in rfc8296, etc.


[major] There is no value for Proto that corresponds to "PIM Address Family".  Are you trying to indicate that the Proto value has to match the Addr Family value in the attribute?  Why?  What if they don't?
Note that rfc7761 doesn't require that.


285	   BIERHeader.BitString= Bit corresponding to the BFR-id of the EBBR

[major] This is not how rfc8296 defines the BitString: it is not a bit, it is a field...


[major] Also (and this is repeated in 3.2), it sounds as if the intent is for the BitString to identify a single EBBR.  If the IBBR includes multiple destinations then the packet will be replicated, and no possible action can be taken.  While the expected EBBR will still receive the information, there is no way to prevent replication.


[related] With BIER-TE, the BitString may have more than one bit set and still represent a single EBBR.


...
290	   Rest of the values in the BIER header are determined based on the
291	   network (MPLS/non-MPLS), capabilities (BSL), and network
292	   configuration.

[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


...
306	3.3.  EBBR procedure

308	   EBBR removes the BIER Header and determine this is a signaling
309	   packet.  The Received signaling packet, PIM join/prune message, is
310	   processed as if it were received from neighbors on a virtual
311	   interface, (i.e. as if the pim adjacency was present, regardless of
312	   the fact that there is no adjacency).

[nit] s/EBBR removes...determine/The EBBR removes...determines


314	   The EBBR will build a forwarding table for the arriving (S,G) using
315	   the obtained BFIR-id and the Sub-Domain information from BIER Header
316	   and/or the PIM join Attributes added to the signaling packet.  In
317	   short it tracks all IBBRs interested in this (S,G).  For a specific
318	   Source and Group, EBBR SHOULD track all the interested IBBRs via
319	   signaling messages arriving from the BIER Domain.  BFER builds its
320	   (s,g) forwarding state with incoming interface (IIF) as the Reverse
321	   Path Forwarding (RPF) interface (in attached PIM domain) towards the
322	   source or rendezvous point.  The outgoing interfaces include a
323	   virtual interface that represent BIER forwarding to tracked IBBRs.

[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.


[major] "using the obtained BFIR-id...from BIER Header and/or the PIM join Attributes"    What does "and/or" indicate?  Does it mean that either is ok?  What if the values are different?   I had asked this before, and the answer was this:

=====
[major] What should a receiver do if the BFR-id doesn't match the BFIR-id in the BIER Header?

HB> not much can be done here, the reason we added the PIM information 
HB> vector was because some HW couldn’t read into the BIER header. 
HB> Ideally this attribute is not needed but we agreed on it because of explained reason.
=====

I don't understand how a BIER router is not able to read the BIER Header.  It it a necessary operation to support/implement BIER.  What am I not understanding?

The specification should be deterministic, using "and/or" leaves the door open to inconsistent implementations.  Please be specific about the value to be used.


[nit] s/EBBR SHOULD/the EBBR SHOULD


[major] "EBBR SHOULD track all the interested IBBRs"   When is it ok for the EBBR to not track?  Why is this recommended and not required?


[minor] "track all the interested IBBRs via signaling messages arriving from the BIER Domain"  Should a Holdtime of 0xffff be disallowed?


[minor] s/BFER builds/The EBBR builds


[nit] s/(s,g) forwarding state/forwarding state


[nit] s/with incoming interface/with the incoming interface


[nit] s/in attached PIM domain/in the attached PIM domain


[minor] s/include a virtual interface that represent BIER forwarding to tracked IBBRs./include all virtual interfaces in the BIER domain towards the tracked IBBRs.


[minor] The text is written for an (S,G), what about (*,G)?  The text seems to apply, but it should be specific about it.


...
329	4.  Datapath Forwarding
330	4.1.  Datapath traffic flow

[nit] Add a space.


...
338	5.  PIM-SM behavior

[] Now that the text has been updated to include "source or RP", I don't think this section is needed.


...
360	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.


...
399	8.  Security Considerations

401	   The procedures of this document do not, in themselves, provide
402	   privacy, integrity, or authentication for the control plane or the
403	   data plane.  For a discussion of the security considerations
404	   regarding the use of BIER, please see [RFC8279] and [RFC8296].  The
405	   security consideration for [RFC7761] aslso apply.

[nit] s/consideration for [RFC7761] aslso/considerations in [RFC7761] also


[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).


407	9.  Acknowledgments

409	   The authors would like to thank Eric Rosen, Stig Venaas for thier
410	   reviews and comments.

[nit] s/thier/their


...
453	A.1.  Link-State Protocols

455	   On IBBR SPF procedures can be used to find the EBBR closest to the
456	   source.

[minor] source or RP...  You updated all other mentions of "source" to make it clear that the same applies to the RP, except for this Appendix.  This is a minor point, but consistency would be very nice.


...
475	A.2.2.  Interior Border Gateway Protocol (iBGP)
...
485	   Suppose BGP is enable between EBBR (B) and IBBR (D) and the PIM
486	   Domain routes are redistributed to the BIER domain via BGP,
487	   performing next-hop-self for these routes.  This would include the
488	   Multicast Source IP address (S).  In such case BGP should use the
489	   same next-hop as the EBBR BIER prefix.  This will ensure that all PIM
490	   domain routes, including the Multicast Source IP address (S) are
491	   resolve via EBBR's BIER prefix address.  When the host (h) triggers a
492	   PIM join message to IBBR (D), IBBR tries to resolve (S).  It resolves
493	   (S) via BGP installed route and realizes its next-hop is EBBR (B).

[major] Where is "next-hop-self" specified/defined?   I know what it is, I've configured the knob many times, but it is not specified in any document that can be referenced here, as far as I know.  Even if this is an example (in the Appendix), please be specific in what you mean -- don't assume people know what you mean.


[nit] s/are resolve via EBBR's/are resolved via the EBBR's


[nit] s/IBBR tries to resolve (S).  It resolves (S) via BGP installed route and realizes its next-hop is EBBR (B)./the IBBR resolves (S) via the BGP installed route and realizes its next-hop is the EBBR (B).

[End of Review -12]