Jorge,
Lots of thanks for your response.
Please see some comments to your responses inline below.
Regards,
Sasha
From: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>
Sent: Thursday, May 4, 2023 3:39 AM
To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Wim Henderickx
(Nokia) <wim.henderi...@nokia.com>; 'John E Drake' <jdr...@juniper.net>; Wen
Lin <w...@juniper.net>; Ali Sajassi (sajassi) <saja...@cisco.com>
Cc: bess@ietf.org
Subject: [EXTERNAL] Re: Questions about Section 4.4.3 of RFC 9136
Hi Sasha,
I'm doing my best to answer your questions in-line below. Some others may want
to chime in too.
Thanks.
Jorge
From: Alexander Vainshtein
<alexander.vainsht...@rbbn.com<mailto:alexander.vainsht...@rbbn.com>>
Date: Sunday, April 30, 2023 at 4:04 AM
To: Jorge Rabadan (Nokia)
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Wim Henderickx
(Nokia) <wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>, 'John E
Drake' <jdr...@juniper.net<mailto:jdr...@juniper.net>>, Wen Lin
<w...@juniper.net<mailto:w...@juniper.net>>, Ali Sajassi (sajassi)
<saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: Questions about Section 4.4.3 of RFC 9136
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 all,
Adding one more item in Q2 of the original email...
Regards,
Sasha
From: Alexander Vainshtein
Sent: Sunday, April 30, 2023 10:52 AM
To: Rabadan, Jorge (Nokia - US/Mountain View)
<jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>;
wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>; 'John E Drake'
<jdr...@juniper.net<mailto:jdr...@juniper.net>>; Wen Lin
<w...@juniper.net<mailto:w...@juniper.net>>; Ali Sajassi (sajassi)
<saja...@cisco.com<mailto:saja...@cisco.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Questions about Section 4.4.3 of RFC 9136
Importance: High
Hi all,
I have a couple of question about Section 4.4.3 of RFC
9136<https://clicktime.symantec.com/15siFAGbNprHbhZ3At8JV?h=h9FlN1MttgnCaUgbweyTGHngXB9zrsasMRBQlsGAesY=&u=https://datatracker.ietf.org/doc/html/rfc9136%23section-4.4.3>.
This section discusses usage of EVPN IP Prefix (Type 5 routes) in the
Interface-ful IP-VRF-to-IP-VRF with Unnumbered SBD IRB scenario.
Q1: Is this scenario relevant for IP-VRFs that carry IPv6 customer traffic? To
the best of my understanding:
1. In this case the IRB that connects IP-VRFs in different NVEs/DGEs to
the SBD are IPv6-capable interfaces
2. As per Section 2.1 of RFC
4291<https://clicktime.symantec.com/15siKzTsqSXt1eNxiSXT7?h=vMYxCTxue7GkBRb8ICviR24o4qBo7bl2OZ-omBypsew=&u=https://www.rfc-editor.org/rfc/rfc4291.html%23section-2.1>
"All interfaces are required to have at least one Link-Local unicast address".
Specifically, each IRB MUST possess at least a unicast link-local IPv6 address
3. Link-local IPv6 addresses of the IRBs that connect IP-VRFs in
different NVEs and DGEs SHOULD be different, otherwise the IPv6 Duplicated
Address Detection check (see Section 5.4 of RFC 4862) would fail. If this
condition is met, the scenario defined in section 4.4.2 of RFC 9136 becomes
applicable.
[jorge] yes, the scenario is applicable too. You're right that IPv6-capable
IRBs have at least an LLA, but you may still use the model in 4.4.3 if you want
to use a MAC as an overlay index. Otherwise using the LLA as GW-IP overlay
index would be the model in 4.4.2.
[[Sasha]] Got, it, lots of thanks! At the same time, I wonder if there could be
any specific reason for the operator to prefer using MAC addresses as overlay
indices when link-local addresses of IPv6-capable IRBs addresses are in any
case available and can be used as overlay indices?
Q2: Does this scenario implicitly introduce unnumbered LAN interfaces in IPv4?
[jorge] it introduces concepts specific to EVPN IP-VRF-to-IP-VRF models, one of
them the SBD, which can have an unnumbered IRB.
[[Sasha]] IMHO and FWIW IRB as a LAN interface has been a well-understood
concept long before emergence of EVPN. Do you imply that an unnumbered IRB is
limited to EVPN IP-VRF-to-IP-VRF model with SBD?
1. Unnumbered IPv4 interfaces are discussed in multiple IETF standards
(RFC 1812, RFC 2328, RFC 5309 and more)
a. AFAIK, in all these documents unnumbered IPv4 interfaces are
restricted to be "point-to-point lines" (using the terminology of RFC 1812)
b. The IRBs that connect IP-VRFs in different NVEs/DGEs to the SBD are
unnumbered but obviously not point-to-point
[jorge] as per the above comment, RFC9136 is very specific to the use of EVPN
in IP-VRFs, the concepts here do not apply generically, but only to EVPN IP
Prefix routes.
2. Consider the network depicted in Figure 10 in the section in question
and suppose that the operator of this network wants to check IP connectivity
between IP-VRF in DGW1 and host IP1.
a. Can the operator ping IP1 from IP-VRF in DFW1?
b. If yes, then which source IP address would be used in the ping packets?
[jorge] in figure 10, BD1 is connected to the IP-VRF via IRB, which can have an
IP that can be used as source. If you refer to DGW1, then you can certainly use
any IP in the IP-VRF, for instance a loopback or the IP address of any other
interface different from the SBD IRB.
[[Sasha]] OK, got it.
3. Consider the network depicted in Figure 10 in the section in question
and suppose that a management system that uses the base RIB data model defined
in RFC
8439<https://clicktime.symantec.com/15siQpfAJ4DURbCtFzvbj?h=m6CJ1UDx01XEHJ2kZSrr8aH-BWllthc87crQXU5rUjM=&u=https://www.rfc-editor.org/rfc/rfc8349>
retrieves the RIB of the IP-VRF in DGW1 after EVPN IP Prefix routes to host
IP1 and to subnets SN1 and SN2 have been received and installed.
a. What will the management receive as the next hops and egress
interfaces of these routes?
b. Will these routes be perceived as labeled routes, and if yes, how
would the management system be able to differentiate between these routes and
routes received as VPNv4/VPNv6 routes?
[jorge] the IP Prefix route next-hops cannot be mapped to the next-hops in the
model you refer to.. section 4.4.2 and 4.4.3 of RFC9136 use recursive
resolutions to other routes.
[[Sasha]] The models described in Section 4.4.2, 4.1 and 4.2 use recursive
resolution but the routes installed in the RIB of the IP-VRF are mapped to the
standard RIB data model in a trivial way:
* The next hop is the GW IP address in the NRLI of the IP Prefix route from
which it is installed
* The egress interface is the local IRB
* ARP Cache of this IRB resolves the next hop address to MAC address based
on the received RT-2.
This is quite different from the models described in Sections 4.3 and 4.4.3
which indeed cannot be mapped to any standard RIB model I am aware of.
I wonder if you have considered providing the required extensions to these
models?
Your 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.
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
