Hi Jeffrey,
Thanks for reviewing.
Please see my comments in-line with [Jorge]. All those are addressed in version
08.
Thx
Jorge
From: Jeffrey (Zhaohui) Zhang
Date: Tuesday, September 26, 2023 at 1:55 PM
To: 'Ali Sajassi (sajassi)' , John E Drake
, Jorge Rabadan (Nokia)
Cc: 'BESS'
Subject: Questions on draft-sajassi-bess-evpn-ip-aliasing-07
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.
Hi,
To prepare for the adoption call, I read the draft and have some questions and
nit comments. If a point has been discussed before, a link to the email archive
is appreciated.
... If H1 is
locally learned only at one of the multi-homing PEs, PE1 or PE2, due
to LAG hashing, PE3 will not be able to build an IP ECMP list for the
H1 host route.
Perhaps remove the red text so that it is clear that "due to LAG hashing" is
for "H1 is locally learned only …" rather than for "PE3 will not be able to …".
[Jorge] ok, done.
For the following three subsections:
1.1. Ethernet Segments for Host Routes in Symmetric IRB
…
With Asymmetric IRB [RFC9135], …
1.2. Inter-subnet Forwarding for Prefix Routes in the Interface-less
IP-VRF-to-IP-VRF Model
In the Interface-less IP-VRF-to-IP-VRF model described in [RFC9136]
…
1.3. Ethernet Segments for Prefix routes in IP-VRF-to-IP-VRF use-cases
This document also enables fast convergence and aliasing/backup path
to be used even when the ESI is used exclusively as an L3 construct,
in an Interface-less IP-VRF-to-IP-VRF scenario [RFC9136].
Do we need to discuss the asymmetric model? It seems to be irrelevant.
[Jorge] in the asymmetric model, the remote nodes are attached to the same
broadcast domain as the multi-homing PEs. Hence, Aliasing/Backup functions are
fully defined in the existing specs and you are right, we don’t need to specify
new procedures. The asymmetric model would only be relevant for section 1.1,
and that’s why section 1.1 describes how the existing procedures provide a
solution for asymmetric IRB.
Both 1.2 and 1.3 mention “Interface-less IP-VRF-to-IP-VRF scenario” in RFC9136
though they are about different scenarios. Perhaps the section titles could be
more accurate – in fact, they could be more consistent with the a/b/c use cases
preceding 1.1. The following is a suggestion:
1.1. MAC/IP routes with symmetric IRB
1.2. IP Prefix routes with interface-less model
1.3. IP Prefix routes with ESI being a pure L3 construct
[Jorge] it’s a fair point, I modified the titles, inspired by you suggestion,
as follows:
“1.1. Multi-Homing for MAC/IP Advertisement Routes in Symmetric IRB
1.2. Multi-Homing for IP Prefix Routes in the Interface-less IP-VRF-to-IP-VRF
Model
1.3. Multi-Homing for IP Prefix routes with Layer 3 Ethernet Segments”
In 1.3.1:
In these use-cases, sometimes the CE supports a single BGP session to
one of the PEs (through which it advertises a number of IP Prefixes
seating behind itself) and yet, it is desired that remote PEs can
build an IP ECMP list or backup IP list including all the PEs multi-
homed to the same CE.
I initially wondered with how PE2 would know to forward traffic to the CE since
it does not learn the routes from the CE, until it came to me that PE1 will
re-advertise type-5 routes to every PE. I also see it is explicitly mentioned
in 4.2. It would be good to briefly mention it in 1.3.1 as well.
It’s also worth pointing out that both PE1 and PE2 can multi-path via each
other.
[Jorge] ok, I added the following. Let me know if it helps. The multi-path bit
across a local and a RT-5 is probably feasible if there are other CEs attached
to PE2, but I believe it would complicate the use case.
“This document provides a solution so that PE3 considers PE2 as a next-hop in
the IP ECMP list for CE1's prefixes, even if PE2 did not advertise the IP
Prefix routes for those prefixes in the first place. The solution uses an ESI
in the IP Prefix routes advertised from PE1 so that, when imported by PE2, PE2
installs the route as local, since PE2 is also attached to the Ethernet Segment
identified by the ESI.”
1.3.2 does not seem to be a different use case from 1.3.1. It can be viewed as
a special case of 1.3.1 – PEC’s attachment to the ES is down. Perhaps fold
1.3.2 into 1.3.1 as a special case?
[Jorge] that’s correct, I added the following text, let me know if it helps:
“There are two use cases analyzed and supported by this document:
IP Aliasing for EVPN IP Prefix routes
IP Aliasing in a Centralized Routing Model
Both use cases are resolved by the same procedures, and the scenario in Section
1.3.2 can be considered a special case of Section 1.3.1.”
For the following:
4.1.2. IP A-D per ES route and SRv6 Transport
When an SRv6 transport is used, each IP A-D per ES route MUST carry
an SRv6 L3 Service TLV within the BGP Prefix-SID attribute [RFC9252].