Re: [bess] A question about draft-ietf-bess-evpn-lsp-ping

["Parag Jain (paragj)" <[e-mail]>]

Hi Sacha,

Pls see inline.

From: Alexander Vainshtein <[e-mail]>
Date: Sunday, October 31, 2021 at 6:03 AM
To: "Parag Jain (paragj)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping

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

Paragj> In example#2,  since the EVPN Ethernet AD Sub-TLV is received in the Echo Request packet, PE-1 can reply with a return code that  gives more info than a generic Return Code 3. We can change the description of the return code to be more precise:

“Replying router is egress for the FEC at the stack depth. In addition, the BUM packets are dropped on the ES corresponding to the ESI received in EVPN Ethernet AD Sub-TLV because of the Split Horizon Group 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.

Paragj> Yes, will update the draft by  using the topology you have given in this email to describe PE2 verifying the state on PE1 using ingress replication and PE-1 and PE-3 using p2mp Ptree.

Paragj>There is an additional scenario for p2mp Ptree – to emulate traffic coming from the MH CE2,  PE-2 sends a echo request packet using P2MP Ptree to PE1 and PE-3. PE-2 will include EVPN Ethernet AD Sub-TLV in the echo request packet that will be received by both PE-3 and PE-1. PE-1 will reply using the same return code as  mentioned above (example#2). PE-3 in this case will reply with a different return code:

“Replying router is egress for the FEC at the stack depth as per RFC8029. In addition, the multicast packets are forwarded because there is no ES corresponding to the ESI received in EVPN Ethernet AD Sub-TLV”




[cid:image001.png@01D7E6C5.F1A22480]
Regards
Parag


Regards,
Sasha

Office: [phone]
Cell:      [phone]

Email:   [e-mail]

From: Parag Jain (paragj) <[e-mail]>
Sent: Friday, October 29, 2021 5:34 AM
To: Alexander Vainshtein <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: [EXTERNAL] Re: A question about draft-ietf-bess-evpn-lsp-ping
Importance: High

Hi Alexander,

Please see inline.


From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 26, 2021 at 11:51 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: A question about draft-ietf-bess-evpn-lsp-ping
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[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]>>, <[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]>>
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 RFC8029. 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: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>


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.