Re: [bess] [EXTERNAL] Re: [nvo3] Problematic text in RFC 9469

[Alexander Vainshtein <[e-mail]>]

Aldrin,
Lots of thanks for your email and apologies for a delayed response.

From my POV neither 9135 nor 9136 say anything about “access-facing” vs. “core-facing” IRB.

And in any case Section 4.4.2 of 9136 deals with both “core-facing” IRBs that connect IP-VRFs to the SBD and “access-facing” IRBs that connect the same IP-VRF to a BD with “regular” Attachment Circuits as shown in the copied diagram below.

                 NVE1
        +------------+                       DGW1
IP10+---+(BD-1)      | +---------------+ +------------+
        |  \         | |               | |            |
        |(IP-VRF)-(SBD)|               |(SBD)-(IP-VRF)|-----+
        |  /    IRB(M1/IP1)           IRB(M3/IP3)     |     |
    +---+(BD-2)      | |               | +------------+    _+_
    |   +------------+ |               |                  (   )
SN1|                  |     VXLAN/    |                 ( WAN )--H1
    |            NVE2  |     GENEVE/   |                  (___)
    |   +------------+ |     MPLS      |     DGW2           +
    +---+(BD-2)      | |               | +------------+     |
        |  \         | |               | |            |     |
        |(IP-VRF)-(SBD)|               |(SBD)-(IP-VRF)|-----+
        |  /    IRB(M2/IP2)           IRB(M4/IP4)     |
SN2+----+(BD-3)      | +---------------+ +------------+
        +------------+

As explained in my original email, the IRBs that connect IP-VRFs to SBD look as Asymmetric IRBs to me, while IRBs that connect IP-VRF “normal” BDs may be either Symmetric or Asymmetric.
In the former case, traffic to IP10 would cross the core as IP-VPN traffic based on RT-2 advertised for the IP --> MAC pair learned by BD-1 in NVE1, while in the latter case RT-5 advertised by NVE1 for the subnet of the IRB that connects IP-VRF to BD-1 with the IP1 as the GW IP address of this route, and RT-2 for the IP1 --> M1 pair associated with the SBD IRB would be used to send this traffic in EVPN encapsulation.

Hope this clarifies my question.

Regards,
Sasha

From: Aldrin Isaac <[e-mail]>
Sent: Wednesday, December 27, 2023 11:59 PM
To: Alexander Vainshtein <[e-mail]>
Cc: Jorge Rabadan (Nokia) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: [EXTERNAL] Re: [nvo3] Problematic text in RFC 9469

Maybe the distinction here is that RFC9135 describes access facing functions and RFC9136 describes core facing?

On Sun, Dec 24, 2023 at 12:41 AM Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:
Jorge,
Again, Lots of thanks for your email!

I have looked up Section 4.4 of RFC 9136 and I have noticed (missed this point before☹) that it indeed defines all IP-VRF-to-IP-VRF use cases as Symmetric.

At the same time, Section 4.4.2 of RFC 9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.2> describes advertisement of RT-5 and RT-2 for the SBD IRB and their installation as following:


1.       RT-5 for the tenant’s subnet is advertised with Route Target that identifies the tenant (IP-VRF)

2.       RT-2 for the IP-MAC pair of the SBD IRB is advertised with the Route Target that identifies SBD

a.       The text clarifies that this Route Target may be the same as the Route Target used in RT-5

b.       Label2 field of this route is not mentioned

This is in direct contradiction with Section 5.1 of RFC 9135 that says that RT-2 associated with a Symmetric IRB

1.   The MPLS Label2 field of this route MUST be set to a value that identifies IP-VRF

2.   “MUST be advertised with two Route Targets, one corresponding to the MAC-VRF of the tenant's subnet and another corresponding to the tenant's IP-VRF”.

To me this means that SBD IRBs are Asymmetric. What, if anything do I miss?

Regards, and best holiday wishes,
Sasha

From: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, December 22, 2023 9:19 PM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: Problematic text in RFC 9469

Hi Sasha,

I realized I never replied to your email.

My first comment is that this document was an ask from the NVO3 WG, as one of the pending points in the charter. It is mostly addressing the NVO3 audience, rather than being a generic primer (it is mostly focused on NVO3 networks and leaves many other aspects out). Thanks for the feedback though!

About whether the SBD follows the asymmetric IRB model, I still disagree, sorry about that 😊

The authority in the definition of symmetric vs asymmetric is RFC9135, and the lookup sequence explained in RFC9135 for asymmetric does not match what the section 4.4.2 says.
Furthermore, RFC9136 provides its summary of the symmetric vs asymmetric IRB model, and declares the entire section 4.4 as a symmetric model from the perspective of the lookups required.

Hope it helps.

Thanks!
Jorge

From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, October 24, 2023 at 1:22 AM
To: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Problematic text in RFC 9469

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information.


Jorge,
Lots of thanks for your response.

I think that RFC 9469 is very important (in spite of being purely Informational), because it provides a very good ”EVPN primer”.
Personally, I would highly recommend it as mandatory reading for the “EVPN beginners”. Of course, this is my personal understanding, I do not know whether this was one of your objectives in writing it.

