[Bier] Re: John Scudder's Discuss on draft-ietf-bier-idr-extensions-17: (with DISCUSS and COMMENT)

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi John,

Thanks for your review, comments and suggestions.
I have submitted revision -18 which should address your comments per our offline discussion: https://author-tools.ietf.org/iddiff?url2=draft-ietf-bier-idr-extensions-18

Some responses included below (prefixed with zzh>) for the benefit of the group.

Thanks!

Jeffrey


Juniper Business Use Only
-----Original Message-----
From: John Scudder via Datatracker <[e-mail]>
Sent: Monday, December 16, 2024 9:19 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]; [e-mail]
Subject: John Scudder's Discuss on draft-ietf-bier-idr-extensions-17: (with DISCUSS and COMMENT)

[External Email. Be cautious of content]


John Scudder has entered the following ballot position for
draft-ietf-bier-idr-extensions-17: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!C5uyrIplylnZoPf_Hj8UXuHhELICnFW4nGDELSopwDitJhZUjZkc-QT6mRtYcZcyIe179Pkm2re0HvQ$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-bier-idr-extensions/__;!!NEt6yMaO-gk!C5uyrIplylnZoPf_Hj8UXuHhELICnFW4nGDELSopwDitJhZUjZkc-QT6mRtYcZcyIe179PkmsowpWsI$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document. I enjoyed reading it and my discuss points notwithstanding, I think its fundamentals are solid.

## DISCUSS

### Sections 3 and 4, is prefix-redistribute normative?

You reference I-D.ietf-bier-prefix-redistribute in two places. Section 3:

   This draft defines a new optional, transitive BGP path attribute,
   referred to as the BIER attribute.  This attribute can be attached to
   a BGP UPDATE message by the originator for NLRIs of AFI 1/2 and SAFI
   1/2/4 so as to indicate the BIER-specific information of a particular
   BFR identified by the /32 (for IPv4) or /128 (for IPv6) host address
   prefix contained in the NLRI, or a set of BFERs covered by a non-host
   address prefix [I-D.ietf-bier-prefix-redistribute].

Section 4:

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

These would be fine if the reference were normative, so the most straightforward fix is to move it to a normative reference. I understand that you may not want to do that since then it would gate publication of the present spec on the advancement of the reference. In that case, you could limit the present spec to the host route case. I understand you might want to be kind to the reader by giving them some hints about what's coming. I think you can still do that as long as you're a little more diplomatic about it, something like,

NEW (Section 3):
   This specification defines an optional, transitive BGP path attribute,
   referred to as the BIER attribute.  This attribute can be attached to
   a BGP UPDATE message by the originator for NLRIs of AFI 1 or 2 and SAFI
   1, 2, or 4 to indicate the BIER-specific information of a particular
   BFR identified by the /32 (for IPv4) or /128 (for IPv6) host address
   prefix contained in the NLRI.  The attachment of the BIER attribute to
   non-host address prefixes is not defined by this document.  It may be
   specified in the future, for example by [I-D.ietf-bier-prefix-redistribute].

I also changed "draft" to "specification" and removed "new", it will age better that way, and changed "1/2" to "1 or 2" since there's no AFI one-half ;-)

And,

NEW (Section 4):
   Recall that the use of the BIER attribute with a non-host BFR-prefix NLRI
   is not defined by this document.

Although you could just delete that paragraph instead.

Of course, you don't have to use the proposed text, anything that makes it clear the reference to that draft is non-normative would be OK [*]. If neither one of these resolutions works for you, we should have a discussion about it.

[*] No, putting it in the "non-normative" section of the references, while necessary, is not sufficient.

Zzh> Very good suggestions. I've changed it accordingly.

s### Section 4, attribute error handling procedures are underspecified

   When a BGP speaker receives an update with the BIER path attribute,
   the syntactic validation of the attribute is done regardless if the
   speaker is a BFR or not, and appropriate action is taken, e.g.,
   performing an "attribute discard" action [RFC7606] about the BIER
   attribute.

There are two main deficiencies I see here. First, you tell the reader to do "syntactic validation," but not what that validation is. I realize there are differences of opinion in how prescriptive to be, and spelling things out in picky detail like RFC 7606 does is not fun and arguably can never be complete anyway. Still, even though it's not fun I would encourage you to try harder than you have.

Second and more important, you say "appropriate action" but don't specify. You provide an example of one action that might be appropriate, but RFC 7606 (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc7606*autoid-29__;Iw!!NEt6yMaO-gk!C5uyrIplylnZoPf_Hj8UXuHhELICnFW4nGDELSopwDitJhZUjZkc-QT6mRtYcZcyIe179Pkm8N8hQTc$ ) and common sense both say that you should be prescriptive at least in this respect. I agree "attribute discard" is suitable in this case. So something like,

