Re-sending with a reduced list of addressees…
Regards,
Sasha
From: Alexander Vainshtein
Sent: Wednesday, March 29, 2023 11:30 AM
To: '[email protected]' <[email protected]>
Cc: Dmitry Valdman <[email protected]>; Nitsan Dolev
<[email protected]>; Michael Gorokhovsky <[email protected]>;
Ron Sdayoor <[email protected]>; Egon Haparnass <[email protected]>; Shell
Nakash <[email protected]>; Marina Fizgeer <[email protected]>; Orly
Kariv <[email protected]>; Moti Morgenstern <[email protected]>;
Rotem Cohen <[email protected]>;
'[email protected]'
<[email protected]>;
'[email protected]'
<[email protected]>
Subject: RE: Question and comments on the EVPN IP Aliasing draft
Importance: High
Hi all,
#3 issue in my original email seems to equally affect mass withdrawal of IP
Prefix routes in the Interface-less IP-VRF-to-IP-VRF scenario in general.
This scenario is mentioned in Section 3.1 of the EVPN Inter-Domain Option-B
Solution
draft<https://datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-00#section-3.1>.
My guess (FWIW) is an update of RFC 9136 is needed to address this issue.
Regards,
Sasha
From: Alexander Vainshtein
Sent: Monday, March 27, 2023 12:16 PM
To:
[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: Question and comments on the EVPN IP Aliasing draft
Hi all,
A few questions and comments on the EVPN IP Aliasing
draft<https://datatracker.ietf.org/doc/html/draft-sajassi-bess-evpn-ip-aliasing-06>:
1. 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:
a. 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.
b. 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.
2. 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”:
a. 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
i. 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://www.rfc-editor.org/rfc/rfc7432.html#section-14.1.1>)?
ii. 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
iii. 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.
3. 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:
a. Table 1 in RFC
9136<https://datatracker.ietf.org/doc/html/rfc9136#fields_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”.
b. 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.
c. Can you please explain how can, in this scenario, the receiving PE
associate received EVPN IP Prefix routes with a specific MH ES?
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._______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
