Re: [Bier] Comments on draft-chen-bier-egress-protect

[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:52 AM
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Comments on draft-chen-bier-egress-protect

Hi,

Similar to my comments about draft-chen-bier-frr, you don't need a separate EP-BIFT. But that's not my main concern.

[HC]: Using a separate EP-BIFT may be simpler.


Consider the following situation:

     BFIR1  ----- BFR  ------ BFER1  ----- ce1
            \                           /
             ---------------------- BFER2
                                         \
                                         ce2

Both ce1 and ce2 receive traffic from BFER1 and BFER2 respectively in normal conditions, and BFIR1 sets two bits in the bitstring. Now if BFER1 fails and the BFR flips on BFER2’s bit for in-flight packets targeted at BFER1, ce2 will receive duplicates.

[HC]: My understanding is that in this case, ce1 receives traffic
from both BFER1 and BFER2 in the same multicast path/tree,
it seems that there is no need to provide protection for either of
them (BFER1 and BFER2) since ce1 (dual homed to BFER1 and BFER2)
will receive the multicast traffic from one of them when any one
of BFER1 and BFER2 fails. Thus, ce2 will not receive duplicates.


While one can argue that the targeted scenario does not have ce2, BIER egress protection design should not be based on that. There are two problems to solve at different layers.

At the overlay, BFER2 should not deliver to ce2 the traffic that is supposed to be via BFER1. This applies to both BIER and other transport means (e.g. p2mp tunnels).

To facilitate that, the transport must make sure that BFER2 knows the FRR’ed traffic was supposed to be via BFER1. In BIER case, the bit for BFER1 must not be flipped to the BFER2 bit.

The BIER tethering solution https://datatracker.ietf.org/doc/draft-ietf-bier-tether/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bier-tether%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc10ed6adadec4d2ef57808d887db659b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637408723668119037%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ITrup6Oup09WdQs%2FXx3Pe9haFnqMGUuwWy1LahHFUHs%3D&reserved=0> can be easily extended to solve the second problem. BFER2 can signal that it is the helper for BFER1 (but only for egress protection). This can be done by adding an Egress Protection sub-sub-tlv to the “BIER Helped Node” sub-tlv defined in the tethering draft.

Then, upon failure the BFR will tunnel in-flight packets to BFER2. When BFER2 gets the packet, it sees the BFER1 bit, notices BFER1 is unreachable and it is the helper node so it will send the packet to overlay for proper forwarding.

[HC]: We will consider the extension and suggestions you proposed
in more details and incorporate them into the draft accordingly.



Jeffrey


Juniper Business Use Only