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> Date: Sunday, April 30, 2023 at 4:04 AM To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.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 <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>; 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: 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://datatracker.ietf.org/doc/html/rfc9136#section-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://www.rfc-editor.org/rfc/rfc4291.html#section-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. 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. 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. 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://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. 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.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
