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

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

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
                   ------ BFER-C ------ CE
                |         |             |
               BFR-B ---- BFER-D --------


                   Figure 3: BIER Egress Site Deployment


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

                            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://datatracker.ietf.org/doc/draft-zzhang-bier-anycast/?

Thanks.
Jeffrey


Juniper Business Use Only