Subject: [Bier] Comments on <draft-zzhang-bier-tether-02>

From: Xiejingrong <[email-masked]>
Date: Mon, 22 Jul 2019 22:20:45 +0000

Hi,
I have some comments on this draft below:

     This can easily be prevented if BFR1 does an SPF calculation with the
     helper BFRx as the root.  For any BFERn reached via X from BFR1, if
     BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the
     helper.  Instead, BFR1 must directly tunnel packets for BFERn to X's
     BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of
     [RFC8279].

     In the following example, there is a connection between BFR1 and
     BFRx.  If the link metrics are all 1 on the three sides of
     BFR1-X-BFRx triangle, loop won't happen
[XJR]
This is an example of static condition. There may be some dynamic conditions too.
For example, the link BFRx-x goes down, and the original tunnel from BFR1 to BFRx will cause loop.
the tunnel will destroy and packet may lose (which wouldn't in this topology if not using the method).

           but if the BFRx-X metric is 3
     while other two sides of the triangle has metric 1 then BFRx will
     send BIER packets tunneled to it from BFR1 back to BFR1, causing a loop.
[XJR]
As above, when BFRx-X metric changes from 1 to 3, there may be packet loss too.
I mean the additional caculation is required not only at the first time, but at time when configuration/link-state changes.
If the BFR1 is a Non-BIER router1, then BFER1 has to tunnel to BFRx, and this procedure can not  share the LFA caculation.
Is the load of additional caculation a concern ?

Thanks
Jingrong

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 23 Jul 2019 19:05:18 +0000

Please see zzh> below.

Juniper Business Use Only
From: BIER <[email-masked]> On Behalf Of Xiejingrong
Sent: Monday, July 22, 2019 6:21 PM
To: BIER WG <[email-masked]>
Subject: [Bier] Comments on <draft-zzhang-bier-tether-02>

Hi,

     [RFC8279].

Zzh> That's expected. Same with LFA situation.

Zzh> I assume you meant that in the following:

                             ------ BFR2 ------- BFER2
                            /
     BFER1---non-BFR1 ---- X ------- BFR3 ------- BFER3
                   \      / \  .........
                    \    /   \
                     BFRx    ------ BFRn ------- BFERn

Zzh> Because BFRx is not directly connected to BFER1, there is no need to do an LFA calculation for BFRx, so doing a BIER-loop-detection calculation with BFRx is extra burden.
Zzh> If that extra calculation is your concern, then you would be concerned with LFA as well - a router needs to do LFA-loop-detection calculation for all its protection neighbors and there could be many of them (in this picture as long as there is a BFER1-BFRx connection it needs a LFA-loop-detection calculation for BFRx).
Zzh> Jeffrey

Thanks
Jingrong

---

From: Xiejingrong <[email-masked]>
Date: Wed, 24 Jul 2019 13:30:18 +0000

Thanks for the clarification.
Works for me.

Jingrong

________________________________
From: Jeffrey (Zhaohui) Zhang [[email-masked]]
Sent: Wednesday, July 24, 2019 3:05
To: Xiejingrong; BIER WG
Subject: RE: Comments on <draft-zzhang-bier-tether-02>

Please see zzh> below.

Hi,

     [RFC8279].

Zzh> That’s expected. Same with LFA situation.

Zzh> Because BFRx is not directly connected to BFER1, there is no need to do an LFA calculation for BFRx, so doing a BIER-loop-detection calculation with BFRx is extra burden.
Zzh> If that extra calculation is your concern, then you would be concerned with LFA as well – a router needs to do LFA-loop-detection calculation for all its protection neighbors and there could be many of them (in this picture as long as there is a BFER1-BFRx connection it needs a LFA-loop-detection calculation for BFRx).
Zzh> Jeffrey

Thanks
Jingrong