Hi Jeffrey,
On 5/12/16, 12:12 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" <[email protected] on behalf of [email protected]> wrote: >Hi Jorge, Ali, > >> [JORGE2] In VPWS DF election is needed for single-active. The NDF will >> block the AC for the service. > >> [JORGE] This is single active, so only one can transmit/receive to/from >> the CE. So only that one should send P=1. > >If I understand it correctly, the draft should specify the following: > >- Use of DF election to determine primary/backup (curious how it is done >for plain old EVPN), including backup DF concept In EVPN, there is no explicit primary/backup, we just tell the remote PE that this ES operate in all-active or single-active. In case of single-active, when a remote PE receives a MAC from one of the PE in the redundancy group, it know that this PE is the primary PE. The back-up PE is the other PE if the ES is dual-homed. If the ES is multi-homed, there RFC7432 would need this EC as well. >- Only the current DF should set the P-bit >- Only the current BDF should set the B-bit >- P=B=1 is invalid Correct. And these can be explicitly spelled out. >- There could be transient situations where multiple P=1 and/or multiple >B=1 routes co-exist. Some heuristic should be used to pick which one to >use to avoid traffic discard at the other end. Agreed we need some additional text here to explain what is expected. > >For the P=B=0 case - the receiving router can't use it anyway until its >P/B is changed, right? If you want to use it as 2nd backup, the spec >needs to point it out. That¹s was the plan initially but we simplified it. Still there should be no issue with P=B=0. Cheers, Ali > >Thanks. > >Jeffrey > >> -----Original Message----- >> From: Rabadan, Jorge (Nokia - US) [mailto:[email protected]] >> Sent: Thursday, May 12, 2016 2:28 PM >> To: Jeffrey (Zhaohui) Zhang <[email protected]>; BESS <[email protected]> >> Subject: Re: [bess] FW: WG Last Call (including implem status & >>shepherd) >> for draft-ietf-bess-evpn-vpws-03 >> >> HI Jeffrey, >> >> >> On 5/12/16, 8:13 PM, "BESS on behalf of EXT Jeffrey (Zhaohui) Zhang" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Hi Jorge, >> > >> >> >If a PE sends a route w/o setting P-bit, wouldn't that indicate it >>is >> a >> >> backup? Why would it bother sending the route if it does not want to >>be >> >> the backup? >> >> >> >> [JORGE] Let¹s assume you have 3 PEs in ES-1 (PE1/2/3) that is a >>single- >> >> active ES. PE4 is a remote PE doing backup function. >> > >> >I assume PE4 is not "doing backup function" but is just one end of the >>PW. >> Or perhaps you mean it needs to decide which of PE1/2/3 is the >> primary/backup. >> >> [JORGE2] by ³doing backup function² I mean that PE4 sets up a >>destination >> to PE1 with a backup to PE2. Aliasing and Backup functions are >>effectively >> done by the remote PEs based on the information advertised by the PEs in >> the ES, right? >> >> > >> >> - PE1 is the primary - the winner of the DF election. PE1 sends P=1 >> >> - PE2 is the backup - the winner of the DF election (without PE1). >>PE2 >> >> sends B=1. >> > >> >Hmm ... DF election is for BUM in RFC 7432 and never mentioned in this >> draft. If it is used for VPWS, it needs to be specified. >> >> [JORGE2] In VPWS DF election is needed for single-active. The NDF will >> block the AC for the service. For all-active there is no DF, of course, >> since there is no BUM ;-) >> >> > >> >The draft says multiple PEs could all set the P/B bits: >> > >> > In multihoming single active scenario, a remote PE receiving P=1 >>from >> > more than one PE will select only one primary PE when forwarding >> > traffic. A remote PE receiving B=1 from more than one PE will select >> > only one backup PE. A remote PE MUST receive P=1 from at least one >>PE >> > before forwarding traffic. >> > >> >And the decision is based on the receiving PE, not on DF election? >> >> [JORGE] This is BGP, there are always transient situations, so it may >> happen that even in single active you get more than one P=1 or B=1, so >>you >> need to say what to do in that case, right? In a steady situation, in >> single-active MH, only the DF MUST send the P=1 since it is only the DF >> the one unblocking the AC in the ES. >> >> > >> >> - PE3 then sends P=B=0. This indicates that PE3 is neither primary >>nor >> >> backup, but the AC is active (if it was oper-down, it would withdraw >> the >> >> route). >> > >> >What purpose does the route from PE3 serve? >> >> [JORGE] since the AC is oper-up on PE3, PE3 needs to send the route. At >> PE4 you know that PE3¹s AC in the ES is good, but simply neither primary >> nor backup. >> >> > >> >> - In case of a failure on PE1, PE2 will activate its AC on ES-1 since >> he >> >> wins the new DF election. >> > >> >What does "activate" involve exactly? Just re-advertise the route with >>P- >> bit set and B-bit cleared? >> >> [JORGE] unblock Tx/Rx on the ACŠ and later readvertise the route with >>the >> new bits. >> >> > >> >> At the same time, PE4 can immediately send >> >> traffic to PE2 as soon as PE1 withdraws the AD routes. PE4 does not >> even >> >> need to wait for the confirmation that PE2 is the new DF. This backup >> >> mechanism speeds up convergence big time. >> >> - The mechanism above does not work if PE2 and PE3 send both the same >> >> P=B=0, since it case of PE1 failure, PE4 could not send any traffic >>(it >> >> does not know who is the active one in the ES) and would need to wait >> for >> >> PE2 to send P=1. >> > >> >I don't see any use of the route from PE3. The draft seems to say that >> both PE1 and PE2 can set the P bit initially and PE4 will pick one to >>send >> traffic to. If it picks PE1 and then PE1 withdraws the route, PE4 will >> then pick PE2? >> >> [JORGE] This is single active, so only one can transmit/receive to/from >> the CE. So only that one should send P=1. >> >> > >> >Jeffrey >> >_______________________________________________ >> >BESS mailing list >> >[email protected] >> >https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >BESS mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
