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

[Huaimo Chen <[e-mail]>]

Hi Jeffrey,

    Thank you very much for comments.
    Regarding to the text below from RFC 8279 you refer to

   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.

    This architectural description is good. Our draft about BIER FRR is well fit in
the architecture defined in RFC 8279.

Best Regards,
Huaimo
________________________________
From: Jeffrey (Zhaohui) Zhang <[e-mail]>
Sent: Monday, November 16, 2020 8:17 AM
To: Huaimo Chen <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: Comments on draft-chen-bier-frr


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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-merling-bier-frr-00%26data%3D04*7C01*7Chuaimo.chen*40futurewei.com*7C9c89b7e002a547e1771808d887d60bba*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637408700702679994*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C2000%26sdata%3DPqgthD2ABe0G6oZ9CQIPOBJQ*2F6bOsaZlIRsBkurW6Rw*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!QpU7u0kPXMh6CP2sg1vg5yI0NZoYaZ0JV9R3tfQOwB26L16CfDWdUg2ysbsWSiQO%24&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cd837f32b71c24ffbaa1e08d88a31f051%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637411294393937363%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dvlBFM5dGoNjOh50Swt5Hp%2FVgITUlURgwtS%2F2c0BKW4%3D&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



Juniper Business Use Only


Juniper Business Use Only