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

[Alexander Vainshtein <[e-mail]>]

Parag,
Lots of thanks for your response.

The updates to the draft that you have suggested (in this and previous emails) look good to me

However, I am not sure your response to my last question really addresses it – please see inline below.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]

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

Hi Sacha,

Thanks for the thorough review of the draft and your comments  and questions. Please see inline.


From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Monday, November 22, 2021 at 11:18 AM
To: "Parag Jain (paragj)" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>

From: Alexander Vainshtein
Sent: Sunday, October 31, 2021 12:44 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

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/3BF2Yofw2ibCfgs5o9Ggk7Q7GS?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

Paragj> yes, this is right. Will update the draft to clarify.


  1.  There no references to the EVPN AD sub-TLV in the draft. Instead, there are two references to the Ethernet AD sub-TLV

Paragj> thanks for pointing this out. Will update the draft to replace all references to Ethernet AD sub-TLV  with EVPN 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?

Paragj> yes, that’s right. Will update the draft to clarify.


     *   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?
Paragj> yes, that’s right. Will update the draft to clarify.


  1.  Section 8.2 of RFC 7432<https://clicktime.symantec.com/3FvUcdCR8RT35G7PAjqTsyr7GS?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?

Paragj> The RD value should correspond to the RD received for the EVI in the per-ES EVPN Type-1 route. Will update the draft to clarify.
[[Sasha]] A per-ES EVPN Type 1 route is advertised with (export) RTs of all the EVI that are  attached to it, and multiple such routes for the same MH ES are advertised with different RD values in the NLRI if the list of RTs is too long to fit into a single BGP Update. Since normally:

  *   the same set of EVI would be attached to a given MH ES in all the PEs that are attached to this MH ES, AND
  *   each EVI would use the same set of RTs as both import and export
a PE that is attached to the same MH ES would receive ALL per-ES EVPN Type 1 routes that have been advertised by another PE attached to the same MH ES – with different RD values the list did not fit in a single Update message..
Which of these RDs should be used?

Thanks
Parag

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 “


  1.  code 3 - "Replying router is an egress for the FEC at stack-depth" as per RFC8209
  2.  Replying router is egress for the FEC at the stack depth as per rfc 8029. In addition, the multicast packets are dropped on the ES corresponding to the SHG Label because of the Split Horizon filtering”.


  1.  Replying router is egress for the FEC at the stack depth as per rfc 8029. In addition, the multicast packets are forwarded because there is no ES corresponding to the SHG label”

1,2 for ingress replication
2,3 for p2mp

Replying router ios egress of Fec exist on the PE and the behavior is to forward the packet as there is no ES corresponding to the SHG label

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.