Re: [bess] A minor contradiction between RFC 9135 and RFC 9136?

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

Hi Sasha,

In your case, the route type 5 would use the RD of the IP-VRF. I don’t think any implementation would do anything different.

RFC9136 says the RD has to be used in the same way it is defined in RFC7432, but the text refers to the recommendation of using a type 1 RD and its uniqueness, in fact the spec says that you take the RD from a mac-vrf or an ip-vrf. This could have been explicitly written, but I don’t think it creates any interop issue at all. We’ve been testing this across vendors for quite some time now, and I don’t see issues.

RFC9136 allows using the RD of a mac-vrf in a few cases where the there is no ip-vrf and a route type 5 is generated, but in the ip-vrf-to-ip-vrf cases you would use the RD of the IP-VRF.

My 2 cents.

Thanks.
Jorge

From: Alexander Vainshtein <[e-mail]>
Date: Sunday, December 10, 2023 at 2:39 AM
To: Jorge Rabadan (Nokia) <[e-mail]>, Wim Henderickx (Nokia) <[e-mail]>, Ali Sajassi (sajassi) <sajassi=[e-mail]>, John E Drake <jdrake=[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: A minor contradiction between RFC 9135 and 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,
A gentle reminder…

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, November 19, 2023 2:22 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>; [e-mail]; Ali Sajassi (sajassi) <sajassi=[e-mail]>; John E Drake <jdrake=[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: FW: A minor contradiction between RFC 9135 and RFC 9136?

Hi all,
The email expansions for the authors of RFC 9135 and RFC 9136 do not work anymore.
Therefore, I forward my email to you individually.

Regards,
Sasha

From: Alexander Vainshtein
Sent: Sunday, November 19, 2023 2:08 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: A minor contradiction between RFC 9135 and RFC 9136?
Importance: High

Hi all,
I see what looks to me as a contradiction between Section 9.1.1 of RFC 9315<https://datatracker.ietf.org/doc/html/rfc9135#section-9.1.1> and Section 4.4.1 of RFC 9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.1>:


The former:

Defines a Symmetric IRB as an interface connecting an IP-VRF to an EVPN Broadcast Domain (a MAC-VRF or a specific BBD within a MAC-VRF that implements VLAN-Aware service interface)

Describes an IP Prefix (EVPN Type 5, a.k.a. RT-5) route advertised for the subnet of a Symmetric EVPN IRB and states that RD in the NLRI of this route is the RD of IP-VRF that contains that the IRB in question

The latter describes the Interface-less IP-VRF to IP-VRF model:

To the best of my understanding, this model deals with just Symmetric IRBs

The RFC states that the NVE/DGW will, for each of its prefixes, advertise an RT-5 with RD in its NLRI as defined in RFC 7432<https://www.rfc-editor.org/rfc/rfc7432.html>. Since RFC 7432 does not refer to IP-VRFs at all, this strongly suggests to me that it means RD of a MAC-VRF .

The following diagram shows why this difference may be meaningful:

[cid:image001.png@01DA2B65.E342FB80]
In this diagram PE-1, PE-2 and PE-3 can only exchange L2VPN/EVPN routes but not VPN-IP routes.
Suppose that IP-VRF in PE-1 and PE-2 are configured with a static route to SN-. In this case:

PE-1 and PE-2 can advertise RT-5 for SN-1 using either RDs of IP-VRFs or RDs of MAC-VRF

If RT-5 uses RDs of containing IP-VRF, bi-directional connectivity between devices in SN-1 and SN-2 can be established

If RT-5 uses RDs of MAC-VRF in its NLRI, PE-3 cannot advertise RT-5 for SN-2 because there is no MAC-VRF in this PE.


What, if anything,  do I miss?

Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha



Disclaimer

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.