Re: [Last-Call] Last Call: <draft-ietf-bess-evpn-virtual-eth-segment-08.txt> (EVPN Virtual Ethernet Segment) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sasha,

 

It is probably just a question of terminology, but the way I see it, you don’t really need bidirectional LSPs, but a pair of unidirectional LSPs where the origination endpoint of one matches the termination endpoint of the other.

Suppose we use the example of Figure 2.

 

PW3 and PW4 have the same end-points (AG2 and PE1), and both share the same transport LSPs in both directions. In the PE’s egress direction, both PWs use LSP1-to-AG2. In the ingress direction both PWs use LSP1-to-PE1. Those two LSPs use the same endpoints AG2 and PE1, and it is really what LSP1 represents in the figure.

 

  • The association to the virtual ES is represented as LSP1, but indeed needs to cover LSP1-to-AG2 and LSP1-to-PE1.
  • After DF election, if PE1 is the non-DF, the PWs that use LSP1 will be brought oper-down. No traffic will be transmitted or received on them.
  • If PE1 is DF, the PWs that use LSP1 are oper-up. When BUM traffic is received on either PW, the PE needs to identify it as coming from the ethernet segment, so that, when forwarded to the EVPN BD, the ESI label can be pushed at the bottom of the stack if needed.

 

That’s how the implementation with which I’m familiar works.

Maybe this is partly implicit in the text and can be clarified.

 

Hope it helps.

Thanks.

Jorge

 

 

From: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>
Date: Monday, April 17, 2023 at 3:53 PM
To: Jorge Rabadan (Nokia) <jorge.rabadan@xxxxxxxxx>
Cc: bess@xxxxxxxx <bess@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, draft-ietf-bess-evpn-virtual-eth-segment@xxxxxxxx <draft-ietf-bess-evpn-virtual-eth-segment@xxxxxxxx>
Subject: RE: Last Call: <draft-ietf-bess-evpn-virtual-eth-segment-08.txt> (EVPN Virtual Ethernet Segment) to Proposed Standard

 

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

 

Jorge,

Lots of thanks for a prompt response.

 

AFAIK it is perfectly valid to advertise Implicit Null label for a FEC representing a local address in RSVP-TE.

And I am not sure what you mean by “single-hop LSPs in general”.

 

From my POV, LSP are, generally speaking, unidirectional while PWs and Ethernet Segments are inherently bi-directional.

In the case of Ethernet Segments:

-          Their egress direction affects the results of DF election

-          Their ingress direction affects inclusion – or non-inclusion of ESI label in certain copies of flooded BUM traffic.

So I still think that if you want to treat an LSP as a virtual Ethernet Segment, you need a bi-directional LSP (Be it MPLS-TP or not).

 

The draft, in its current form, simply ignores these differences.

What, if anything, do I miss?

 

Regards,

Sasha

 

From: Jorge Rabadan (Nokia) <jorge.rabadan@xxxxxxxxx>
Sent: Monday, April 17, 2023 9:08 AM
To: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>; last-calls@xxxxxxxx; draft-ietf-bess-evpn-virtual-eth-segment@xxxxxxxx
Cc: bess@xxxxxxxx
Subject: [EXTERNAL] Re: Last Call: <draft-ietf-bess-evpn-virtual-eth-segment-08.txt> (EVPN Virtual Ethernet Segment) to Proposed Standard

 

Hi Sasha,

 

There would be more cases where you can identify traffic coming from a given LSP.

For instance RSVP-TE, or single-hop LSPs in general, etc – there is no need for bidirectional MPLS-TP.

 

The text itself implicitly refers to the cases where PWs can be aggregated into a common LSP, so not sure if anything else is needed.

 

Thanks.

Jorge

 

 

 

From: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>
Date: Sunday, April 16, 2023 at 5:44 PM
To: last-calls@xxxxxxxx <last-calls@xxxxxxxx>, draft-ietf-bess-evpn-virtual-eth-segment@xxxxxxxx <draft-ietf-bess-evpn-virtual-eth-segment@xxxxxxxx>
Cc: GTD-SYS-Packet Solutions <GTD-SYS-Packet-Solutions@xxxxxxxx>, bess@xxxxxxxx <bess@xxxxxxxx>
Subject: Re: Last Call: <draft-ietf-bess-evpn-virtual-eth-segment-08.txt> (EVPN Virtual Ethernet Segment) to Proposed Standard

 

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.

 

Hi all,

I have doubts regarding the text in Section 1.2 of the draft that refers to LSPs (as opposed to PWs) as virtual Ethernet Segments.

 

