Parag, and all,
A couple of additional questions dealing with the definition of the EVPN AD
sub-TLV in Section 4.3 of the
draft<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping#section-4.3>.
1. I assume that this sub-TLV can be used to differentiate between per-ES
and per-EVI EVPN Ethernet Auto-Discovery (Type 1) routes by the value of
Ethernet Tag:
* For per-ES EVPN Type 1 routes the Ethernet Tag field in the sub-TLV
must be set to the reserved MAX-ET value
* For per-EVI EVPN Type 1 routes the Ethernet Tag field in the sub-TLV
must be set to the non-reserved value
If this assumption is correct, it would be nice to have this explicitly
specified in the draft
1. There no references to the EVPN AD sub-TLV in the draft. Instead, there
are two references to the Ethernet AD sub-TLV
* In the last para of Section 6.2.1 when it is included in the Target
FEC TLV of an LSP Ping request while an ESI label advertised by the
corresponding remote PE for the MH ES identified by the ESI value in the
sub-TLV is included in the label stack. My guess is that in this case this
sub-TLV refers to the per-ES EVPN Type 1 route – can you please confirm?
* In Section 6.3 when this sub-TLV it is included in the Target FEC TLV
of an LSP Ping request while the label stack includes the aliasing label
advertised by the specific MAC-VRF of the remote PE for the MH ES identified by
the ESI value in the sub-TLV is included in the label stack. My guess is that
in this case this sub-TLV refers to the per-EVI EVPN Type 1 route – can you
please confirm?
2. Section 8.2 of RFC
7432<https://datatracker.ietf.org/doc/html/rfc7432#section-8.2> specifies that
a per-ES EVPN Type 1 route for a given multi-homed ES may be advertises
multiple times with different RD values because it may carry more Route Targets
than could be fit into a single BGP Update message. Can you please explain
which RD value should be used in the EVPN AD sub-TLV if it is used in
association with a per-ES EVPN Type 1 route in (2b) above?
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]
From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:03 PM
To: Parag Jain (paragj) <[email protected]>
Cc: [email protected]; [email protected]
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping
Importance: High
Parag,
Lots of thanks for a prompt response.
At the same time your response does not resolve my concerns, since I have
failed to understand why in Example#1 you propose responding with “return code
3 - Replying router is an egress for the FEC at stack-depth” while in Example#2
you propose responding with “return code corresponding to The FEC exists on the
PE and the behavior is to drop the packet because of Split Horizon Filtering”.
In both cases a BUM packet received by PE-1 with the label stack described
would not be discarded:
* In example 1 it would be sent towards CE-2 and CE-4 (but not to CE-2
because PE-1 is not the DF on MH ES-1)
* In example 2 it still would be sent towards CE-4 (because it is a
single-homed CE).
In any case I think that explicit definition of the scenarios in which any of
the new return codes should be used in missing in the draft.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]<mailto:[email protected]>
From: Parag Jain (paragj) <[email protected]<mailto:[email protected]>>
Sent: Friday, October 29, 2021 5:34 AM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [EXTERNAL] Re: A question about draft-ietf-bess-evpn-lsp-ping
Importance: High
Hi Alexander,
Please see inline.
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Tuesday, October 26, 2021 at 11:51 AM
To:
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
Subject: A question about draft-ietf-bess-evpn-lsp-ping
Resent-From: <[email protected]<mailto:[email protected]>>
Resent-To: <[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>,
<[email protected]<mailto:[email protected]>>
Resent-Date: Tuesday, October 26, 2021 at 11:51 AM
Hi,
A have a question about usage of the new return codes defined in the latest
version of draft-ietf-bess-evpn-lsp-ping.
Section 8.2 of the
draft<https://clicktime.symantec.com/3Jca2eC7hH1xm34XuNuqi9A6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-lsp-ping%23section-8.2>
requests IANA to define two new return codes as explained below:
o The FEC exists on the PE and the behavior is to drop the packet
because of not DF.
o The FEC exists on the PE and the behavior is to drop the packet
because of Split Horizon Filtering.
Section 6.2.1 of the
draft<https://clicktime.symantec.com/3FCJxL7BmTpcsrv8pCBcWUm6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-lsp-ping%23section-6.2.1>
describes how these codes may be used in a very simple scenario.
My question deals with a sightly more complicated scenario that is shown in the
embedded diagram below (and also in the attached PDF file).
It still deals with an EVI that uses ingress replication for delivery of BUM
traffic and is instantiated in PE-1, PE-2, and PE-3 (same as in the draft) that
exchange and receive Inclusive Multicast Ethernet (IMET) Tag EVPN routes.
However, in my example the EVI in PE-1 and PE-2 are each attached to two
dual-homed CEs (CE-2 and CE-3) via two different All-Active multi-homed
Ethernet segments in such a way that:
1. The EVI in PE-2 is selected as the DF on MH ES-1
2. The ECI in PE-1 is selected as the DF on MH ES-2
(quite easy to achieve, say, with the default DF election procedure, VLAN-based
service interface and egress VLAN translation).
In addition, the EVI in PE-1 is attached to a single-homed CE-4.
Just as in the example in the draft, an operator sends an LSP Ping request from
PE-3 to PE-1 for the FEC associated with IMET route that has been advertised by
the EVI in this PE.
But, to differentiate from the example in the draft, the EVI in PE-1 is
attached to 3 different Ethernet segments:
* To a single homed Ethernet segment that attaches it to CE-4
* To a multi-homed Ethernet segment MH ES-1 on which it is not elected as
the DF
* To a multi-homed Ethernet segment MH ES-2 on which it is elected as the
DF.
Which return code is supposed to be used in the reply to this request?
Paragj> for the example above, the PE-1 should reply with return code 3 -
"Replying router is an egress for the FEC at stack-depth" as per RFC8209. LSP
Echo Request is used to test a particular LSP identified by the FEC Stack
included in the packet. The response by PE-1 for FEC associated with IMET route
is dependent on EVI (and bridge table) and independent of ESI (and ACs).
Paragj> in Section 6.2.1 of the draft-ietf-bess-evpn-lsp-ping draft, we will
also update the text that ISID in ethernet tag field is used to determine the
bridge table and that the processing of Echo Request packet on PE2 will be
similar to that on PE1.
In another scenario, suppose that the operator sends an LSP Ping request from
PE-2 to PE-1 1 for the FEC associated with IMET route that has been advertised
by the EVI in this PE and includes the ESI label that PE-1 has advertised in
the per-ES Ethernet Auto-Discovery EVPN route for MH ES-2 (for which the ESI in
PE-1 is the DF).
Which return code is supposed to be used in the reply to this request?
Paragj> since an Ethernet AD sub-TLV corresponding to ES-2 and the associated
MPLS Split Horizon Label is carried in the LSP Ping packet from PE-2, the PE-1
should reply with return code corresponding to “The FEC exists on the PE and
the behavior is to drop the packet because of Split Horizon Filtering”.
Thanks
Parag
Your timely feedback would be highly appreciated.
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: [email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
