Re: [Bier] Comments on draft-zhang-bier-flooding

[<[e-mail]>]

Hi Jeffrey,







Yes, I think they will. They deploy PIM in the network and it works before. 






Thanks,


Sandy











原始邮件




发件人： <[e-mail]>;
收件人：张征00007940;
抄送人： <[e-mail]>; <[e-mail]>;
日 期 ：2017年11月10日 12:01
主 题 ：RE: [Bier] Comments on draft-zhang-bier-flooding








Hi Sandy,


 


If an operator is happy with configuring static routes for remote BFERs, would it be acceptable to configure the BFR-IDs  for those remote BFERs along with the static routes?


 


Jeffrey


 

 


From: [e-mail]  [mailto:[e-mail]] 
 Sent: Thursday, November 9, 2017 8:37 PM
 To: Jeffrey (Zhaohui) Zhang <[e-mail]>
 Cc: [e-mail]; [e-mail]
 Subject: Re: [Bier] Comments on draft-zhang-bier-flooding




 


Hi Jeffrey,


 


Thanks for your comments!


The method you mentioned is like treating the border router as a BIER proxy, it works in the situation that the regions connected with border router are all running IGP/ BGP routing protocols. And I think it is a solution though  it increase the complexity of border routers. 


But it doesn't work well if static configured routes are used in at least of one region. So if you have any better idea about static configured routing region?


 


Thanks,


Sandy

 

 


原始邮件



发件人： <[e-mail]>;



收件人： <[e-mail]>;  <[e-mail]>;



日 期 ：2017年11月10日  08:44



主 题 ：[Bier] Comments on draft-zhang-bier-flooding




 



Hi Sandy,



 


During a recent offline discussion on OSPF/ISIS inter-area BIER signaling, I brought up that when an area border router re-advertise into another area, it does not need to  advertise the encapsulation sub-TLV, because routers in other areas won't use that information at all. All that is needed is the BFR-IDs.



 


The same could be applied to the use case you're describing:



 
  


                              |                |



                     .........|................|..........



                     .  ISIS  |                |        .



                     .        |                |        .



                     .       MR1--------------MR2       .



                     .        |  .          .  |        .



                     .        |    .      .    |        .



                     .        |      .  .      |        .



                     .        |       ..       |        .



                     .        |     .    .     |        .



                     .        |   .        .   |        .



                     .        | .            . |        .



                     .        MR3              MR4      .



                     .       /  \             /  \      .



                     .....................................



                            /    \           /    \



                           /      \         /      \



                          /        \       /        \



                     ...................  .................



                     .    B1--------B2 .  .B3--------B4  .



                     .                 .  .              .



                     .   Rm            .  . Rx           .



                     .       ...       .  .     ...      .



                     .            Rn   .  .         Ry   .



                     .                 .  .              .



                     .         OSPF    .  .       OSPF   .



                     ...................  .................



                       Figure 1: An typical hybrid network



 


So, I don’t see a need to use BSR to flood the BIER info across those different routing domains. As  long as the border routers advertise the BFR-IDs of its downstream nodes to neighboring border routers, and its neighboring border routers continue to advertise the BFR-IDs of those downstream nodes, it will work.



 


For example, MR3 has to learn routes to Rm…Rn somehow – as long as that learning includes the BFR-IDs of Rm…Rn, and MR3 advertises those to its neighbors in the ISIS domain and so on, things will work.



 


Jeffrey