Re: [Bier] Questions/comments on https://www.ietf.org/archive/id/draft-chen-bier-anycast-label-00.txt

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

Hi Siyu,


Juniper Business Use Only
-----Original Message-----
From: Chensiyu (Susie) <chensiyu27=[e-mail]>
Sent: Monday, March 18, 2024 11:56 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; '[e-mail]' <[e-mail]>
Cc: duanfanghong <[e-mail]>; Songbo (songbo, MULTICAST) <[e-mail]>; Xuesong Geng <[e-mail]>
Subject: RE: Questions/comments on https://www.ietf.org/archive/id/draft-chen-bier-anycast-label-00.txt

[External Email. Be cautious of content]


Hi Jeffrey,
Thanks a lot for your review about our drafts. Let me reply you question one by one.
Q1: What do you mean by the following?-- 'hard convergence'
A: It is same as IGP re-convergence.

Q2: Pre-calculated FRR paths can certainly be used, just like in unicast case.
A: We'd like to construct a lightweight failure protection method that is suitable for certain topology. I'll introduce in the BIER WG meeting and will update this topology in a new version draft.

Zzh> You need to handle the normal topologies any way, and regular routing convergence plus FRR mechanism should work well for all scenarios. It's not clear to me if this new method is necessary; plus it is still not clear to me how it works.

Q3: It seems that they have different prefixes; so calling them Anycast BIER Prefix is misleading and confusing.
A: 'Anycast BIER Prefix' can represent two BIER prefixes from two BFERs, and they carries the same Anycast MPLS Label. BIER prefixes value themselves are different.

Q4: Are Anycast labels like "global" labels?
A: Yes, we need assign global label block so that different sites' label can be configured or automatically generated without conflicts.

Q5: The BIFTs drawn here are different from what's in RFC8279. Can you include the BFR-IDs (as keys) in each row?
In the above figure, is the third row for BFR-ID 3? Why does it not have the F-BM?
A: I updated the topology in the latest version of draft and slides on the website:
https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/119/materials/slides-119-bier-5-bier-anycast-label__;!!NEt6yMaO-gk!HijjBO4wqQSq00chJKesaY0_NBO1XVeXBvuBV4Q3mvlgsEtWbnZGk1GHfM9pezHTHrWPAak85WkBf529Yp-vB41DYyoDQxmb$

zzh> The BIFT in the slides is still different from the one in RFC8279. Each entry in the BIFT should be for a BFER-ID, but I don't see that in the slides.

Q6: Is the above regular BIER forwarding?
A: Forwarding behavior still follows RFC8279. But the procedure of generating BIFT are modified so that two available downstream paths can be maintained in advance.

Zzh> Existing FRR can be done by multiple ECMP/primary/backup paths as well.
Zzh> If you could fix the BIFT representation as mentioned above, it'll help me understand the solution. At this time I am just lost.
Zzh> Thanks.
Zzh> Jeffrey

Q7: Is it that the you're using the same global "anycast" label to tie C and D together? If so, why not just use the same BFR-id and BFR-prefix for them?
A: Yes. Global Anycast label can be understood as global site label. We would like to maintain BFRID and BFR-Prefix to be unique because CE will only send Join towards one of BFER. So BFIR need to declare the BFER with unique BFR-ID. BFER need to advertise its BIER Info by unique Prefixes.

Q8: Does D maintain two or three BIFTs for the same <sub-domain, BSL, set>?
A: No. Only one BIFT table will be maintained for the same <SD, BSL, SI>. But Both Anycast and Bypass carried by BIER Packet will be able to locate the same BIFT.
The relationship between <SD, BSL, SI> , Anycast Label, Bypass Label will be recorded and utilized.

I also apply for the remote BIER WG presentation this time and I will illustrate our draft in this afternoon.
See you there :).

Best wishes,
Siyu

-----Original Message-----
From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=[e-mail]]
Sent: Friday, March 8, 2024 4:11 AM
To: Chensiyu (Susie) <[e-mail]>
Cc: duanfanghong <[e-mail]>; '[e-mail]' <[e-mail]>
Subject: Questions/comments on https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-chen-bier-anycast-label-00.txt__;!!NEt6yMaO-gk!HijjBO4wqQSq00chJKesaY0_NBO1XVeXBvuBV4Q3mvlgsEtWbnZGk1GHfM9pezHTHrWPAak85WkBf529Yp-vB41DYzvrhpk_$

Hi Siyu,

I have some questions and comments on this draft.

   When failures occur at transit or egress BIER node, there is no fast
   recovery or protecting mechanism currently.  The recovery duration
   depends on how fast the unicast algorithm can re-calculate the new
   path.  The new available path can only be generated in this way
   called 'hard convergence'.  In this document, a fast failover method
   is designed for BIER to generate an alternative path for flow in
   advance by allocating and transmitting additional BIER MPLS label.

