Re: [Bier] Call for adoption: draft-xiong-bier-resilience-01

[<[e-mail]>]

Hi Jeffrey,






Sorry to reply late. Thanks for your great comments.  Reply about the BIER resilience use cases is as follows.






1, BIER 1+1 protection


Jeffrey>>1+1 Protection is what we referred to as live-live, but it only make sense if both copies are sent to the CE (using MVPN example) for it to do the merge, and that is really not BIER specific (it is rather an overlay function).Additionally, if there is no need for live-live, or if BFERs simply  send redundant packets  its downstream router who them  merges the flow, then it is not clear to me what value BFD provides.

Quan>>In live-live, the BFIR sends two copies to all BFERs through seperate multipoint paths. When no failure, the BFERs need to merge the two flows. But when failure occured, the BFER must monitor and detect multicast failures and choose the flow from the no failure path. And another scenario with DetNet service,  Packet Replication Function (PRF) used in the DetNet to lower the packet loss metric as an example of live-live terminated within BIER domain. PRF is used in combination with Packet  Elimination Function (PEF) and usually referred to as PREF. 


2,BIER 1:1 protection

Jeffrey>>With the inherent unicast FRR it’s not clear to me what value the 1:1 protection has.And active tail seems to be outside the scope of draft-hu-bier-bfd.
Quan>> We plan to change this use case to restoration. P2mp BFD with active tails can be used in restoration cause when failure occured the head can be notified and create a new path to restore the service. And we will update the draft-hu-bier-bfd before IETF104 and cover the active tail fuction.




3,BIER Link Protection

Jeffrey>>BIER Link Protection is inherent of unicast protection and nothing special needs to be done.
Quan>>Yes, BIER link protection is realized in the underlay network but we still list it in the draft and try to specify all possible scenarios for BIER-specific network but maybe no need to be done in BIER related methods.


I will update the draft before IETF104. If you have any suggestions, welcome to join in us.

Thanks,

Quan










原始邮件



发件人：Jeffrey(Zhaohui)Zhang <[e-mail]>
收件人：熊泉00091065;
抄送人：[e-mail] <[e-mail]>;
日 期 ：2019年02月24日 12:13
主 题 ：RE: [Bier] Call for adoption: draft-xiong-bier-resilience-01




Hi Quan,


 


If what I summarized makes sense, then an informational draft about  BIER resilience topic would be better organized as outlined by my bullet points in my view.


 


Additionally, if there is no need for live-live, or if BFERs simply  send redundant packets  its downstream router who them  merges the flow, then it is not clear to me what value BFD provides.


 


BTW – active tail seems to be outside the scope of draft-hu-bier-bfd  (ok it’s for further study).


 


Jeffrey


 




From: [e-mail] <[e-mail]> 
 Sent: Friday, February 15, 2019 3:24 AM
 To: Jeffrey (Zhaohui) Zhang <[e-mail]>
 Cc: [e-mail]
 Subject: Re: [Bier] Call for adoption: draft-xiong-bier-resilience-01




 

Hi Jeffery,

 

Sorry to reply late!  I was on vocation during last two weeks.

Thanks for taking your time to review and sharing your comments, much appreciated.

draft-xiong-bier-resilience is an informational draft and its goal is to summarize and specify BIER resilience use cases and related failure detection methods.
We try to specify all possible scenarios for BIER-specific network but maybe no need to be done in BIER related methods.
The document mainly focus on providing use cases with  the failure detection methods like P2MP BFD and active tail which is defined in draft-hu-bier-bfd.

More comments are welcome to fix the draft. Thank you!

Best Regard,
Quan  

 


"Jeffrey (Zhaohui) Zhang" <[e-mail]> Fri,  25 January 2019 18:36 UTCShow  header

Hmm … I had some email exchanges on this topic with a few folks before but looks like I forgot to compile and send out my comments soon after the Bangkok meeting.   Anyway, I think we need more discussion on the content before adoption.   Quite a long time ago we discussed with some customers and the following are a summary:       *   BIER makes use of unicast FRR so traffic interruption is minimum      *   Same as unicast      *   Therefore MoFRR or live-live is not really needed   *   Live-live might be done for mission critical applications      *   Just send two streams in different subdomains (with disjoint underlays)      *   Application must be responsible for merging the two streams and discard duplicates         *   It’s not feasible or it does not provide live-live protection value for a BFER to pick which stream to deliver            *   Switch over can’t be link status based            *   Traffic based switch over only possible for CBR, and even so due to FRR traffic loss may not be enough to trigger detection       For the three use cases in draft-xiong-bier-resilience:     3.1.  End-to-End 1+1 Protection   3.2.  End-to-End 1:1 Protection   3.3.  BIER Link Protection       1+1 Protection is what we referred to as live-live, but it only make sense if both copies are sent to the CE (using MVPN example) for it to do the merge, and that is really not BIER specific (it is rather an overlay function).   BIER Link Protection is inherent of unicast protection and nothing special needs to be done.   With the inherent unicast FRR it’s not clear to me what value the 1:1 protection has.       Jeffrey   From: BIER [mailto:[e-mail]] On Behalf Of Greg Shepherd Sent: Friday, January 25, 2019 1:12 PM To: BIER WG <[e-mail]>; Subject: [Bier] Call for adoption: draft-xiong-bier-resilience-01   Please read and reply to this thread with your vote for/against adoption of:https://datatracker.ietf.org/doc/draft-xiong-bier-resilience/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dxiong-2Dbier-2Dresilience_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=STb7mqddzf1ELpQUCskrlZeKWCg8DUFLm6tGxLR5-N4&s=zxYw2qZxEAraeYYpbwQ4j3pvaDxP-VTa-Zj70NrZh4U&e=>..as a BIER WG document.   This starts a two week counter.   Thanks, Chairs (Shep)