The problematic (from my POV) text refers to Figure 2 and says (the problematic part is highlighted):

 

 

   In such scenarios, a virtual ES (vES) is defined as a set of

   individual PWs if they cannot be aggregated into a common LSP.  If

   the aggregation of PWs is possible, the vES can be associated to an

   LSP in a given PE.  In the example of Figure 2, EVC3 is connected to

   a VPWS instance in AG2 that is connected to PE1 and PE2 via PW3 and

   PW5 respectively.  EVC4 is connected to a separate VPWS instance on

   AG2 that gets connected to an EVI on PE1 and PE2 via PW4 and PW6,

   respectively.  Since the PWs for the two VPWS instances can be

   aggregated into the same LSPs going to the MPLS network, a common

   virtual ES can be defined for LSP1 and LSP2.  This vES will be shared

   by two separate EVIs in the EVPN network.

 

 

The problem with the highlighted text is that PE1 and PE2 always can identify the PW from which they receive this or that packet, but, in most cases, cannot identify the LSP in which this PW has been running.

(The only exception of which I am aware, is the case of static PWEs in bi-directional MPLS-TP LSPs).

If LSP1 and LSP2 were components of a common virtual MH ES,  PE1, upon reception of a BUM packet from PW4, would not be able to identify this MH ES and to insert a suitable ESI label into the EVPN encapsulation of the copy it would be sending to PE2.

 

IMHO and FWIW some clarification (e.g., restricting ability to use LSPs as virtual Ethernet Segments to just bi-directional MPLS-TP LSPs?) would be very much in place.

 

Hopefully these notes will be useful.

 

Regards,

Sasha

 


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'EVPN Virtual Ethernet Segment'

  <draft-ietf-bess-evpn-virtual-eth-segment-08.txt> as Proposed Standard

 

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@xxxxxxxx mailing lists by 2023-04-27. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

 

Abstract

 

 

   EVPN and PBB-EVPN introduce a family of solutions for multipoint

   Ethernet services over MPLS/IP network with many advanced features

   among which their multi-homing capabilities.  These solutions

   introduce Single-Active and All-Active for an Ethernet Segment (ES),

   itself defined as a set of physical links between the multi-homed

   device/network and a set of PE devices that they are connected to.

   This document extends the Ethernet Segment concept so that an ES can

   be associated to a set of EVCs (e.g., VLANs) or other objects such as

   MPLS Label Switch Paths (LSPs) or Pseudowires (PWs), referred to as

   Virtual Ethernet Segments (vES).  This draft describes the

   requirements and the extensions needed to support vES in EVPN and

   PBB-EVPN.

 

 

 

 

 

The file can be obtained via

https://clicktime.symantec.com/15sLvSMFe6yJaL7it9kEb?h=WX7sPrWtPYj6YArP1_IG-VUvi72ntJf3jPZD8aotZlk=&u=https://clicktime.symantec.com/15siFA9u7fT6Pcy1rRzYE?h=oH6e_3PB3X1eWGKah_83SV7rAO13MiTubvXyMPWLSs4=&u=https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-virtual-eth-segment/

 

 

The following IPR Declarations may be related to this I-D:

 

   https://clicktime.symantec.com/15sM1GYY6ietzGweRi9PD?h=LatO2AZiVAH39lrwHIwya5amzj8HrV_kDAIVEAeg85M=&u=https://clicktime.symantec.com/15siKzMBaH8goZnwPzPgr?h=2sUb0zrdQ5wcPvhgS2fD7IYQBGY3koDFG7wzpwkjYlU=&u=https://datatracker.ietf.org/ipr/3169/

   https://clicktime.symantec.com/15sMAvw71x25pAbVWpwgT?h=GdR-katv1Fmx1tCzKJUyhSBiuWnAI85UP95ltcuRR_U=&u=https://clicktime.symantec.com/15siVejkVWVsdTSnV7Bz6?h=sT7aE2ZEJl5mDkO4HW9iizdbIbzENVSMXvgn_zrG5lg=&u=https://datatracker.ietf.org/ipr/3354/

   https://clicktime.symantec.com/15sM66jpZLLVQDmZyGYXq?h=Hr8E955Kl0orr2_O8JUL1JHDwJMJS1wH8Q2F_JhQIrM=&u=https://clicktime.symantec.com/15siQpYU2tpHDWcrwYnqU?h=vhhGcaEYULDbhQhTesln7lZn7Qj-ZfAKgO-VH6KAeCU=&u=https://datatracker.ietf.org/ipr/3353/

 

 

 

 

 

Regards,

Sasha

 


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.


Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux