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

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

Hi Huaimo,

RFC 8279 has the following:

   In the event that unicast traffic to the BFR-NBR is being sent via a
   "bypass tunnel" of some sort, the BIER-encapsulated multicast traffic
   sent to the BFR-NBR SHOULD also be sent via that tunnel.  This allows
   any existing "fast reroute" schemes to be applied to multicast
   traffic as well as to unicast traffic.

While it does not explicitly call out "IP FRR", it does say "any existing "fast reroute" schemes", and the reason any scheme works is that BIER forwarding is really tied to how you reach individual BFERs.

As I mentioned, how it is done is really implementation details - whether it is "tunnel" based or just tunnel-less IPFRR based. The actual structure of forwarding state could be ECMP or Unequal Cost MP based (a BIFT entry has an ECMP/UECMP nexthop with several branches and if one goes down you just use the rest) and it'll work for all situations.

You may argue that the extra take is better - we don't have to continue on that as there is no need to standardize the internal implementation.

Jeffrey

From: Huaimo Chen <[e-mail]>
Sent: Sunday, November 15, 2020 11:27 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Comments on draft-chen-bier-frr

[External Email. Be cautious of content]

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]<mailto:[e-mail]>>
Sent: Friday, November 13, 2020 8:14 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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<https://urldefense.com/v3/__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__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!QpU7u0kPXMh6CP2sg1vg5yI0NZoYaZ0JV9R3tfQOwB26L16CfDWdUg2ysbsWSiQO$>.

[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


Juniper Business Use Only


Juniper Business Use Only