Hi Jeffrey, This is a draft based on RF7432 and as such we are expecting tag manipulation wrt vlan-based service to be consistent with RFC 7432. Additional comments below Š
On 5/12/16, 11:27 AM, "BESS on behalf of Rabadan, Jorge (Nokia - US)" <bess-boun...@ietf.org on behalf of jorge.raba...@nokia.com> wrote: >HI Jeffrey, > > >On 5/12/16, 8:13 PM, "BESS on behalf of EXT Jeffrey (Zhaohui) Zhang" ><bess-boun...@ietf.org on behalf of zzh...@juniper.net> 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? Just as in RFC7432, Eth A-D per ES indicates what kind of multi-homing is associated with this ES (all-active versus single-active). The P/B bits in Eth A-D per EVI, indicates active/backup role per instance and its usage is recommended for multi-homing but not needed for dual-homing. > >> >>> - 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 ;-) Yes, forwarding decision is based on VLAN tag and not based on MAC addressses, so there is no notion of known unicast versus BUM traffic here. > >> >>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. We should add some text to the draft to indicate ³reception of multiple P=1² is for transient situation. > >> >>> - 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. E.g., it can be considered as 2nd backup. -Ali > >> >>> - 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 >>BESS@ietf.org >>https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
