Re: [Bier] comments on draft-zzhang-bier-tether-03

[Zhang Z <[e-mail]>]

Hi Jeffrey,

The modification looks good to me.

Thanks,
Sandy

________________________________
·¢¼þÈË: BIER <[e-mail]> ´ú±í Jeffrey (Zhaohui) Zhang <zzhang=[e-mail]>
·¢ËÍʱ¼ä: 2019Äê10ÔÂ1ÈÕ 5:21
ÊÕ¼þÈË: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
³­ËÍ: [e-mail] <[e-mail]>
Ö÷Ìâ: Re: [Bier] comments on draft-zzhang-bier-tether-03


Hi Sandy,



Thanks for your comments ¨C good catches!



Please see if the following addresses them:



3.1.  IGP Signaling



   Suppose that the BIER domain uses BIER signaling extensions to ISIS

   [RFC8401] or OSPF [RFC8444].  The helper node (BFRx) MUST advertise

   one or more BIER Helped Node sub-sub-TLVs (one for each helped node).

   The value is BIER prefix of the helped node (X) followed by a one-

   octet priority field, and one-octet reserved field.  The length is 6

   for IPv4 and 18 for IPv6 respectively.



   The post-SPF processing procedures in Section 6.9 of the BIER

   architecture specification [RFC8279] are modified as following for

   BIER tethering purpose.



   At step 2, the removed node is added to an ordered list maintained

   with each child that replaces the node.  If the removed node already

   has a non-empty list maintained with itself, add the removed node to

   the tail of the list and copy the list to each child.



   At the end, the calculating node BFR-B would use a unicast tunnel to

   reach next hop BFRs for some BFERs.  The next hop BFR has an ordered

   list created at step 2 above, recording each BIER incapable node

   replaced by their children along the way.  For a particular BFER to

   be reached via a tunnel to the next hop BFR, additional procedures

   are performed as following.



   o  Starting with the first node in the ordered list of incapable

      nodes, say N1, check if there is one or more helper nodes for N1.

      If not, go the next node in the list.



   o  Order all the helper nodes of N1 based descending (priority, BIER

      prefix).  Starting with the first one, say H1, check if BFR-B

      could use H1 as LFA next hop to reach the BFER.  If yes, H1 is

      used as the next hop BFR for the BFER and the procedure stops.  If

      not, go to the next helper in order.



   o  If none of the helper nodes of N1 can be used, go to the next node

      in the list of incapable nodes.



   If the above procedure finishes without finding any helper, then the

   original BFR next hop via a tunnel is used to reach the BFER.





Jeffrey



From: [e-mail] <[e-mail]>
Sent: Sunday, September 29, 2019 11:44 PM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: [Bier] comments on draft-zzhang-bier-tether-03



Hi Jeffrey, co-authors,



I have read the newest version of draft "draft-zzhang-bier-tether". I think it's well written and helpful for BIER deployment.

And I have some comments:

1. In section 3 about the IGP/BGP signaling, because a Helper can help more than one non-BFR node, there will be more than one Helped Node sub-sub-TLV shown in the signaling. But one helped prefix MUST be shown only once.

So one sentence about it may be added in the section to make it more clear.



2. About the IGP SPF calculation procedure, IMO it's better to explain the algorithm modification of [RFC8279] section 6.9. Like:

This sentence may be added in Step 2:

But the node's prefix SHOULD be noted for Helping check.

A Step 4 may be added:

When BFR-B finds that one node signals as the helper of one or more helped nodes, BFR-B MUST check if the helped node is bypassed. If the helped node is bypassed, BFR-B SHOULD replace the existed tunnel from BFR-B that bypass the helped node with the helper node as the child node. If more than one helper existed for a helped node, the one which has the highest priority is selected.



Thanks,

Sandy