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

["Bocci, Matthew (Nokia - GB)" <[e-mail]>]

Authors

I will hold off requesting publication until these questions have been addressed.

Regards

Matthew

From: Alexander Vainshtein <[e-mail]>
Date: Monday, 22 November 2021 at 20:57
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,
Sure.
Will be waiting for your response.

Regards,
Sasha

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Parag Jain (paragj) <[e-mail]>
Sent: Monday, November 22, 2021 9:45:33 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [EXTERNAL] Re: A question about draft-ietf-bess-evpn-lsp-ping


Hi Sacha



Missed your earlier email.



Thanks for following up. Let me get back to you.



Thanks

Parag



From: Alexander Vainshtein <[e-mail]>
Date: Monday, November 22, 2021 at 11:18 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 and all,

A gentle reminder...



Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]



From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:44 PM
To: Parag Jain (paragj) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: RE: A question about draft-ietf-bess-evpn-lsp-ping



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://clicktime.symantec.com/3U5Do9J5RhHhTjqohayWqmm6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-bess-evpn-lsp-ping%23section-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?

  1.  Section 8.2 of RFC 7432<https://clicktime.symantec.com/33h88cTkC5PZgUrjaDS4vS46H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7432%23section-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: [phone]

Cell:      [phone]

Email:   [e-mail]<mailto:[e-mail]>



From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:03 PM
To: Parag Jain (paragj) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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: [phone]

Cell:      [phone]

Email:   [e-mail]<mailto:[e-mail]>



From: Parag Jain (paragj) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, October 29, 2021 5:34 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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 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: [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.

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.