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

[Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>]

Jorge,

Lots of thanks for a prompt response.

 

I will try to summarize our agreements and disagreements.

I also have an additional question regarding usage of LSPs as virtual Explicit Segments.

 

First, the summary:

 

1. As I see, we agree that LSP as a virtual Ethernet Segment actually means  “a pair of unidirectional LSPs where the origination endpoint of one matches the termination endpoint of the other”, so that one direction of the aggregated PWs uses on of these LSPs and the other direction – the other one.  (This presumably implies that the two LSPs also share the life span).
2. We also seem agree that the (data plane of the) EVPN PE that acts as the tail-end of one of these LSPs MUST be able to identify the PW packets it receives as being delivered in this LSP.  This precludes using PHP towards EVPN PE

 

Neither of these points is explicitly mentioned in the current version of the draft (or at least I have not found any mention of them).

 

Our disagreement seems to be entirely about references to MPLS-TP:

 

1. You object to restricting LSPs as virtual Ethernet Segment to MPLS-TP and static PWs.
2. From my POV:
1. A pair of unidirectional LSPs with a common life span and such that the head-end of one matches the tail-end of the other and vice versa is exactly what RFC 59060 calls an “associated bidirectional LSP” in MPLS-TP
2. MPLS-TP also strongly discourages usage of PHP
3. These definitions do not say anything about the method by which such a pair of LSPs and the PWs that us it are set up:

                                                               i.      RFC 6373 defines a framework for dynamically signaling various types of MPLS-TP LSPs and states that the common PW control plane can be used for signaling PWs that use MPLS-TP LSPs

                                                             ii.      AFAIK there are implementations of such a control plane.

From my POV, my comment would be resolved if you clarified the above-mentioned points of agreement even without mentioning MPLS-TP.

 

Now my additional question.

 

Sections 3.5 and  4.1 of the draft explain how the  default (“service carving”) DF Election algorithm as defined in RFC 7432  could be used with virtual Ethernet Segments.

1. It is my understanding that in the case of LSP as a multi-homed virtual Ethernet Segment, the service carving algorithm would be applied to each individual PW aggregated in this LSP. E.g., in the example of Figure 2 in the draft, the situation in which PW3 is elected as the DF in the {PW3, PW5} pair while  PW6 is elected as the DF in the {PW4, PW6} pair may occur. Can you please confirm is this correct?
2. If (1) above is correct, can you please clarify, which value should be used as the Ethernet Tag of the specific PW in this LSP, since the reverence to a VLAN ID in Section 3.5 of the draft looks problematic to me.

 

Regards, and lots opf thanks in advance

Sasha

 

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

 

Hi Sasha,

 

“To me this is equivalent to your definition.”

 

Sure, however, I was not excluding any LSP type, and I don’t think we need to, since the actions are really happening on the PWs riding on those LSPs.

So if your suggestion is that we should add text to restrict this to static PWs and MPLS-TP LSPs, I don’t agree. That does not reflect what implementations are doing.

 

Thanks.

Jorge

 

From: Alexander Vainshtein <Alexander.Vainshtein@xxxxxxxx>
Date: Wednesday, April 19, 2023 at 7:47 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 your response.

 

This indeed may be a matter of terminology.

Section 3.1.3 of RFC 5960 says:

 

 

   A point-to-point associated bidirectional LSP between LSRs A and B

   consists of two unidirectional point-to-point LSPs, one from A to B

   and the other from B to A, which are regarded as a pair providing a

   single logical bidirectional transport path.

 

To me this is equivalent to your definition.

 

 

Did I miss something substsntial?

 

Regards,

Sasha

 

 

 

 

 

Get Outlook for Android

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