[Bier] A new comment about https://datatracker.ietf.org/doc/html/draft-ietf-bier-idr-extensions

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

Hi,

Currently, the BIER-BGP draft does not handle the situation of BIER-incapable routers. This is pointed out in the multicast/bier-as-a-service draft:

   The BGP signaling and a necessary enhancement can be explained using
   the following example.  EBFR43 advertises its BIER prefix (a loopback
   address) as /32 IPv4 or /128 IPv6 prefix in BGP with a BIER Path
   Attribute (BPA) [RFC8279] [I-D.ietf-bier-idr-extensions].  ASBR431
   receives it and re-advertises it (with BGP Next Hop changed to
   itself) but does not do anything wrt BIER because it does not support
   BIER.  Same happens on ASBR341.  When ASBR311 and ASBR351 receive it
   from ASBR341, they create a BIFT entry corresponding to EBFR43's BFR-
   ID.  The entry causes a BIER packet with corresponding bit set in its
   BitString to be tunneled to EBFR43.  This cannot be based on BGP Next
   Hop in the advertisement because the BGP Next Hop is ASBR341.  When
   eventually EBFR11 receives the re-advertised route, it creates a BIFT
   entry that causes corresponding packets to be tunneled to ASBR311
   (but not to EBFR43 directly).  Now it is clear that this cannot be
   based on either the BIER prefix itself or the BGP Next Hop.  The
   solution is that the originating EBFR attaches a Tunnel Encap
   Attribute (TEA) [RFC9012] with the tunnel destination set to itself,
   and whenever a BFR re-advertises the route it changes the tunnel
   destination to itself.  When a BFR creates the BIFT entry, it uses
   the Tunnel Egress Endpoint in the TEA to find out where to tunnel
   packets.

The above also pointed out a solution based on TEA that is later specified in https://datatracker.ietf.org/doc/html/draft-ietf-bier-multicast-as-a-service-01.html#section-2.1.

Now I realize that, with the above procedure, transit BFRs do *not* need to advertise BIER info with their own BIER prefix anymore. Anytime a BGP BFR re-advertise a BFER prefix, it only need to change the BIER Info to its own, instead of separately advertise its own BIER info with its own prefix.

Additionally, we don't need to use the TEA to specify the "tunnel" endpoint. We can simply add a sub-TLV in the BIER Info TLV to specify the tunnel endpoint (which is BFER itself when the BFER prefix is originated, and the re-advertising BGP BFR when it is re-advertised by a BGP BFR).

Thoughts?

Thanks.
Jeffrey

Juniper Business Use Only