Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

["Ali Sajassi (sajassi)" <[e-mail]>]

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)"
<[e-mail] on behalf of [e-mail]> wrote:

>HI Jeffrey,
>
>
>On 5/12/16, 8:13 PM, "BESS on behalf of EXT Jeffrey (Zhaohui) Zhang"
><[e-mail] on behalf of [e-mail]> 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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/bess
>
>_______________________________________________
>BESS mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bess