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

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Sasha,

I think the misunderstanding could be solved if we worded the association to the virtual ES differently. The association is really to a group of PWs that share the same unidirectional LSP pair (rather than to the LSP, which I can see why is confusing). The multi-homing procedures are done on the PWs and not on the LSPs. In other words, in Figure 2, we could two vESes composed of PW3/PW5 and PW4/PW6, or you could group them together and have only one vES, i.e. PW3+PW4/PW5+PW6. The latter is a way to reduce the amount of ethernet segments given that e.g., PW3 and PW4 share fate in case one of their transport LSPs fail.

About the additional questions:


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?

Yes. Note that we are using the definition of Ethernet Tag as in RFC8584, where the Ethernet Tag can be a configured ID or configured EVI value, or etc. as long as it represents the BD and it is consistently configured on all the PEs attached to the ES.


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.
See above. In the implementations that I know of, an ID identifying the BD is configured consistently in the PEs attached to the ES. That can be a VLAN ID or an EVI or anything as per RFC8584. I don’t see a problem here.

Thanks.
Jorge


From: Alexander Vainshtein <[e-mail]>
Date: Thursday, April 20, 2023 at 5:23 PM
To: Jorge Rabadan (Nokia) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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.

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:

a.       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

b.       MPLS-TP also strongly discourages usage of PHP

c.        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<https://datatracker.ietf.org/doc/html/rfc6373> 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) <[e-mail]>
Sent: Wednesday, April 19, 2023 9:50 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 19, 2023 at 7:47 PM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [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: 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<https://clicktime.symantec.com/15t5eiByNXDkfTWSFy5rH?h=PWpabQIfD818Y8rD_hEEip92W5R9D2ueQAbFw4T-z2Y=&u=https://datatracker.ietf.org/doc/html/rfc5960%23section-3.1.3> 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<https://clicktime.symantec.com/15t5ZszguuYAFWgWiQghf?h=uOrQw-JKk6ofKNnTQFmXa4bVptKtXNW3REwgG8lohkI=&u=https://aka.ms/AAb9ysg>

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.