Hi Sasha,
Let me try to reply to your questions:
How can a PE that receives an EVPN Type 1 route decide whether it is a per-EVI
Ethernet A-D route or a per-EVI IP A-D route?
[jorge] The IP A-D per EVI route carries a route target of an IP-VRF.
1. “The draft defines, without going into details, quite a different
procedure for recursive resolution of such routes that uses per EVI IP A-D
routes introduced in the draft. This procedure inherently assumes that
inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e.,
without inner L2 encapsulation).
My question is: How can the PE that receives an EVPN IP Prefix routes with a
non-reserved ESI value decide which of these two procedures it should apply to
each specific route?”
[jorge] As discussed, for IP Prefix routes, the draft extends RFC9136 section
4.4.1 (we added some text about it) to support the resolution of IP Prefix
routes to IP A-D routes.
* RFC9136 section 4.4.1 supports both Ethernet NVO tunnels and IP NVO
tunnels (see the terminology section in RFC9136). That is, both inner L2 or L3
encapsulation.
* If an implementation receives an IP Prefix route with a non-reserved ESI
value that is imported in an IP-VRF, the procedures in the draft are followed,
irrespective of whether the PEs use Ethernet NVO or IP NVO tunnels. The route
resolution is described in 5.3.1.
* By the way, the recursive resolution is compatible with RFC9136. See
table 1, first two top rows:
+==========+==========+==========+============+===============+
| ESI | GW IP | MAC* | Label | Overlay Index |
+==========+==========+==========+============+===============+
| Non-Zero | Zero | Zero | Don't Care | ESI |
+----------+----------+----------+------------+---------------+
| Non-Zero | Zero | Non-Zero | Don't Care | ESI |
+----------+----------+----------+------------+---------------+
Let me know if it helps.
Thanks.
Jorge
From: Alexander Vainshtein <[email protected]>
Date: Sunday, July 9, 2023 at 9:54 AM
To: Jorge Rabadan (Nokia) <[email protected]>
Cc: [email protected] <[email protected]>,
[email protected]
<[email protected]>
Subject: Re: RE: Question and comments on the EVPN IP Aliasing draft
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Jorge and all,
More of the same:
How can a PE that receives an EVPN Type 1 route decide whether it is a per-EVI
Ethernet A-D route or a per-EVI IP A-D route?
My 2c,
Sasha
Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Alexander Vainshtein <[email protected]>
Sent: Sunday, July 9, 2023 12:57:00 PM
To: Jorge Rabadan (Nokia) <[email protected]>
Cc: [email protected] <[email protected]>;
[email protected]
<[email protected]>
Subject: RE: Question and comments on the EVPN IP Aliasing draft
Jorge,
Lots of thanks for the new revision, it addresses the majority of my comments.
I still have some doubts about co-existence of the “old” (as in RFC 9136
Section 4.4.1) and “new” interface-less IP-VRF-to-IP-VRF models.
Specifically:
1. Section 4.3 of RFC 9136 provides a detailed procedure for recursive
resolution of received EVPN IP Prefix routes with a non-reserved ESI value in
their NLRI. To the best of my understanding, this procedure inherently assumes
that inter-subnet traffic is carried between the PEs as EVPN traffic (i.e.,
with inner L2 encapsulation). This procedure uses the Router MAC Extended
Community, or, in the case of its absence, a local policy for determination of
the Destination MAC address in the inner L2 encapsulation/
2. The draft defines, without going into details, quite a different
procedure for recursive resolution of such routes that uses per EVI IP A-D
routes introduced in the draft. This procedure inherently assumes that
inter-subnet traffic is carried between the PEs as IP-VPN traffic (i.e.,
without inner L2 encapsulation).
My question is: How can the PE that receives an EVPN IP Prefix routes with a
non-reserved ESI value decide which of these two procedures it should apply to
each specific route?
I think that the draft should provide an unambiguous answer to this question.
Regards,
Sasha
From: Jorge Rabadan (Nokia) <[email protected]>
Sent: Thursday, July 6, 2023 9:23 PM
To: Alexander Vainshtein <[email protected]>;
[email protected]
Cc: [email protected]
Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft
Sasha,
We just published version 07 of the EVPN IP Aliasing draft, and tried to
address your comments in this thread. Let us know if you have further comments.
Thank you!
Jorge
From: Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>
Date: Tuesday, April 4, 2023 at 5:09 PM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: Re: Question and comments on the EVPN IP Aliasing draft
Hi Sasha,
I can work on some clarifications in the text based on your feedback.
About whether the draft updates RFC9136, I’m hesitant to add it to the header,
since this spec is obviously optional.
Thanks.
Jorge
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Monday, April 3, 2023 at 5:51 AM
To: Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Subject: RE: Question and comments on the EVPN IP Aliasing draft
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See
https://clicktime.symantec.com/15siFAdRxjC6ZR12VsdcD?h=9dKjeFiIGxpBYd94GifyAUHFA2O22JVj1NliypFJLQk=&u=http://nok.it/ext
for additional information.
Hi Jorge,
Lots of thanks for a prompt response.
I have explained my position with regard to IP Aliasing for RT-5 in
Interface-less IP-VRF-to-IP-VRF model in my previous email.
I only can add that the neither the metadata of the IP Aliasing draft nor its
text specify an update to RFC 9136.
Regards,
Sasha
From: Jorge Rabadan (Nokia)
<[email protected]<mailto:[email protected]>>
Sent: Monday, April 3, 2023 4:17 AM
To: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>; Dmitry Valdman
<[email protected]<mailto:[email protected]>>; Nitsan Dolev
<[email protected]<mailto:[email protected]>>; Michael Gorokhovsky
<[email protected]<mailto:[email protected]>>; Ron
Sdayoor <[email protected]<mailto:[email protected]>>; Egon Haparnass
<[email protected]<mailto:[email protected]>>; Shell Nakash
<[email protected]<mailto:[email protected]>>; Marina Fizgeer
<[email protected]<mailto:[email protected]>>; Orly Kariv
<[email protected]<mailto:[email protected]>>; Moti Morgenstern
<[email protected]<mailto:[email protected]>>; Rotem Cohen
<[email protected]<mailto:[email protected]>>
Subject: [EXTERNAL] Re: Question and comments on the EVPN IP Aliasing draft
Hi Sasha,
Please see in-line with [jorge].
Thanks for the good questions/points.
Jorge
From: Alexander Vainshtein
<[email protected]<mailto:[email protected]>>
Date: Sunday, March 26, 2023 at 11:16 PM
To:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>,
Dmitry Valdman <[email protected]<mailto:[email protected]>>,
Nitsan Dolev <[email protected]<mailto:[email protected]>>, Michael
Gorokhovsky
<[email protected]<mailto:[email protected]>>, Ron
Sdayoor <[email protected]<mailto:[email protected]>>, Egon Haparnass
<[email protected]<mailto:[email protected]>>, Shell Nakash
<[email protected]<mailto:[email protected]>>, Marina Fizgeer
<[email protected]<mailto:[email protected]>>, Orly Kariv
<[email protected]<mailto:[email protected]>>, Moti Morgenstern
<[email protected]<mailto:[email protected]>>, Rotem Cohen
<[email protected]<mailto:[email protected]>>
Subject: Question and comments on the EVPN IP Aliasing draft
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See
https://clicktime.symantec.com/15t5Zsu7ZPvvXHNzW589B?h=3ceHKr8YVLM3UOko-NyIuMmvVO2HwRp1fi1RLBdLkNo=&u=http://nok.it/ext
for additional information.
Hi all,
A few questions and comments on the EVPN IP Aliasing
draft<https://clicktime.symantec.com/15t5ei6Q21cWwECv3dXHo?h=hLCOzcf5t8oR3LIGwDra1wBHCN4UcxyL3SN_N-D7vPY=&u=https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-06>:
Section 3 of the draft states that a PE that is attached to a MH ES shall
advertise a set of IP per ES A-D routes, and Section 4.1 says that these routes
shall be tagged with Export RTs of all IP-VRFs attached to this MH ES. The
following is not mentioned:
Should the ESI Label Extended Community be attached to these routes? My guess
(FWIW) is that this is necessary, since this is the only way to let the remote
PEs to know the MH mode of the MH ES in question.
[jorge] correct
Assuming an affirmative answer to the previous question, what should the ESI
Label Extended Community attached to these routes carry in its Label field? My
guess (FWIW) is that his field is not relevant and should be set to all zeroes.
[jorge] yes. We can add a sentence to that respect. The label field SHOULD be
set to 0 and MUST be ignored on reception.
Section 3 of the draft says that “a remote PE that receives an EVPN MAC/IP
Advertisement route or an IP Prefix route with a non-reserved ESI and the RT of
a particular IP-VRF SHOULD consider it reachable by every PE that has
advertised an IP A-D per ES and IP A-D per EVI route for that ESI and IP-VRF”:
Is the statement above applicable in the case of a MH ES in Single-Active MH
Mode? My guess is that it is only applicable to MH Es in All-Active MH mode
[jorge] same as in rfc7432bis, both modes
If the answer to the previous question is negative, should the PE that receives
an EVPN Type 2 route for an IP→MAC pair treat the IP address in this pair
reachable only via he PE that has advertised this route and treating other PEs
as “backup PEs” (similar to what is defined in Section 14.1.1 of RFC
7432<https://clicktime.symantec.com/15t5pNUxwEyhm7rm8kKb3?h=m9ESlNFEXlL5s4xyn-g6bmr0dWvx9li2FHAjKrC16c0=&u=https://www.rfc-editor.org/rfc/rfc7432.html%23section-14.1.1>)?
[jorge] yes, assuming that PE the has received the AD routes.
The suggestion to attach the Layer 2 Attributes Extended Community to the per
EVI IP A-D route in Section 3.1 of the draft seems to support my guesses above
I also think that if the MH ES in Single-Active mode is attached o more than 2
PEs, the Layer 2 Attributes Extended Community MUST be attached to EVPN per EVI
IP A-D routes.
[jorge] at the moment the addition of the L2 Attr ext community is a SHOULD. I
have no problem in making it a MUST assuming my co-authors are ok.
I have to admit that I do not understand how IP Aliasing should work for EVPN
IP Prefix routes in the Interface-less IP-VRF-to-IP-VRF scenario mentioned in
Section 1.2 of he draft:
Table 1 in RFC
9136<https://clicktime.symantec.com/15t5jYHgUdJ7MB2qbBvSR?h=3pwOHmxhy4P_vmCrfN-Bzd29Fz_PC1o-KGYWe1eTTfY=&u=https://datatracker.ietf.org/doc/html/rfc9136%23fields_overlay_table>
states that a non-zero ESI value in the NLRI of IP Prefix routes is used as an
Overlay index for recursive resolution, while that the Label value in such a
NLRI is “Don’t Care”.
At the same time, section 4.1.1 of this RFC states that the ESI field of the
NLRI f these routes is set to all zeroes in the Interface-less IP-VRF-to-IP-VRF
scenario while the Label field in the NRLI of these routes identifies the IP
VRF in question.
Can you please explain how can, in this scenario, the receiving PE associate
received EVPN IP Prefix routes with a specific MH ES?
[jorge] section 1.2 illustrates an RFC9136 interface-less model since there is
no SBD. However, this draft modifies the interface-less model by using non-zero
ESI on the IP Prefix routes and a recursive resolution to A-D per ES/EVI routes.
Your timely feedback would be highly appreciated.
Regards, and lots of hanks 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.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
