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

[Aldrin Isaac <[e-mail]>]

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]> 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*
>       1. The text clarifies that this Route Target may be the same as the
>       Route Target used in RT-5
>       2. 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]>
> *Sent:* Friday, December 22, 2023 9:19 PM
> *To:* Alexander Vainshtein <[e-mail]>;
> [e-mail]
> *Cc:* [e-mail]; [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]>
> *Date: *Tuesday, October 24, 2023 at 1:22 AM
> *To: *Jorge Rabadan (Nokia) <[e-mail]>,
> [e-mail] <
> [e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <[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 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]>
> *Sent:* Tuesday, October 24, 2023 3:23 AM
> *To:* Alexander Vainshtein <[e-mail]>;
> [e-mail]
> *Cc:* [e-mail]; [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]>
> *Date: *Thursday, September 21, 2023 at 3:03 AM
> *To: *[e-mail] <
> [e-mail]>
> *Cc: *[e-mail] <[e-mail]>, [e-mail] <[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 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.
>
>
>
>
>
>
>
> *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]
> https://www.ietf.org/mailman/listinfo/nvo3
>