This is also why I am worried about minor inaccuracies in the text – from my POV the beginners should be given an accurate view on the technology from Day 1.
In particular, based on my personal experience (an I have to do lots of EVPN-related mentoring in my organization)  I assure you that EVPN beginners quite frequently think that the term “Ethernet Segment” refers just to multi-homed ES☹; part of my job is to convince them that they are mistaken.

Regarding your statement on SBD:

I agree that Section 4.4.2 of RFC 9136<https://datatracker.ietf.org/doc/html/rfc9136#section-4.4.2> does not mention specifically Symmetric or Asymmetric IRBs.

However, the quoted text from this section (below) de-facto implies Asymmetric IRBs connecting each IP-VRF to the SBD (the relevant fragments are highlighted):


NVE1 advertises the following BGP routes:

Route type 5 (IP Prefix route) containing:

IPL = 24, IP = SN1, Label = SHOULD be set to 0.

GW IP = IP1 (SBD IRB's IP).

Route Target identifying the tenant (IP-VRF).

Route type 2 (MAC/IP Advertisement route for the SBD IRB) containing:

ML = 48, M = M1, IPL = 32, IP = IP1, Label = 10.

A BGP Encapsulation Extended Community [RFC9012<https://datatracker.ietf.org/doc/html/rfc9012>].

Route Target identifying the SBD. This Route Target may be the same as the one used with the RT-5.
If the IRB in question were Symmetric, Route type 2, in accordance with Section 5.1 of RFC 9135<https://datatracker.ietf.org/doc/html/rfc9135#section-5.1>, would include the Label2 field identifying local IP-VRF and would also carry Route Target(s) identifying IP-VRF. None of these are mentioned.

Of course, this is just an example. But:

•       Section 4.4.2 of RFC 9136 in its description of the SBD model states: “However, the NVE/DGWs are now connected through Ethernet NVO tunnels terminated in the SBD instance”,

•       Section 4. of RFC 9469<https://datatracker.ietf.org/doc/html/rfc9469#section-4.3> says “In the Symmetric model, the inter-subnet connectivity between NVEs is done based on tunnels between the IP-VRFs”.

This brings me to a conclusion that SBD is intended to be used with Asymmetric IRBs. What, if anything, did I miss?

Regards,
Sasha

From: Jorge Rabadan (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 24, 2023 3:23 AM
To: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: Problematic text in RFC 9469

Hi Sasha,

Thanks for reading it!
As a co-author and editor of the RFC, in my humble opinion those points do not deserve to file an errata.

The RFC is purely informational and only focuses on describing how the existing specs can be applied to NVO3 networks, without specifying any new procedures or changes in the definition of those terms.


For the ES, while I see your point, I don’t think this term in the glossary section will confuse the reader about what an ES is.

IP-VRF – again I don’t think it is confusing the reader, given that it is such a common term.

SBD – I don’t agree with you.. RFC9136 defines the SBD concept and it does not mention “asymmetric” models..


Thanks.
Jorge


From: Alexander Vainshtein <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 21, 2023 at 3:03 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Problematic text in RFC 9469

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information.


Dear authors of RFC 9469<https://datatracker.ietf.org/doc/html/rfc9469>,
I have just started reading this Information RFC, and I see a few problematic statements in the Terminology section.

Here is what I have noticed so far:

ES:
Ethernet Segment. When a Tenant System (TS) is connected to one or more NVEs via a set of Ethernet links, that set of links is referred to as an "Ethernet Segment". Each ES is represented by a unique Ethernet Segment Identifier (ESI) in the NVO3 network, and the ESI is used in EVPN routes that are specific to that ES.

This text seems inaccurate because, while the ES definition above equally applies to single-homed and multi-homed ES, but unique ESI values used in EVPN routes that are specific to this ES are only assigned to multi-homed ES. MAC/IP Advertisement (EVPN Type 2) routes that are specific to any single-homed ES always carry all zeroes in the ESI field of their NLRI.

IP-VRF:
IP Virtual Routing and Forwarding table, as defined in [RFC4364<https://datatracker.ietf.org/doc/html/rfc4364>]. It stores IP Prefixes that are part of the tenant's IP space and are distributed among NVEs of the same tenant by EVPN. A Route Distinguisher (RD) and one or more Route Targets (RTs) are required properties of an IP-VRF. An IP-VRF is instantiated in an NVE for a given tenant if the NVE is attached to multiple subnets of the tenant and local inter-subnet forwarding is required across those subnets.

This text seems inaccurate because, with Symmetric EVPN IRB, an IP-VRF that stores IP prefixes that are part of the tenant’s IP space may be instantiated in a PE that does not participate in any EVI and/or does not perform any local inter-subnet forwarding – please see embedded diagram below.

[cid:image001.png@01DA3D5E.844D0070]


SBD:
Supplementary Broadcast Domain, as defined in [RFC9136<https://datatracker.ietf.org/doc/html/rfc9136>]. It is a Broadcast Domain that does not have any Attachment Circuits, only has IRB interfaces, and provides connectivity among all the IP-VRFs of a tenant in the Interface-ful IP-VRF-to-IP-VRF models.

To the best of my understanding, all IRB interfaces that use an SBD MUST be Asymmetric, but this is not mentioned.

Do you think that these issues deserve posting some Errata?

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.
_______________________________________________
nvo3 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nvo3<https://www.ietf.org/mailman/listinfo/nvo3>