Last Call Review of draft-ietf-bier-idr-extensions-11
review-ietf-bier-idr-extensions-10-rtgdir-lc-talaulikar-2024-02-12-01

Hello All,

This is the updated RTGDIR review for the revised version 11 of the draft that
has been updated to address the comments from the previous review.

There are minor comments and nits that need to be addressed as described
below.

Thanks,
Ketan



idnits 2.17.1 

draft-ietf-bier-idr-extensions-11.txt:


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 6 instances of too long lines in the document, the longest one
     being 2 characters in excess of 72.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     It's possible that the BFR supports some but not all BSLs in the
     received MPLS or non-MPLS Encapsulation sub-TLVs.  After updating the
     BIER Nexthop sub-TLV in the top BIER TLV to itself, for the BSLs that it
     does support, the BFR MUST remove the BIER Nexthop sub-TLV (if present)
     in the corresponding Encapsulation sub-TLVs.  For the BSLs that it does
     not support, it MUST not update those Encapsulation sub-TLVs except that
     if a BIER Nexthop sub-TLV is not included in the Encapsulation sub-TLV,
     the received BIER Nexthop sub-TLV in the top BIER TLV MUST be copied into
     the Encapsulation sub-TLV.  All impacted length fields (e.g., the
     Encapsulation sub-TLV Length, the top level BIER TLV Length) MUST be
     updated accordingly.

  -- The document date (3 June 2024) is 116 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'RFC8296' is mentioned on line 282, but not defined

  == Outdated reference: A later version (-07) exists of
     draft-ietf-bier-prefix-redistribute-06


     Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

119	3.  BIER Path Attribute

121	   This draft defines a new optional, transitive BGP path attribute,
122	   referred to as the BIER attribute.  This attribute can be attached to
123	   a BGP UPDATE message by the originator for NLRIs of AFI 1/2 and SAFI
124	   1/2/4 so as to indicate the BIER-specific information of a particular
125	   BFR identified by the /32 or /128 host address prefix contained in
126	   the NLRI, or a set of BFERs covered by a non-host address prefix
127	   [I-D.ietf-bier-prefix-redistribute].  In other words, if the BIER
128	   path attribute is present, the NLRI is treated by BIER as a "BFR-
129	   prefix".  Use of the attribute with other AFIs/SAFIs is outside the
130	   scope of this document.

132	   The BIER path attribute is encoded in the TLV format shown in the
133	   following figure.

135	       0                   1                   2                   3
136	       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
137	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
138	      |              Type             |             Length            |
139	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
140	      ~                        Value (variable)                       ~
141	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

143	                                  Figure 1

145	   The Length field defines the length of the value portion in octets
146	   (thus, a TLV with no value portion would have a length of zero).  The
147	   TLV is not padded to 4-octet alignment.  Unknown and unsupported
148	   types MUST be preserved and propagated within both the NLRI and the
149	   BGP-LS Attribute.  The presence of unknown or unexpected TLVs MUST
150	   NOT result in the NLRI or the BGP-LS Attribute being considered
151	   malformed.

[nit] s/BGP-LS/BIER

153	   When creating a BIER attribute, a BFR needs to include one BIER TLV
154	   for every Sub-domain that the prefix belongs to.  The attribute type
155	   code for the BIER Attribute is TBD.  The value field of the BIER
156	   Attribute contains one or more BIER TLV as shown in Figure 2.

158	       0                   1                   2                   3
159	       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
160	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
161	       |           Type = 1            |            Length             |
162	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
163	       |  Sub-domain   |            BFR-ID             |   Reserved    |
164	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
165	       ~                                                               ~
166	       |                           Sub-TLVs                            |
167	       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................

169	                               Figure 2

171	      Type: 1.

173	      Length: Two octets encoding the length in octets of the Value
174	      part.

176	      Sub-domain: a one-octet field encoding the sub-domain ID
177	      corresponding to the BFR-ID.

179	      BFR-ID: a two-octet field encoding the BFR-ID.

[minor] Please give reference pointers (with sections, if possible) to the
base BIER RFCs for terminologies like sub-domain, BFR-ID, etc. when first
introduced in this document.

181	      Sub-TLVs: contains one or more sub-TLV.

[minor] Just confirming that it MUST contain at least one sub-TLV ...

183	   The BIER TLV MAY appear multiple times in the BIER Path Attribute,
184	   one for each sub-domain.  There MUST be no more than one BIER TLV
185	   with the same Sub-domain value; if there is, the entire BIER Path
186	   Attribute MUST be ignored.

188	   A BIER TLV may have sub-TLVs, which may have their own sub-TLVs.  All
189	   those are referred to as sub-TLVs and share the same Type space,
190	   regardless of the level.


326	4.  Originating/Propagating/Updating BIER Attribute

328	   The use of BIER attribute with a non-host BFR-prefix NLRI is covered
329	   in [I-D.ietf-bier-prefix-redistribute].

331	   A BIER Forwarding Egress Router (BFER) MUST attach a BIER attribute
332	   to its own host BFR-prefix NLRI.  The BIER attribute MUST include one

[minor] When you say "host", you mean local? Like a loopback? Perhaps you
mean, when the local /32 or /128 that is the BFR Prefix is advertised via
BGP (e.g., AFI=1/2, SAFI=1), then the BIER attribute is attached to it?

