Re: [Bier] Comments on draft-chen-bier-frr-02.

[iirme01 <[e-mail]>]

Hi all,


I'm one of the authors of [I-D.merling-bier-frr].


Hi Huaimo,


you find my response to the "lost packet"-issue inline with the prefix [DM].


Best regards,

Daniel


Am 17.03.2021 um 16:31 schrieb Huaimo Chen:
> Hi Jeffrey,
>
>     Thanks for your comments.
>     My responses are inline below with prefix [HC].
>
> Best Regards,
> Huaimo
> ------------------------------------------------------------------------
> *From:* Jeffrey (Zhaohui) Zhang <[e-mail]>
> *Sent:* Tuesday, March 16, 2021 5:41 PM
> *To:* Huaimo Chen <[e-mail]>; [e-mail] 
> <[e-mail]>
> *Subject:* Comments on draft-chen-bier-frr-02.
> Hi Huaimo,
>
> Please see my comments below.
>
> Some are nits, but if I understand it correctly, the idea of using
> multiple per-nbr FRR BIFTs is flawed.
> [HC]: My statement below is right.
>
>    [I-D.merling-bier-frr] proposes a tunnel-based fast re-route (FRR)
>    ... Before the
>    primary bit mask is recomputed and updated, some of BIER packets may
>    be forwarded incorrectly.
>
> Would like to see elaborations on why some of the packets may be
> forwarded incorrectly - especially if you consider the approach
> at the end of this mail.
>
> [HC]: There are two forwarding entries for each BFER in the BIFT for FRR.
> One is primary forwarding entry with primary bit mask and primary next 
> hop.
> The other is the backup forwarding entry with backup bit mask and 
> backup next hop.
> The backup next hop is the next hop of the neighbor.
> All the primary forwarding entries in the BIFT have thier primary bit 
> masks and
> primary next hops that are computed before the failure of a neighbor.
> When the failure of a neighbor happens, the BIER packets that
> go to the neighbor as its next hop are forwarded to the next hop
> of the neighbor using the backup forwarding entry.
> All the other BIER packets that go to the other neighbors
> as their next hops are forwarded to these next hops (i.e., primary 
> next hops)
> using the primary forwarding entries.
> These primary forwarding entries with thier primary bit mask and 
> primary next hop
> are computed before the failure. After the failure, all the primary 
> forwarding entries
> will be recomputed and may be different from those before the failure.
> From the time at which the neighbor fails to the time at which
> all the primary forwarding entries are recomputed and updated
> based on the updated network topology after failure,
> Some of the BIER packets that are forwarded using the old primary
> forwarding entries may be lost.
[DM]: Why would any packets be lost? Until the forwarding entries, i.e., 
both the primary and backup ones, are updated, the backup forwarding 
entries are used for forwarding for all BFERs that are usually reached 
via the now unreachable next-hop. That is, the packets are forwarded to 
other next-hops. All other BFERs are reached via reachable next-hops 
through primary forwarding entries.
>
>
>    This document describes a mechanism for fast re-route (FRR)
>    protection against the failure of a node or link in the core of a
>    BIER domain, which resolves the above issue.  It is based on LFA,
>    which is called LFA-based BIER-FRR.
>
> Unicast FRR can be based on many mechanisms, and BIER FRR can simply
> follow suit. It does not have to be limited to LFA or tunnel - simple
> ECMP can also work if there are ECMP paths (if an ECMP branch is no
> longer available you can simply take another one).
>
> [HC]:  The draft about LFA-based BIER FRR does not mean other approaches
> for BIER FRR cannot be used.
>
>    In normal operations, the normal BIFT is used to forward BIER
>    packets.  When a neighbor fails, the BFR as PLR uses the FRR BIFT for
>    the neighbor to forward BIER packets.  For a BIER packet to traverse
>    the BFR and the failed neighbor, the BFR reroutes the packet around
>    the failed neighbor using the FRR BIFT for the neighbor.  For a BIER
>    packet to traverse the BFR and any other neighbors, the BFR forwards
>    the packet to its expected next hop neighbors using the forwarding
>    entries with these BFR neighbors in the FRR BIFT.
>
> I do not see why there is a need for per-neighbor FRR BIFT. It is also not
> clear how the switch between normal BIFT and FRR BIFT is done - in fact
> I think it is flawed - more on that later.
>
> [HC]: In one implementation, we can have a BIFT pointer, which points
> to the forwarding table that is used. In normal operations, the pointer
> points the normal BIFT. When a neighbor fails, we can set the pointer to
> the FRR BIFT for the neighbor. After the network convergence,
> the normal BIFT is recomputed and updated based on the updated network
> topology after the failure, we can set the pointer to the normal BIFT.
>
>    From the BIRT on the BFR, a "Bit Index Forwarding Table" (BIFT) is
>    derived.  In addition to having a route to a BFER in each row of the
>    BIFT which is the same as the BIRT, it has a "Forwarding Bit Mask"
>    (F-BM) in its each row.  For the rows in the BIRT that have the same
>    SI and the same BFR-NBR, the F-BM for each of these rows in the BIFT
>    is the logical OR of the BitStrings of these rows.
>
> Need to be a bit more strict here. A row in BIFT is about a
> particular BFER, which could be reached via two ECMP nbrs.
> The F-BM is really for a nbr, not for a row. See Figure 6 in RFC8279.
>
> [HC]: We will update accordingly.
>
>    When a BFR receives a packet, for each BFER k (from the rightmost to
>    the leftmost) represented in the SI and BitString of the packet, if
>    BFER k is the BFR itself, the BFR copies the packet, sends the copy
>    to the multicast flow overlay and clears bit k in the original
>    packet; otherwise the BFR finds the row (i.e., forwarding entry) in
>    the BIFT for the sub-domain using the SI and BitString as the key or
>    say index, and then copies, updates and forwards the packet to the
>    BFR-NBR (i.e., the next hop) indicated by the row (i.e., forwarding
>    entry).
>
> Strictly speaking, the BIFT is for <sub-domain, SI> (if we ignore
> different bitstringLen), and the lookup key is 'k' not the entire 
> bitstring.
>
> [HC]: We may add some text to explain.
>
>    The FRR-BIRT for BFR-NBR X of the BFR considers the failure of X and
>    maps the BFR-id (in the sub-domain) of a BFER to the BFR-prefix of
>
> A nit here - strictly speaking it's not that you map the bfr-id to bier
> prefix in BIRT. BIRT is built based on how a BIER prefix is reached,
> and the mapping is the other way around - you map the prefix to a BFR-id
> when you derive the BIFTs from BIRT.
>
> [HC]: It seems that this is based on some RFCs. I will double check.
>
>    The BFR may build the FRR-BIRT for BFR-NBR X by copying its BIRT to
>    the FRR-BIRT first, and then change the next hop with value BFR-NBR X
>    in the FRR-BIRT to a backup next hop (BNH) to protect against the
>    failure of X.  In other wards, for the BFR-id of a BFER in the FRR-
>    BIRT for BFR-NBR X, if the next hop BFR-NBR on the path to the BFER
>    is X, it is changed to a BNH when there is a BNH on a backup path to
>    the BFER without going through X and the link from the BFR to X.
>
>    If there is not any BNH to a BFER to protect against the failure of
>    X, the next hop BFR-NBR X to the BFER in the FRR-BIRT for BFR-NBR X
>    is changed to NULL.  For a multicast packet having the BFER as one of
>    its destinations, if the next hop BFR-NBR to the BFER is NULL, the
>    BFR does not send the packet to the next hop BFR-NBR NULL but drops
>    it when X fails.
>
> A nit - it's not that the packdet is dropped. Rather, the bit for that
> BFER is simply cleared.
>
> [HC]: We will update accordingly.
>
> So for BFERs not affected by X's failure, they're still present in
> X's FRR BIFT and are the same as in the normal BIFT. Keeping these
> per-nbr FRR BIFTs with those unaffected entries
> just does not make sense - you might as well have one BIFT in which
> each row includes ECMP/backup branches. Of course, this is implementation
> details/preferences, but:
>
> - it's not good to specify this controversial implementation details
> - switching to using FRR BIFT is actually flawed - see later comments.
>
> [HC]: Switching between normal and FRR BIFT is described above.
>
>    The forwarding procedure defined in [RFC8279] is updated/enhanced for
>    a FRR-BIFT to consider the case where the next hop BFR-NBR to a BFER
>    is NULL.  For a multicast packet with the BitString indicating a BFER
>    as one of its destinations, the updated forwarding procedure checks
>    whether the next hop BFR-NBR to the BFER in the FRR-BIFT is NULL.  If
>    it is NULL, the procedure will not send the packet to this next hop
>    BFR-NBR NULL but drop the packet.
>
> A nit - not "drop the packet" but simply clear the bit.
> Additionally, even when you do not support FRR you also have situations
> whwere some BFERs are simply not reachable. In other words, clearing
> the bit for those BFERs is the base requirement/assumption in RFC8279,
> not a update/enhancement.
>
> [HC]: We will update accordingly.
>
>    The FRR-BIFTs will be pre-computed and installed ready for activation
>    when a failure is detected.  Once the BFR detects the failure of its
>    BFR-NBR X, it activates the FRR-BIFT for X to forward packets with
>    BIER headers and de-activates its BIFT.  After activation of the FRR-
>    BIFT, it remains in effect until it is no longer required.
>
> Let's say this BFR has several BFR neighbors (including X and W).
> X fails first and W fails instantly after that.
> Which FRR BIFT do you use? X's FRR BIFT does not consider W's failure
> and W's FRR BIFT does not consider X's failure, so using either one alone
> has problems. Notice that this is different from the typical
> "multiple failure" scenario - it's not that X and W may depend on each
> other but it could be that some BFERs have a common backup neighbor Y, yet
> if you use X's FRR BIFT then those BFERs normally reachable via W
> are not protected now that W also fails. Similarly, if you use W's
> FRR BIFT then those BFERs normally reachable via X are not protected
> now that X also fails.
>
> [HC]: We focus on single failure at one time. Multiple failures at the 
> same
> should be out of scope now. We may consider it in future.
>
>
> That's why a single BIFT should be used for both normal and FRR 
> forwarding,
> just like in unicast case.
>
>    The number of entries in a FRR BIFT is the number of BFERs.  Each FRR
>    BIFT on a BFR can be compressed through combining all the entries
>    with the same BFR-BNR and F-BM into one entry.  The number of entries
>    in a compressed FRR BIFT is the number of neighbors of the BFR minus
>    one.
>
>    For example, the compressed FRR-BIFT for BFR C on BFR B is shown in
>    Figure 7.  The number of entries in it is three, which equals the
>    number (four) of neighbors of BFR B minus one.
>
> +----------------+---------+------------+
>                  |     BFR-id     |  F-BM   |  BFR-NBR |
>                  | (SI:BitString) |         | (Next Hop) |
> +================+=========+============+
>                  | 1, 4 (0:01001) |  01001  |     G |
> +----------------+---------+------------+
>                  | 2, 3 (0:00110) |  00110  |     E |
> +----------------+---------+------------+
>                  |  5 (0:10000)   |  10000  |     A |
> +----------------+---------+------------+
>
>              Figure 7: Compressed FRR BIFT for BFR C on BFR B
>
>    For a BIER packet with a BFR-ID as a destination, the entry
>    containing the BFR-ID is used to forward the packet.
>
> Not sure of the benefit of compression here. It makes the lookup more
> complicated. If the memory consumption is a concern, just get rid of
> per-nbr FRR-BIT and use a single one. Additionally, the F-BM and BFR-NBR
> information can be considered forwarding information that can be pointed
> at by multiple BIFT entries, so the above compression does not really
> give you much savings.
>
> [HC]: Compression is optional.
>
>    Once BFR B detects the failure of its BFR-NBR X, after receiving the
>    packet from BFR A, BFR B copies, updates and sends the packet using
>    the FRR-BIFT for X on BFR B to avoid X and link from B to X according
>    to the forwarding procedure defined in [RFC8279].
>
>    For example, once BFR B detects the failure of its BFR-NBR C, after
>    receiving the packet from BFR A, BFR B copies, updates and sends the
>    packet to BFR G and BFR E using the FRR-BIFT for BFR C on BFR B to
>    avoid C and link from B to C.
>
> See earlier comments about failure of multiple neighbors (who do not
> use each other for backup). Using a per-nbr FRR BIFT not only is
> unnecessary, but also has problems.
>
> [HC]: Multiple failures handling is out of scope for now.
>
> A better way is to simply have a single BIFT for both normal and FRR
> forwarding. Each entry has some ECMP and/or primary/backup branches,
> and you simply use another ECMP branch or a backup branch when the
> normally used branch fails. A backup branch can go through completely
> different nbr, or go through the same neighbor but via a tunnel.
>
> Jeffrey
>
> Juniper Business Use Only
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier