Jorge,
Lots of thanks for your response.
It seems we are mainly on the same page.
It would be nice if you could clarify the point about "a group of PW that share
the same pair of unidirectional LSPs" and mention the need to identify the
ingress LSP from which the PW packets have been received by the EVPN PE in the
text of the draft.
Such a text would fully resolve my comment.
Regards,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>
Sent: Thursday, April 27, 2023, 20:18
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>
Cc: bess@ietf.org <bess@ietf.org>; last-c...@ietf.org <last-c...@ietf.org>;
draft-ietf-bess-evpn-virtual-eth-segm...@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,
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 <alexander.vainsht...@rbbn.com>
Date: Thursday, April 20, 2023 at 5:23 PM
To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>
Cc: bess@ietf.org <bess@ietf.org>, last-c...@ietf.org <last-c...@ietf.org>,
draft-ietf-bess-evpn-virtual-eth-segm...@ietf.org
<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 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://clicktime.symantec.com/15siFAEXoqZFzL2ph9fzk?h=BRKc2hwfLrEKYungZ6EQviPdp8eBkvLX4NvHb9xOC9s=&u=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.
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
