Hi all,
I would like to add one more question (#5 - highlighted) to the previous list.
Your timely feedback would be highly appreciated.
Regards, and lots of thanks in advance,
Sasha
From: Alexander Vainshtein
Sent: Monday, November 14, 2022 11:36 AM
To: [email protected]
Cc: [email protected]; Alexander Ferdman <[email protected]>; Dmitry
Valdman <[email protected]>; Ron Sdayoor <[email protected]>; Nitsan
Dolev <[email protected]>
Subject: A question pertaining to validation of LSP Ping Echo requests in
draft-ietf-bess-evpn-lsp-ping-08
Importance: High
Hi all,
My colleagues and I have a question about the validation rules for LSP Ping
Echo Requests associated with EVPN Type 2 routes in
draft-ietf-bess-evpn-lsp-ping-08<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-lsp-ping-08>.
The problematic text in Section 4.1 of the draft says:
The LSP Echo Request is sent using the EVPN MPLS label(s) associated
with the MAC/IP Advertisement route announced by a remote PE and the
MPLS transport label(s) to reach the remote PE. When remote PE
processes the received LSP Echo Request packet, the remote PE
validates the MAC state if the MAC/IP Sub-TLV contains only MAC
address. If the MAC/IP Sub-TLV contains both MAC and IP address, the
PE validates the ARP/ND state.
Here are our questions:
1. Suppose that some MAC address:
a. Has been learned by the intended egress PE from the Data Plane from an
All-Active MH ES and advertised in a MAC-only route EVPN Type 2 route
b. An EVPN Type 2 route for some IP→MAC pair with the same MAC address
has been advertised by another PE attached to the same All-Active MH ES
c. An LSP Ping Echo request with the IP→MAC pair in question and the
label that has been advertised by the intended egress PE in the Label1 field of
an EVPN Type 2 route for the MAC address in question is received
What is the expected result of the validation taking into account that the
egress PE has not ever advertised an EVPN Type 2 route for the IP→MAC pair in
question?
2. Suppose that:
a. Some MAC address as been learned by the egress PE only via the control
plane (ARP/ND) and advertised In an EVPN Type 2 route for an IP→MAC pair
b. A MAC-only LSP Ping request for the MAC address in question with the
label advertised in the Label1 field of the EVPN Type 2 route for an IP→MAC
pair in question has been received
What is the expected result of the validation taking into account that the
egress PE has not advertised any MAC-only routes for the MAC address in
question?
3. Suppose that:
a. We are dealing with a BD that is used by a Symmetric EVPN IRB
b. Some MAC address as been learned by the egress PE only via the control
plane (ARP/ND) and has been advertised In an EVPN Type 2 route for an IP→MAC
pair with Label2 field present
c. A MAC-only LSP Ping request for the MAC address in question with the
label advertised in the Label2field of the EVPN Type 2 route for an IP→MAC pair
in question has been received
What is the expected result of the validation?
4. Same as #3 above, but the LSP Ping request is for the IP→MAC pair in
question and with the label advertised in the Label2 field of the EVPN Type 2
route for an IP→MAC pair in question?
1. RFC 8214<https://tools.ietf.org/html/rfc8214> defines usage of per EVI
EVPN A-D (Type 1) routes in EVPN-VPWS in addition to their usage for
aliasing/backup path defined in RFC 7432. Suppose that the operator tries to
perform a connectivity check to the aliasing function of some EVI but the PE
that receives an LSP Ping Echo request with the EVPN Ethernet AD sub-TLV in the
target label stack and label has advertised this FEC and label for a specific
Attachment Circuit of an EVPN-VPWS instance. Is there any way it can indicate
in the Echo Reply message that the label matches the target FEC but this FEC
and label are used for EVPN-VPWS and not for aliasing?
>From my POV the simplest way to answer all these questions would be to say
>that the information and the label in the LSP Ping Echo request should be
>validated vs. the set of EVPN Type 2 routes advertised by the egress PE and
>succeed (yielding return code 3) only in the case of an exact match. Scenarios
>described in #1, #2 and #3 above could be treated as partial matches and
>yielding some new return codes while scenario 4 would be treated as success.
Your timely feedback would be highly appreciated.
Regards, and lots of thanks in advance,
Sasha
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