What do you mean by the following?

  ... The recovery duration
   depends on how fast the unicast algorithm can re-calculate the new
   path.  The new available path can only be generated in this way
   called 'hard convergence'.

Pre-calculated FRR paths can certainly be used, just like in unicast case.


   As shown in the following figure, one customer device is multihomed
   to two BFERs in order to perform egress protection.  Two BFERs are
   deployed in the same egress site.  Different BFR-ids and BFR-prefixes
   are configured.  However, they are assigned with same Anycast MPLS
   label and different Bypass MPLS labels.  The same Anycast label can
   be used to specify the egress site.  The Bypass MPLS label works as
   the traditional MPLS label to ensure the normal behavior of BIER
   forwarding function within the site.  They are advertised by BIER-
   Info Sub-Tlv in BIER prefix.  BIER prefix carrying Anycast MPLS label
   is called Anycast BIER Prefix.  After receiving BIER prefix, BIER

It seems that they have different prefixes; so calling them Anycast BIER Prefix is misleading and confusing.

   MPLS Label will be contained in BIER Forwarding Table to instruct
   forwarding data packet.

Are Anycast labels like "global" labels?

   After receiving BIER Info Sub-TLV, BFR will parse Bypass MPLS Label
   and Anycast MPLS Label.  The relationship of [BFR-id, Anycast Label,
   Bypass Label] will be maintained by each BFR.  As shown in the figure
   below, BFR will receive BIER Info Sub-TLVs from BFER-C and BFER-D.
   The Anycast Label of two BFERs are different with BFR's, but they are
   same with each other.  BFR will combine BFR-id of BFER-C and BFER-D
   as the one entry in the Bit Index Forwarding Table.  Both BFER-C and
   BFER-D may receive packet.

     Site1      Site2           Site3
                         ------ BFER-C(2)
                      |                 |
   BFR-A(1)--  BFR-B ---- BFER-D(3) -------- CE


                   Figure 3: BIER Egress Site Deployment


              BFR-B BIFT
             --------------------------------------
              | F-BM | BFR-NBR | NBR-Label        |
             =====================================
              | 001  |    A    |  AnycastLabel-1       |
             -------------------------------------
              | 110  |    C    |  AnycastLabel-3       |
             -------------------------------------
                         |    D    |  AnycastLabel-3       |
             -------------------------------------

                            Figure 4: BFR-B BIFT

The BIFTs drawn here are different from what's in RFC8279. Can you include the BFR-IDs (as keys) in each row?
In the above figure, is the third row for BFR-ID 3? Why does it not have the F-BM?

   When BFR receives BIER data packet, it will locate the BIFT according
   to the BIFT-id encapsulted in BIER header.  If the packet needs to be
   forwarded to BFR-id 3, it will modify the BIFT-id field as
   AnycastLabel-2 and then forward it.  When BFER-D receives this
   packet, the packet will be finnaly sent to CE.

Is the above regular BIER forwarding?

   BFERs will also advertise their BIER Info Sub-Tlv to each other.
   When BFER-C receives BFER-D's Sub-sub-TLV, it finds BFER-D has same
   anycast label and different bypass label, it will encode bypass label
   into its BIFT as shown below.

Is it that the you're using the same global "anycast" label to tie C and D together? If so, why not just use the same BFR-id and BFR-prefix for them?

              BFR-C BIFT
             --------------------------------------
              | F-BM | BFR-NBR | NBR-Label        |
             =====================================
              | 001  |    B    |  Label-3         |
             -------------------------------------
              | 100  |    D    |  BypassLabel-13  |
             -------------------------------------

                            Figure 5: BFR-C BIFT

Which two BFR-IDs are the two entries in the above table for?

3.4.  Fast Recovery

   When link between BFR-B and BFER-D goes down due to certain reason,
   BFR-B will detect it and forward packet to BFER-C immediately
   according to BIFT entry.  AnycastLabel-2 will be encapsulated.  When
   BFER-C receives this packet, it will firstly use anycast label to
   locate corresponding BIFT table.  Then it will use BFR-id 3 to look

Does C maintain two BIFTs for the same <sub-domain, BSL, set>?
Or even three (with the 3rd one identified by its bypass label)?

   for F-BM and find its neighbor is BFER-D.  The bypass label of BFER-D
   will be encapsulated into data packet header.  Then BFER-D will
   finally receive the packet.  No packet will be dropped because the
   backup out interface has been generated when the anycast and bypass
   MPLS Labels have been advertised and utilized.

Does D maintain two or three BIFTs for the same <sub-domain, BSL, set>?

What is the advantage of this solution compared to https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-zzhang-bier-anycast/?__;!!NEt6yMaO-gk!HijjBO4wqQSq00chJKesaY0_NBO1XVeXBvuBV4Q3mvlgsEtWbnZGk1GHfM9pezHTHrWPAak85WkBf529Yp-vB41DY5wwz7kj$

Thanks.
Jeffrey


Juniper Business Use Only