NEW1:
   When a BGP speaker receives an update with the BIER path attribute,
   syntactic validation of the attribute (details to be supplied, could
   be an xref to a different subsection) is done regardless of whether the
   speaker is a BFR or not.  A malformed BIER attribute MUST be handled
   using the "attribute discard" approach [RFC7606].

If you don't love the MUST you could change it to a SHOULD:

NEW2:
   When a BGP speaker receives an update with the BIER path attribute,
   syntactic validation of the attribute (details to be supplied, could
   be an xref to a different subsection) is done regardless of whether the
   speaker is a BFR or not.  A malformed BIER attribute SHOULD be handled
   using the "attribute discard" approach [RFC7606] although it MAY be
   handled using one of the stricter approaches given in Section 2 of
   [RFC7606].

I don't see why you'd ever want to choose one of the other options though (treat-as-withdraw, afi/safi disable, session reset) so ISTM you might as well use the simpler paragraph.

Zzh> Please see my attempt in the diff.

Finally, this from a little further down the paragraph seems wrong:

                                                        However, as long
   as the syntactic validation of the BIER path attribute passes, the
   route is useable for non-BIER purposes.

You've specified "attribute discard" for your error-handling strategy, so even if syntactic validation fails the route can be used for non-BIER purposes. I think you should either delete this sentence, or rewrite as,

NEW:
                                                        However, the
   route is useable for non-BIER purposes.

If this isn't OK then we need to have a longer discussion because one of us has misunderstood something.

Zzh> Yes. I removed the sentence.

### Section 4, duplication handling

   Two different BFR-prefixes MUST NOT have the same non-zero BFR-ID in
   the same sub-domain.  If a duplication is detected, the receiving BFR
   MUST NOT use it

What's "it"? The route that is detected as duplicating one that has already been received? Any route that contains that BFR-ID? The former would ignore one or more routes seemingly at random, the latter would make duplication poison that BFR-ID. For sake of discussion I'm assuming the former.

Zzh> The latter. When there is a dup, the BFR-ID (hence all the BFR-prefixes with that ID) must not be used.

                   for BIFT calculation for the sub-domain and an error
   SHOULD be logged.  The BFR SHOULD discard the BIER attribute that
   contains the duplicate BFR-ID.

This worries me because there's no guaranteed temporal ordering between arrival of routes for different prefixes even from the same peer, much less from different peers. Let's say route A for prefix A' and route B for prefix B' have the same non-zero BFR-ID in the same sub-domain. BFR1 receives route A, then route B. It discards the attribute for B and proceeds with its computation using A (if I've correctly guessed your intent). BFR2 receives route B, then route A. It discards the attribute for A and proceeds with its computation using B. Is this fine and dandy, or concerning?

Zzh> Now I believe the BIER attribute must not be discarded, so that everyone can discover the duplicate. I've removed the last sentence.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


## COMMENT

### Abstract

I have two small editorial comments:

   Bit Index Explicit Replication (BIER) is a multicast forwarding
   architecture that doesn't require an explicit tree-building protocol
   and doesn't require intermediate routers to maintain per-tree
   multicast states.  Some BIER-specific information and state, which
   are only in proportion to the network but not per-tree, do need to be

"Only in proportion to the network" isn't very precise. Maybe you mean "number of routers in the network" or something like that. Perhaps even "number of BIER routers".

Zzh> Changed to "in proportion to the number of BIER routers".

   advertised, calculated, and maintained.  This document describes BGP
   extensions for advertising the BIER information and methods for
   calculating BIER states based on the advertisement in a single
   Administrative Domain.

Even after reading (and I think, understanding) the spec, I'm still not sure what you mean by "based on the advertisement in a single Administrative Domain". Are you trying to say the specification only applies to operation within a single Administrative Domain? If so it might be better to have a short declarative sentence directly to that effect, or even leave the caveat out of the Abstract. Something like,

   advertised, calculated, and maintained.  This document describes BGP
   extensions for advertising the BIER information and methods for
   calculating BIER states based on those advertisements.

and if you want to add the caveat, add on something like,

   Although BGP is an inter-domain protocol, this use of BGP is expected to
   be limited to a single Administrative Domain, in keeping with the overall
   BIER architecture.

Zzh> The sub-domain and BFR-ID configuration need to be consistent within a BIER domain. In the case of IGP that can be easily done. In the case of BGP, the easiest way is to limit it an AD. Another reason for introducing the AD here was to address the concern of "attribute escape" brought up by an earlier reviewer.
Zzh> I removed the caveat from the abstract.

### Section 3, the TLVs go inside the PA value field

   The BIER path attribute is encoded in the TLV format shown as
   follows:

This is a tad confusing because a BGP path attribute is itself a TLV. I suggest rewarding something like,

   The BIER path attribute is an optional, transitive BGP path attribute
   with type code TBD and of variable length. The attribute value portion
   carries BIER TLVs, which are encoded as follows:

zzh> Yes. Fixed.

### Section 3, unknown and unsupported types... within the NLRI

                                            Unknown and unsupported
   types MUST be preserved and propagated within both the NLRI and the
   BIER Attribute.

What does it mean for an unknown/unsupported type to be preserved and propagated within the NLRI? Within the attribute is easy to understand, but you aren't changing the NLRI format, so that seems like a non-sequitur.

Perhaps delete "both the NLRI and", so:

                                            Unknown and unsupported
   types MUST be preserved and propagated within the
   BIER Attribute.

Zzh> You're right. Fixed.

### Section 3.3, recurrence of NH sub-TLV

You don't forbid the presence of multiple NH sub-TLVs at any given level of the sub-TLV hierarchy. If this is covered in Section 4 or 5 I missed it, but either way it seems like you ought to say something here. AFAICT there should be only one at any given level. (Maybe there's a case for one IPv4 and one IPv6 NH? But probably not.)

