Re: [Bier] Shepherd review of draft-ietf-bier-idr-extensions

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

Hi,

More shepherd review comments below.

The abstract and introduction section talk about data center use case. While it does say " These extensions may also be  applicable in other scenarios", I don't think we need to call out the data center use case - it equally applies to other scenarios as well. With that I suggest the following text:

   Bit Index Explicit Replication (BIER) is a new multicast forwarding
   architecture which doesn't require an explicit tree-building protocol
   and doesn't require intermediate routers to maintain per-flow/tree
   state.  BIER-specific information does need to be signaled with routing
   protocol extensions, and this document
   describes BGP extensions for advertising the BIER-specific information.

End of the introduction section has the following:

   These extensions are applicable in those multi-tenant data centers
   where BGP instead of IGP is used as an underlay [RFC7938].  These
   extensions may also be applicable to other BGP based network
   scenarios.

It can either be removed, or if we want to keep it then it should have an informational reference to draft-zzhang-bier-multicast-as-a-service for "other ... scenarios".

      BSL: a one-octet field indicating the length of the Bitstring in
      4-octets.  The field MUST be filled with one of the valid BSL
      values as specified in [RFC8279].  Upon receiving a BSL-TLV
      containing an invalid BSL value, it MUST be ignored.

I can't find in RFC8279 about the bitstringlength encoding. I suspect it is the 4-bit encoding as in RFC8296, which is also how IGP signaling does it. This paragraph probably should be corrected. If it is indeed 4-bit, maybe it should be combined with the label field (currently the label field uses 3-octets but 4-bit of that is not used) - just like in IGP case.

   An implementation that supports the BIER attribute MUST support a
   per-EBGP-session policy, that indicates whether the attribute is
   enabled or disabled for use on that session.  The BIER attribute MUST

The above seems to imply the policy is for both sending and receiving.

   NOT be sent on any EBGP peers for which the session policy is not
   configured.  If an BIER attribute is received on a BGP session for
   which session policy is not configured, then the received attribute
   MUST be treated exactly as if it were an unrecognised non-transitive
   attribute.  That is, "it MUST be quietly ignored and not passed along
   to other BGP peers".

The above is about receiving.

   To prevent the BIER attribute from "leaking out" of an BIER domain,
   each BGP router on the BIER domain MUST support an outbound route
   announcement policy.  Such a policy MUST be disabled on each EBGP
   session by default unless explicitly configured.

The above is about sending; but is it a different policy or the same as the one mentioned above? Does a non-ASBR BFR need that policy? The first sentence does say "each BFR" but do we really need it on non-ASBRs?

   Since the BIER attribute is an optional, transitive BGP path
   attribute, a non-BFR BGP speakers could still advertise the received
   route with a BIER attribute.  This is desirable in the incremental
   deployment scenario where a BGP speaker could tunnel a BIER packet or
   the payload of a BIER packet to a BFER directly if the BGP next-hop
   of the route for that BFER is a non-BFR.

Why is the "or the payload of a BIER packet" there?  Should it be deleted?

Thanks.
Jeffrey

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang
Sent: Friday, December 10, 2021 11:20 AM
To: [e-mail]; BIER WG <[e-mail]>
Subject: Shepherd review of draft-ietf-bier-idr-extensions

Hi,

I have not done a thorough review but I realize that non-MPLS encapsulation is not covered in this. I believe non-MPLS encapsulation is already well thought and mature, and even covered in the bgp-ls extension draft, so I think it's good to non-MPLS encapsulation here as well.

Jeffrey

Juniper Business Use Only