Re: [Pals] [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

[Alexander Vainshtein <[e-mail]>]

Jorge,
Again lots of thanks for the clarification.

I think that we are actually in sync with regard to “Single-Active vES that uses PWs.
Your examples speak about “PW1 on EVI1 being DF and PW2 on EVI2, same PE, being NDF”, i.e., each PW connecting just one EVI to its CE and using the PW Status bits to indicate whether this PW is a DF or NDF for the only EVI to which it belongs. I do not have any problems with such a restriction.

As for the All-Active vES using the hack described by Luc  - have serious doubts regarding its feasibility. E.g., how would the CE discover that one of the “anycast PEs” fails? ? You would not be able to run any kind of diagnostic between each individual PE and the CE, right?

In any case I think that the next revision of the draft should be more explicit regarding what is in and what out of scope.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Tuesday, October 2, 2018 12:46 PM
To: Alexander Vainshtein <[e-mail]>
Cc: Michael Gorokhovsky <[e-mail]>; Alexander Ferdman <[e-mail]>; Shell Nakash <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Luc Andre Burdet (lburdet) <[e-mail]>; Ali Sajassi (sajassi) <[e-mail]>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Hi Sasha,

Please see in-line.
Thank you.
Jorge

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 2, 2018 at 10:24 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>, Alexander Ferdman <[e-mail]<mailto:[e-mail]>>, Shell Nakash <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Luc Andre Burdet (lburdet)" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Jorge,
Again, lots of thanks for your message  – and apologies for my delayed response.

After some thinking, I think that I can summarize your statement as following:

1.       The draft discusses two different types of vES:

a.       vES comprised of EVCs across an Ethernet access network

b.       vES comprised of PWs across an MPLS access network

2.       All considerations pertaining multi-homing of vES in the draft deal only with vES  of the first type.

a.       With the vES of the first type all “normal” PE-CE mechanisms (LAG for all-Active, MVRP for Single-Active etc.) can be used

b.       Scalability requirements in the draft are formulated as so many vES per ENNI port which only makes sense for the vES of the first type

3.       When it comes to vES of the second type, from your POV within the scope of this draft they are limited to:

a.       Single-homed vES
[JORGE] Multi-homed vES… I don’t think there is a need to specify single-homed vES.


b.       Single-Active vES that use Port-Active redundancy mode (see draft-brissette<https://tools.ietf.org/html/draft-brissette-bess-evpn-mh-pa-01>) with PW status-based signaling for propagating DF election from PEs to CEs.
[JORGE] Two comments:
-          All-active is possible as Ali/Luc mentioned, but it has to be specified clearly if we agree it is required.
-          Single-active (in the way I mentioned) is not port-active. PW status bits can signal the state of each individual PW going to a remote PE, so you can have PW1 on EVI1 being DF and PW2 on EVI2, same PE, being NDF. The PE would signal PW-status standby for PW2 and PW-status 0x0 for PW1. As I was saying the association to the vES in this case is based on the vc-id only and not vc-id + VLANs.


Any other modes are simply out of scope of the draft/
[JORGE] there is a third one that is suggested in the draft – LSP based (in the same way you can have an ES associated to a port, or a vES to an individual VLAN, in some cases it is possible to associate the ES to an LSP, instead of associating the vES to each individual PW within the LSP).

If this understanding is correct, then I do not have any technical issues with it – but, of course, it would be nice to see this stated explicitly in the draft.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Rabadan, Jorge (Nokia - US/Mountain View) [mailto:[e-mail]]
Sent: Thursday, September 27, 2018 11:38 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Luc Andre Burdet (lburdet) <[e-mail]<mailto:[e-mail]>>; Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>; Alexander Ferdman <[e-mail]<mailto:[e-mail]>>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Sasha,

Thank you.
I keep my statement (section 1.2 is the one explaining how a virtual ES can be a set of LSPs or individual PWs, and there is no mentioning of all-active), although again, there are many things to clarify in the text, I agree.

If there is a 1:1 mapping between CE and PW on a given PE, the association can be based on the PW itself. For instance in Figure 2, PW3 and PW5 can be associated to virtual ES-1. Single-active just needs from the NDF to signal PW status bits e.g. standby signaling, so that AG2 sends the traffic to the DF only. That was the idea of Figure 2, and some implementations out there. In the example, the association can be simply based on the PW (vc-id) and the NDF signaling based on PW status bits. No need for MVRP or ELMI, etc. Agreed, it should be mentioned.

Thanks.
Jorge

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 27, 2018 at 10:01 PM
To: "Luc Andre Burdet (lburdet)" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>, Alexander Ferdman <[e-mail]<mailto:[e-mail]>>, Shell Nakash <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Jorge,
Lots of thanks for your response.
Unfortunately, a search for "All-Active" in the draft provided 18 hits, some of them (e.g. in Section 3.1) being in firect contradiction with your statement "in the current text, there is nothing (I think) that implies that you can use all-active mode with an ES that is associated to PWs".
And "Single-Active" is not so simple either if you use PWs that carry multiple VLANs (explicitly alloeed in the draft). If thede VLANd go to different EVIs, per-EVI DF election schemes (starting from the default one) would require some PE-CE protocol to notify the CE about the results of DF election - but these protocols would have to run over the same PWs. I do not think that MVRP or E-LMI could be used in such a way. Of course if you only use PWs carryinga single VLAN each, you could simply use PW status - but this is not mentioned in the draft.
My 2c
Thumb typed by Sasha Vainshtein

________________________________
From: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, September 27, 2018 7:11:22 PM
To: Alexander Vainshtein; Luc Andre Burdet (lburdet); Ali Sajassi (sajassi)
Cc: Michael Gorokhovsky; Alexander Ferdman; Shell Nakash; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Sasha,

Although I agree with Luc and Ali that an all-active solution can be added to the description, note that, in the current text, there is nothing (I think) that implies that you can use all-active mode with an ES that is associated to PWs. So unless we add that description for all-active, people should assume PW-based ES’es support only single-active mode.

My 2 cents.

Jorge


From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, September 26, 2018 at 10:58 AM
To: "Luc Andre Burdet (lburdet)" <[e-mail]<mailto:[e-mail]>>, "Ali Sajassi (sajassi)" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>, Alexander Ferdman <[e-mail]<mailto:[e-mail]>>, Shell Nakash <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Jorge Rabadan <[e-mail]<mailto:[e-mail]>>
Resent-Date: Wednesday, September 26, 2018 at 10:58 AM

Ali,
Lots of thanks for a prompt response.
I fully understand how the scheme described by Luc could work.
But I have some doubts regarding it matching the standard PW architecture.
First of all, tbis scheme mandates usage of static PW labels - I do not think this is common, not even with MPLS-TP (where, at least nominally, you could still advertise PW labels using targeted LDP session between the pair of PEs).
There are some generic PW mechanisms that cannot be used (e.g., sequencing). This may be a minor issue because "fat PWs" (RFC 6391) also do not allow sequencing.
And there may be more - e.g., I doubt you could use static PW status messages (RFC 6478) with this construct...
So I think that asking the PALS WG (that, from my POV, is the body that has the authority to decide what is and what is not a PW) position on this construct  makes sense.
Thumb typed by Sasha Vainshtein

________________________________
From: Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, September 25, 2018 7:07:00 PM
To: Alexander Vainshtein; Luc Andre Burdet (lburdet)
Cc: Michael Gorokhovsky; Alexander Ferdman; Shell Nakash; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Hi Sasha,

What Luc mentioned below can work with any of the existing model supporting static PW because the pair of EVPN PEs terminating vES (with PW termination) act and look like a single logical PE to the CE. Therefore, the CE sees its PW being terminated by a single logical PE. EVPN provides the synch mechanism between the pair of PEs running vES. I agree with Luc that an example can be provided in the draft to describe how All-Active vES can be supported with PWs.

Cheers,
Ali

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 25, 2018 at 8:09 AM
To: "Luc Andre Burdet (lburdet)" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>, Alexander Ferdman <[e-mail]<mailto:[e-mail]>>, Shell Nakash <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Tuesday, September 25, 2018 at 8:09 AM

Luc,
Lots of thanks for a prompt and highly informative response.

I am adding the PALS WG to the CC list since, from my POV, your proposal goes beyond the PW network reference model as shown in Figure 2 of RFC 3985<https://tools.ietf.org/html/rfc3985>.
While this model has been extended to cover multi-segment PWs (RFC 6073<https://tools.ietf.org/html/rfc6073>), PW redundancy (RFC 6718<https://tools.ietf.org/html/rfc6718>) and ICCP (RFC 7275<https://tools.ietf.org/html/rfc7275>)  none of these extensions seem to be directly applicable to the proposed scheme.

My 2c,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: Luc Andre Burdet (lburdet) [mailto:[e-mail]]
Sent: Tuesday, September 25, 2018 5:46 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>; Alexander Ferdman <[e-mail]<mailto:[e-mail]>>; Shell Nakash <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Hi Sasha,

I agree the vES draft does not go in great detail about A/A PWs.

For A/A PWs terminating at peering PEs, the concept is similar to LAG, using static label at peering PEs:
•         The CE sets up a single PW to remote endpoint to anycast IP1, Label1.
•         PE1, PE2 set up a PW each to CE, using local static label Label1.
•         PE1,PE2 adv IP1 as anycast IP towards CE-side
There will not be excessive MAC-moves since the CE sees only one pseudowire to a single remote—very similar to what is done for LAG on “real” links.

We can update the draft to be more descriptive—that draft needs a re-read anyways, the header on each page still reads “PBB-EVPN” ☺

HTH,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
[e-mail]<mailto:[e-mail]>
Tel: [phone]






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS <[e-mail]<mailto:[e-mail]>> on behalf of Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 25, 2018 at 06:25
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Michael Gorokhovsky <[e-mail]<mailto:[e-mail]>>, Alexander Ferdman <[e-mail]<mailto:[e-mail]>>, Shell Nakash <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Dear authors of the EVPN Virtual Ethernet Segment<https://tools.ietf.org/html/draft-sajassi-bess-evpn-virtual-eth-segment-03> draft,
My colleagues and I have a question pertaining to support of All-Active redundancy mode in EVPN that uses virtual Ethernet Segments.

Section 8.5 of RFC 7432<https://tools.ietf.org/html/rfc7432#section-8.5> says:

   If a bridged network is multihomed to more than one PE in an EVPN
   network via switches, then the support of All-Active redundancy mode
   requires the bridged network to be connected to two or more PEs using
   a LAG.

   If a bridged network does not connect to the PEs using a LAG, then
   only one of the links between the bridged network and the PEs must be
   the active link for a given <ES, VLAN> or <ES, VLAN bundle>.  In this
   case, the set of Ethernet A-D per ES routes advertised by each PE
   MUST have the "Single-Active" bit in the flags of the ESI Label
   extended community set to 1.

This restriction is easy to understand, since, with the All-Active multi-homing mode of an Ethernet Segment, a CE attached to such a segment potentially would receive traffic from all the PEs attached to this  segment. Since A CE that is part of a bridged network must learn MAC addresses of the received traffic, it would potentially experience continuous MAC Move events – with undesirable consequences.

The EVPN Virtual Ethernet Segment draft replaces Ethernet links (forming a “real” ES) with Ethernet PWs, and claims support of both Single-homed and multi-homed multi-homing modes. When I compare these claims with the quoted above statement from RFC 7432, I see two possibilities:
•         Either a CE that is connected to an All-Active vES cannot be part of a bridged network (and thus would not do any MAC learning)
•         Or  an extension of LAG that deals with Ethernet PWs instead of Ethernet links is required.

Could you please clarify which of these two options is correct?

Note: The draft includes Informative references to the two drafts that have been published as RFC 7432 and RFC 7623.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________