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

[Huaimo Chen <[e-mail]>]

Hi Jeffrey,

    Thank you very much for your comments.
    My responses are inline below with prefix [HC].

Best Regards,
Huaimo

________________________________
From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Friday, November 13, 2020 8:14 AM
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Comments on draft-chen-bier-frr

Hi,

If I understand it correctly, this draft describes *one internal* implementation of BIER FRR based on unicast FRR, a concept that is already captured in BIER architecture. Therefore, at best it can be an *informational* document.

[HC]: The draft describes a fast reroute protection for transit
nodes in BIER, which uses IP FRR such as LFA defined RFC 5286.
In BIER architecture RFC 8279, it seems that there is no text
talking about using IP FRR to provide protection for transit
nodes. There is no reference to IP FRR such as RFC 5286.
Regarding to changing draft's intended status to "informational",
I am open for this. The reasons for its current status to be
"Standards Track" are that the RFCs about IP FRR such as RFC 5286
are "Standards Track" and other documents using IP FRR are
"Standards Track".


The described internal implementation is actually not the best way (I understand that is subject to argument). Unicast FRR does not use a separate FIB for FRR - the same FIB is used for both regular forwarding and FRR. Similarly, the same BIFT can be used BIER regular forwarding and FRR

[HC]: The FIB for normal IP addresses/prefixes is much bigger than
the BIFT for BFERs. Using a separate FIB may consume or waste tons
of memory. Considering the small size of a BIFT (at most, the size
is the number of BFR nodes in a network), using
a separate BIFT for FRR seems better. Its advantages include that
it is simpler and the forwarding procedure for BIFT can be used
for FRR-BIFT without any change.
When a BIFT is used for both normal BIER forwarding and BIER FRR,
one row (forwarding entry) in this combined BIFT may have multiple
backup sub-rows (sub-forwarding entries). At most, the number of
the backup sub-rows in a row (forwarding entry) is the number of
BFR neighbors connected to the BFR that builds the BIFT.
Each backup sub-row corresponds to one of the BFR neighbors and
is used to forward the traffic with next hop BFR-NBR being the
corresponding neighbor while the neighbor fails.
There may be multiple rows in the BIFT containing the backup
sub-rows corresponding to one BFR neighbor. When this neighbor
fails, for each of these multiple rows (forwarding entries),
the backup sub-row (sub-forwarding entry) corresponding to
the failed neighbor is used to forward the traffic.


- an entry in the FIB has forwarding information for regular forwarding and FRR - as explained in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-merling-bier-frr-00&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C9c89b7e002a547e1771808d887d60bba%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637408700702679994%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=PqgthD2ABe0G6oZ9CQIPOBJQ%2F6bOsaZlIRsBkurW6Rw%3D&amp;reserved=0.

[HC]: The draft pointed by the link above seems use a different way.
For a BFR's next hop (NH), it assumes that there is a tunnel to
each of the next hop's next hop (NNH) from the current BFR.
When a NH fails, the BFR seems to forward traffic through a
tunnel to the NNH.
There is one backup sub-row in each of the rows (forwarding entries)
in the BIFT for both normal BIER forwarding and FRR.


Jeffrey

Juniper Business Use Only