333	   BIER TLV for each BIER sub-domain that it supports.  Each BIER TLV
334	   MUST include an MPLS and/or non-MPLS Encapsulation sub-TLV, and
335	   SHOULD include a BIER Nexthop sub-TLV with the Nexthop set to the
336	   BIER prefix.  If the BIER Nexthop sub-TLV is not included, the BIER
337	   prefix will be used by receiving BFRs as the BIER nexthop when
338	   calculating BIFT.

340	   When a BGP speaker receives an update with the BIER path attribute,
341	   the syntactic validation of the attribute is done regardless if the
342	   speaker is a BFR or not, and appropriate action is taken, e.g.,
343	   performing an "attribute discard" action [RFC7606] about the BIER
344	   attribute.  If it is a BFR, then semantics validation of the BIER
345	   path attribute is done.  If the validation passes, BIFT entries are
346	   calculated as described in Section 5.  Otherwise, some or all BIER
347	   TLVs MUST be ignored and not re-advertised further.  However, as long
348	   as the syntactic validation of the BIER path attribute passes, the
349	   route is useable for non-BIER purposes.

351	   When a BFR re-advertises a BGP NLRI with a BIER attribute, for the
352	   sub-domains that this BFR supports, in the corresponding BIER TLV it
353	   SHOULD set/update the BIER Nexthop sub-TLV to use its own BIER
354	   prefix, in which case it MUST replace the MPLS or non-MPLS
355	   Encapsulation sub-TLV with its own, i.e., as if the BFR is attaching
356	   the encapsulation sub-TLV for its own BIER prefix.  If it does not
357	   update the BIER Nexthop sub-TLVs, it MUST NOT update MPLS or non-MPLS
358	   Encapsulation sub-TLV.  If it does not support a sub-domain, it MUST
359	   NOT update the corresponding BIER TLV.

361	   It's possible that the BFR supports some but not all BSLs in the
362	   received MPLS or non-MPLS Encapsulation sub-TLVs.  After updating the
363	   BIER Nexthop sub-TLV in the top BIER TLV to itself, for the BSLs that
364	   it does support, the BFR MUST remove the BIER Nexthop sub-TLV (if
365	   present) in the corresponding Encapsulation sub-TLVs.  For the BSLs
366	   that it does not support, it MUST not update those Encapsulation sub-
367	   TLVs except that if a BIER Nexthop sub-TLV is not included in the
368	   Encapsulation sub-TLV, the received BIER Nexthop sub-TLV in the top
369	   BIER TLV MUST be copied into the Encapsulation sub-TLV.  All impacted
370	   length fields (e.g., the Encapsulation sub-TLV Length, the top level
371	   BIER TLV Length) MUST be updated accordingly.

373	   Since the BIER attribute is an optional, transitive BGP path
374	   attribute, a non-BFR BGP speaker could still advertise the received
375	   route with a BIER attribute.

377	   Two different BFR-prefixes MUST NOT have the same non-zero BFR-ID in
378	   the same sub-domain.  If a duplication is detected, the receiving BFR
379	   MUST NOT use it for BIFT calculation for the sub-domain and an error
380	   SHOULD be logged.  The BFR SHOULD discard the BIER attribute that
381	   contains the duplicate BFR-ID.


448	7.  Operational Considerations

450	   It's assumed by this document that the BIER domain [RFC8279] is
451	   aligned with an Administrative Domain (AD) which may be composed of
452	   multiple ASes (either private or public ASes).  Use of the BIER
453	   attribute in other scenarios is outside the scope of this document.

455	   A boundary router of the AD that supports the BIER attribute MUST

[nit] s/AD/AS

456	   support a per-EBGP-session/group policy, that indicates whether the
457	   attribute is allowed and by default it is NOT allowed.  If it is not
458	   allowed, the BIER attribute MUST NOT be sent to any EBGP peer of the
459	   session/group, and the BIER attribute received from the peer MUST be
460	   treated exactly as if it were an unrecognized non-transitive
461	   attribute.  That is, "it MUST be quietly ignored and not passed along
462	   to other BGP peers".

464	8.  Acknowledgements

466	   Thanks a lot for Eric Rosen and Peter Psenak for their valuable
467	   comments on this document.

469	9.  IANA Considerations

471	   IANA is requested to assign a codepoint TBD in the "BGP Path
472	   Attributes" registry to the BIER attribute.

474	   IANA is requested to create a registry for "BGP BIER TLV and SUB-TLV

[minor] I assume you mean this registry to be created under the BGP Parameter
registry group?

475	   Types".  The type field for the registry consists of two octets, with
476	   possible values from 1 to 655355 (the value 0 is reserved).  The
477	   allocation policy for this field is to be "First Come First Serve"
478	   [RFC8126].

480	   Four initial values are to be allocated from the "BGP BIER TLV and
481	   Sub-TLV Types" registry as follows:

483	      1: BIER TLV

485	      2: MPLS Encapsulation sub-TLV

487	      3: non-MPLS Encapsulation sub-TLV

489	      4: BIER Nexthop sub-TLV

491	10.  Security Considerations

493	   This document introduces no new security considerations beyond those
494	   already specified in [RFC4271] and [RFC8279].

[minor] Since the BIER attribute is associated with prefixes in BGP AFI=1/2
SAFI = 1, perhaps some discussion may be needed that this is for local
infrastructure loopback prefixes and not meant to be advertised out over the
Internet.