Ali,
Again lots of thanks and more comments inline below.
Regards,
Sasha
From: Ali Sajassi (sajassi) <[email protected]>
Sent: Monday, November 28, 2022 7:52 PM
To: Alexander Vainshtein <[email protected]>
Cc: [email protected]; Alexander Ferdman <[email protected]>; Dmitry
Valdman <[email protected]>; Ron Sdayoor <[email protected]>; Nitsan
Dolev <[email protected]>; [email protected]
Subject: [EXTERNAL] Re: A question pertaining to validation of LSP Ping Echo
requests in draft-ietf-bess-evpn-lsp-ping-08
< sent the previous email by accident w/o completing my replies …>
Hi Sasha,
Thanks for your comments. Please refer to my replies marked with “AS>>”
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Wednesday, November 23, 2022 at 11:54 PM
To: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
Alexander Ferdman
<[email protected]<mailto:[email protected]>>, Dmitry Valdman
<[email protected]<mailto:[email protected]>>, Ron Sdayoor
<[email protected]<mailto:[email protected]>>, Nitsan Dolev
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Subject: RE: A question pertaining to validation of LSP Ping Echo requests in
draft-ietf-bess-evpn-lsp-ping-08
Hi Ali,
Lots of thanks for a prompt and very detailed response, and my sincere
apologies for a delayed response.
Please see a short comment to your response marked [[Sasha]] inline below.
Please note also that I have recently added yet another question to my list, I
am copying here it for your convenience:
RFC
8214<https://clicktime.symantec.com/15sLvRarab44zTHqki3B5?h=-pQqvRTWyDgbZBFNWxJKt61Yx1qwxuredpm7yjxg84g=&u=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?
AS>> EVIs are distinct and thus EVI for EVPN-VPWS is different from EVPN EVI.
So, the receiving PE when it receives an Echo request, it knows whether this
message is for EVPN-VPWS or EVPN based on EVI (represented by RD).
I see that the current version of the draft does not even mention RFC 8214.
AS>> EVPN-VPWS has multiple modes, and it may be better to cover it in a
separate draft. I will talk to Parag about a write-up of a short draft about
EVPN-VPWS and put a clarification statement that this draft is limited to EVPN
and EVPN-IRB.
[[Sasha]] Can you please clarify what limiting the current draft to just EVPN
and EVPN with IRB means.
Suppose that an egress PE that has advertised a per EVI EVPN Type 1 route with
a certain NLRI (RD, ESI, Ethernet Tag ID, Label) for an interface of an
EVPN-VPWS instance it contains receives an LP Ping Echo request with the EVPN
Ethernet A-D Sub-TLV in the Target FEC TLV that matches RD, ESI and Ethernet
Tag ID of this route and with the top label that matches the label in the
advertised route. Which return code should t use in its reply?
AS>> more comments below …
Regards, and lots of thanks in advance,
Sasha
From: Ali Sajassi (sajassi) <[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 22, 2022 2:15 AM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>; Alexander Ferdman
<[email protected]<mailto:[email protected]>>; Dmitry Valdman
<[email protected]<mailto:[email protected]>>; Ron Sdayoor
<[email protected]<mailto:[email protected]>>; Nitsan Dolev
<[email protected]<mailto:[email protected]>>
Subject: [EXTERNAL] Re: A question pertaining to validation of LSP Ping Echo
requests in draft-ietf-bess-evpn-lsp-ping-08
Hi Sasha,
Thanks for your comments. Please refer to my responses below marked with “AS>”
From: BESS <[email protected]<mailto:[email protected]>> on behalf of
Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Monday, November 14, 2022 at 1:36 AM
To:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
Alexander Ferdman
<[email protected]<mailto:[email protected]>>, Dmitry Valdman
<[email protected]<mailto:[email protected]>>, Ron Sdayoor
<[email protected]<mailto:[email protected]>>, Nitsan Dolev
<[email protected]<mailto:[email protected]>>
Subject: [bess] A question pertaining to validation of LSP Ping Echo requests
in draft-ietf-bess-evpn-lsp-ping-08
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://clicktime.symantec.com/15sLvRYetCY2KC1bwWUPA?h=-ckPg5zPj9JW8ZeCWk4IAlaBiELRKcWTwix5bTPwY0s=&u=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.
AS> The 2nd part of the above paragraph (2nd sentence onward) should be
modified as follow:
“ In EVPN, MAC/IP Advertisement has multiple personality and it is used for the
following cases:
1) This route with only MAC address and MPLS Label1 is used for populating
MAC-VRF and performing MAC forwarding.
2) This route with MAC and IP addresses and only MPLS Label1 is used for
populating both MAC-VRF and ARP/ND tables (for ARP suppression) as well as for
performing MAC forwarding
3) This route with MAC and IP addresses and both MPLS Label1 and Label2 is
used for populating MAC-VRF and IP-VRF tables as well as for both MAC
forwarding, and IP forwarding in case of symmetric IRB
When the remote PE receives MAC/IP Sub-TLV containing only MAC address, then
the remote PE validates the MAC state and forwarding. When the remote PE
receives MAC/IP Sub-TLV containing both MAC and IP addresses and if the EVPN
label points to a MAC-VRF, then it validates the MAC state and forwarding. If
the remote PE is not configured in symmetric IRB mode, then it validates ARP/ND
state as well.
[[Sasha]] I think that ARP/ND state should be validated even if the MAC-VRF is
configured with a Symmetric IRB, and the qualifier " If the remote PE is not
configured in symmetric IRB mode " is excessive.
AS>> When an EVPN is configured for symmetric IRB mode, then ARP/ND is
terminated locally and thus there is no need to verify it remotely (actually
you cannot verify it remotely!). However, for asymmetric IRB, ARP/ND is
processed remotely and thus should be verify it remotely. That’s why I have the
text the way I have written it.
[[Sasha]] Suppose that two PEs are attached to an All-Active MH ES, and both
are configured with a MAC-VRF attached to this MH ES and configured with a
Symmetric EVPN IRB with anycast IP and MAC address. Suppose further that one
(and it typically would be just one) of these PEs receives an P message with a
certain IP→MAC pair in its sender part and advertises this pair in an EVPN Type
2 route with Labl1 and Label2. What prevents the other PE from sending an LSP
Ping Echo request with the EVPN MACIP Sub-TLV in the Target FEC stack TLV and
with the label it has received in the Label1 field of the advertised route to
the PE that has advertised this route, and what, if anything, prevents it from
responding with return code 3 to such a request?
Cheers,
Ali
However, if the EVPN label points to an IP-VRF, then it validates IP state and
forwarding. Any other combinations, such as remote PE receiving MAC/IP Sub-TLV
containing only MAC address but with EVPN label pointing to an IP-VRF, should
be considered invalid and LSP Echo response should be sent with the appropriate
return code.
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?
AS> Baseline EVPN (RFC 7432) describes how a MAC address or <MAC, IP> pair is
synched up among multi-homing PEs. So, if PE1 (but not PE2) advertises M1 or
<M1, IP1>, PE2 will synch up with PE1 and programs M1 or (M1,IP1> in its tables
as if it has received M1 or <M1,IP1> via its local ESI. So, in your example,
when PE3 send lsp ping request to PE2 (either for M1 for <M1,IP1>), then PE2
can validate it even though PE2 never advertised M1 or <M1,IP1>. Of course,
this assumes aliasing is enabled. If aliasing is not enabled, then PE3 doesn’t
have the right MPLS label to send the LSP Ping request.
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?
AS> I believe the updated text should take care of this scenario.
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?
AS> The updated text should take care of this scenario. If you think no, then
tell us what part and we can elaborate further.
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?
AS> Again the updated text, should cover this scenario.
Cheers,
Ali
>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.
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
