Re: [bess] Questions about Section 4.4.3 of RFC 9136

["Jorge Rabadan (Nokia)" <[e-mail]>]

Hi Sasha,

No disagreement - if you identified a gap in that YANG model, it might be good to address it if people need it.

Thanks.
Jorge

From: Alexander Vainshtein <[e-mail]>
Date: Tuesday, May 9, 2023 at 5:50 PM
To: Jorge Rabadan (Nokia) <[e-mail]>
Cc: [e-mail] <[e-mail]>, Wim Henderickx (Nokia) <[e-mail]>, 'John E Drake' <[e-mail]>, Wen Lin <[e-mail]>, Ali Sajassi (sajassi) <[e-mail]>
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.


Jorge,
Again lots of thanks for a prompt and very useful response.

With regard to mapping routes that are installed in the VRF RIB following recursive resolution of EVPN Type-5 routes:

I consider bringing this issue to the attention of the RTGWG and the authors of the RIB Extension YANG Data Model draft<https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-yang-rib-extend-18>.

What do you think?

Regards,
Sasha

From: Jorge Rabadan (Nokia) <[e-mail]>
Sent: Monday, May 8, 2023 3:48 PM
To: Alexander Vainshtein <[e-mail]>
Cc: [e-mail]; Wim Henderickx (Nokia) <[e-mail]>; 'John E Drake' <[e-mail]>; Wen Lin <[e-mail]>; Ali Sajassi (sajassi) <[e-mail]>
Subject: [EXTERNAL] Re: Questions about Section 4.4.3 of RFC 9136

Hi Sasha,

Please see in-line.
Thanks.
Jorge

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Sunday, May 7, 2023 at 9:00 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Wim Henderickx (Nokia) <[e-mail]<mailto:[e-mail]>>, 'John E Drake' <[e-mail]<mailto:[e-mail]>>, Wen Lin <[e-mail]<mailto:[e-mail]>>, Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
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.


Jorge,
Lots of thanks for your response.
Please see some comments to your responses inline below.



Regards,
Sasha

From: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, May 4, 2023 3:39 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; Wim Henderickx (Nokia) <[e-mail]<mailto:[e-mail]>>; 'John E Drake' <[e-mail]<mailto:[e-mail]>>; Wen Lin <[e-mail]<mailto:[e-mail]>>; Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Date: Sunday, April 30, 2023 at 4:04 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, Wim Henderickx (Nokia) <[e-mail]<mailto:[e-mail]>>, 'John E Drake' <[e-mail]<mailto:[e-mail]>>, Wen Lin <[e-mail]<mailto:[e-mail]>>, Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; 'John E Drake' <[e-mail]<mailto:[e-mail]>>; Wen Lin <[e-mail]<mailto:[e-mail]>>; Ali Sajassi (sajassi) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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?
[jorge2] for instance, if ipv4 and ipv6 prefixes are exchanged via IP Prefix routes and you want to use a single mechanism without configuring any ip address on the SBD IRB.

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?
[jorge2] not implying anything, just saying that the procedures described in this document are in the context of EVPN.


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?
[jorge2] not really, I had never seen a requirement for it.



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.

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.