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

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

Please see zzh> below.



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

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.

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

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 ?

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