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 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
* MPLS-TP also strongly discourages usage of PHP
* 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) <jorge.raba...@nokia.com>
Sent: Wednesday, April 19, 2023 9:50 PM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Cc: bess@ietf.org; last-c...@ietf.org;
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org
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.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>
Date: Wednesday, April 19, 2023 at 7:47 PM
To: Jorge Rabadan (Nokia)
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>,
last-c...@ietf.org<mailto:last-c...@ietf.org>
<last-c...@ietf.org<mailto:last-c...@ietf.org>>,
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>
<draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org<mailto:draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org>>
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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