Zzh> Right. Changed.

If you do deliberately permit multiple can you help me understand how I'm supposed to handle it if I find two NH sub-TLVs at the top level (for example)?

### Section 4, why bother including the Nexthop in the paragraph 2 case?

It's not a big deal, but in this case,

   A BIER Forwarding Egress Router (BFER) MUST attach a BIER attribute
   to its own /32 (for IPv4) or /128 (for IPv6) host BFR-prefix NLRI.
   The BIER attribute MUST include one BIER TLV for each BIER sub-domain
   that it supports.  Each BIER TLV MUST include an MPLS and/or non-MPLS
   Encapsulation sub-TLV, and SHOULD include a BIER Nexthop sub-TLV with
   the Nexthop set to the BIER prefix.  If the BIER Nexthop sub-TLV is
   not included, the BIER prefix will be used by receiving BFRs as the
   BIER nexthop when calculating BIFT.

why would you bother including the nexthop, i.e. why the SHOULD? It's by-definition redundant information.

Zzh> You're right. I changed it to MAY.

### Section 4, BSL

You did expand BSL way back in Section 1, but since you've reintroduced it here, it would have helped me to have it expanded on first use in Section 4. If you don't want to do that, I suggest putting it in your glossary.

Honestly, my favorite fix would be to just use "BitString Length" everywhere and get rid of the gratuitous abbreviation... although if "BSL" is already an established term in the BIER document set I suppose it's too late.

Zzh> I added it to the glossary and expanded it in Section 4.

### Section 4, not neutronium, but close; also an oversight

While brevity is the soul of wit and I admire your ability to cram a lot of specification into a few paragraphs, this section was not easy for me as a reader. Offering a rewrite is something I wouldn't want to put the work into unless you're keen to have it, but if I were to attempt it, the general idea would be to break the long discursive paragraphs with conditional branching within the sentences into short declarative chunks. As an example, one might change,

                                                          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.

Into something like,

   For BSLs that it does not support:

   - If a BIER Nexthop sub-TLV is included in the Encapsulation sub-TLV, do
     nothing.
   - 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.

And oh by the way, even if you stick with your current writing style (and it's OK if you do), don't you need to fix "the received BIER Nexthop sub-TLV in the top BIER TLV MUST be copied", because there might not be such a thing at all, if the paragraph 2 default action of inferring the value from the BIER prefix has been followed?

Zzh> Good catch. Please see the diff.

### Section 6

As I briefly discussed with Jeffrey offline, there looks to be a bug here:

   The BFER1/2/3 each advertises a route for its loopback address with a
   BIER path attribute, listing one BIER TLV for each subdomain that it
   is in, with a non-zero BFR-ID and an MPLS Encapsulation sub-TLV.  A
   BIER Nexthop sub-TLV is included in the one from BFER1 but not the
   ones from BFER2/3.  The BIER Nexthop sub-TLV encodes the addresses of
   BFER2 and BFER3 respectively.

   When BFR2 receives the route, it calculates its BIFT entries.
   Because the route from BFER1 does not include a BIER Nexthop, BFR2
   uses BFRer1's BFR-prefix as the nexthop.

I think in the first paragraph you must have meant,

   A BIER Nexthop sub-TLV is not included in the one from BFER1 but is
   included in the ones from BFER2 and BFER3.

Zzh> Right. I've corrected it.

Zzh> Thanks a lot for your detailed comments and suggestions! It really improved the quality significantly, and the suggestions made it easier.
Zzh> Jeffrey