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

Hi Jeffrey, 
These clarification looks good to me.
Thank you!
Best regards,
Sandy

------------------Original------------------
From: Jeffrey(Zhaohui)Zhang <zzhang@juniper.net>
To: 张征00007940;
Cc: bier@ietf.org <bier@ietf.org>;
Date: 2022年09月21日 09:38
Subject: RE: [Bier] A new comment about https://datatracker.ietf.org/doc/html/draft-ietf-bier-idr-extensions
Hi Sandy,
Thanks for your follow up - they're good comments that can be incorporated together with the suggestions that I was proposing.
The BIER-NH does not have to be mandatory. If it is not present, then it can be assumed that it is the BIER prefix itself.
Jeffrey
Juniper Business Use Only
-----Original Message-----
From: zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
Sent: Friday, September 16, 2022 11:02 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: bier@ietf.org
Subject: Re: [Bier] A new comment about https://datatracker.ietf.org/doc/html/draft-ietf-bier-idr-extensions
[External Email. Be cautious of content]
Hi Jeffrey,
Sorry for the late response, I just find this mail and I think this discussion makes sense.
I'd like to summary the new proposal, could you please tell me if I understand right?
1. When BGP is used to advertise the info, it does not use TEA, but adds a sub-tlv to the BGP Attribute (an attribute newly added in the IDR draft), indicating BIER-NH; 2. Whether it is a BFER or an intermediate BFR, set BIER Attr (including BIER-NH) of itself when sending; (one question, is this BIER-NH sub-tlv a mandatory option? That is, it must be carried when BGP announces BIER Attribute?) 3. BFR does not advertise its own BFR-Prefix (or advertise optional), but directly forwards the BFR-Prefix that advertises BFER (by the way, BIER-NH is set in point 2); this method will advertise the BGP Prefix in multiple domains, but BGP itself has the characteristics of this cross-domain route propagation; 4. Point 3, BFR can also consider using aggregated routes when forwarding BFR-Prefixes of other domains. In this case, the label-range sub-tlv defined in the Prefix Distribute can be advertised; 5. If BFR does not want to forward prefixes of other domains, it can also advertise its own BF
 R-Prefix and carry the label-range sub-tlv defined in Prefix Distribute, and also set BIER-NH to Own.
Thanks,
Sandy
------------------Original------------------
From: Jeffrey(Zhaohui)Zhang <zzhang=40juniper.net@dmarc.ietf.org>
To: 'bier@ietf.org' <bier@ietf.org>;
Date: 2022年08月02日 05:08
Subject: [Bier] A new comment about https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bier-idr-extensions__;!!NEt6yMaO-gk!G1pQRVj-WJSN9_KmeVqpMHxp94H2FqWg2JUguN-cIqGqgA2ilipHawl9tlNwPNR9elbX_KUoF7StBwkX6ezV6f0$
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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-bier-multicast-as-a-service-01.html*section-2.1__;Iw!!NEt6yMaO-gk!G1pQRVj-WJSN9_KmeVqpMHxp94H2FqWg2JUguN-cIqGqgA2ilipHawl9tlNwPNR9elbX_KUoF7StBwkXLVjxTCM$  .
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
_______________________________________________
BIER mailing list
BIER@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!G1pQRVj-WJSN9_KmeVqpMHxp94H2FqWg2JUguN-cIqGqgA2ilipHawl9tlNwPNR9elbX_KUoF7StBwkXHpgtvAk$