Re: [nvo3] Problematic text in RFC 9469
Aldrin Isaac <aldrin.isaac@gmail.com> Wed, 27 December 2023 21:59 UTC
Return-Path: <aldrin.isaac@gmail.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B8C14F749; Wed, 27 Dec 2023 13:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hQvDdGOfcON; Wed, 27 Dec 2023 13:59:43 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93B0C14F73F; Wed, 27 Dec 2023 13:59:42 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2ccc34a9f90so25776251fa.0; Wed, 27 Dec 2023 13:59:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703714381; x=1704319181; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=s6XOGVuPwKr4eoV6fwMKmZxRD/DSfmSOuDSOhWoveFk=; b=mdj4pfnQVNtkklDgh57VBTvX1eVO4TAlzpS5XgHsSklym8VaXN4zAfuPm6PLvleQIr 57nDorWbjM1u2gcwGDFK59Pqxevhr4ypOHTYeswQO3zhVUOFc+19tjFUxzq6rQhKRmjR uNpDMtpEsuJg618oaP2qDMwrhQIeVQY+8p4GOEpGL2l+tP9CzsZ9xgeU5DsrtLE1+HMt m4N8k61i44WbKG+K8gO8+HIismJTUOqfh+UaO1q4qYOOYXuUE2+6+PwbjK5VuwjYE6yZ HbpfM0soc9XkmlLgwpUaImOjZrsSFx7TAk8CFri6lSc0jo1aDjBXlGafxEbJ3t29X28l fKTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703714381; x=1704319181; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=s6XOGVuPwKr4eoV6fwMKmZxRD/DSfmSOuDSOhWoveFk=; b=PxmbiBwaEnhKslv1a1mng+6PgqR2t3VwLPy3S+LDoASzu+IiuP0dn4UloDn2ycYCV2 o4Ljwwg/+kNA5o5N9nEbpqfDDvzwjj75SWQpsuPT0rJvzZD/Zh8v1K0zsB8k0h54/vS5 AOjkVayGPvfokCwbGM+PiBAyELYYHLYZJUokeW/wmMsoDTvH0udig88CORgvQe5AJXvp A9y3OD3OmvL9aBwaVf17v/Acm9+BArEM+0O2G/ziZVEShfipTQy3rBzjBLe4LrajKQyT iUxoZDJwIUwJ7B67d4iiH6AZm9QYRyF0vWWK7dW3SaXc0wtEjCNEgRICE2ZUTgD+FzNg oJkA==
X-Gm-Message-State: AOJu0Yy76ZdWN17RDs3qixnwdnVRfB6U0S8ImAa73NvoqK1C16Vc8UXX TEOlgCj7TjOgFL1mP3z9lWtGLdR+pSI1hlHXYDY=
X-Google-Smtp-Source: AGHT+IHmztXj2PxRsLJHWZ6Pwog2xXdJ2VCOiMiDdnxrlkTsYdNj0DmRQZy/ul2lXosqlPhye37RnuSaC8LybO/4YRk=
X-Received: by 2002:a2e:9090:0:b0:2cc:d864:1248 with SMTP id l16-20020a2e9090000000b002ccd8641248mr1069220ljg.48.1703714380468; Wed, 27 Dec 2023 13:59:40 -0800 (PST)
MIME-Version: 1.0
References: <PH0PR03MB6300D854E338B2DCC6141829F6F8A@PH0PR03MB6300.namprd03.prod.outlook.com> <DS0PR08MB94455B26682FF26C6C06876DF7D8A@DS0PR08MB9445.namprd08.prod.outlook.com> <PH0PR03MB630013DAFB4ACAEA709F2BEAF6DFA@PH0PR03MB6300.namprd03.prod.outlook.com> <LV8PR08MB9584A7D497AB558A2ABBFC5DF794A@LV8PR08MB9584.namprd08.prod.outlook.com> <PH0PR03MB6300D59197B53DAADA2EA354F69AA@PH0PR03MB6300.namprd03.prod.outlook.com>
In-Reply-To: <PH0PR03MB6300D59197B53DAADA2EA354F69AA@PH0PR03MB6300.namprd03.prod.outlook.com>
From: Aldrin Isaac <aldrin.isaac@gmail.com>
Date: Wed, 27 Dec 2023 13:59:02 -0800
Message-ID: <CAOA2mbxBSo=87StFr-=LjZo2y_49TUH-NuKGYhu0Op6HiU7uoA@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Cc: "Jorge Rabadan (Nokia)" <jorge.rabadan@nokia.com>, "nvo3@ietf.org" <nvo3@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-nvo3-evpn-applicability@ietf.org" <draft-ietf-nvo3-evpn-applicability@ietf.org>
Content-Type: multipart/related; boundary="00000000000072b376060d84eae8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/oKZ8szifwBHreKhdj3KKrC_FSiA>
Subject: Re: [nvo3] Problematic text in RFC 9469
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Dec 2023 21:59:48 -0000
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 < Alexander.Vainshtein@rbbn.com> 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) <jorge.rabadan@nokia.com> > *Sent:* Friday, December 22, 2023 9:19 PM > *To:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; > draft-ietf-nvo3-evpn-applicability@ietf.org > *Cc:* nvo3@ietf.org; bess@ietf.org > *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 <Alexander.Vainshtein@rbbn.com> > *Date: *Tuesday, October 24, 2023 at 1:22 AM > *To: *Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>, > draft-ietf-nvo3-evpn-applicability@ietf.org < > draft-ietf-nvo3-evpn-applicability@ietf.org> > *Cc: *nvo3@ietf.org <nvo3@ietf.org>, bess@ietf.org <bess@ietf.org> > *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) <jorge.rabadan@nokia.com> > *Sent:* Tuesday, October 24, 2023 3:23 AM > *To:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>; > draft-ietf-nvo3-evpn-applicability@ietf.org > *Cc:* nvo3@ietf.org; bess@ietf.org > *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 <Alexander.Vainshtein@rbbn.com> > *Date: *Thursday, September 21, 2023 at 3:03 AM > *To: *draft-ietf-nvo3-evpn-applicability@ietf.org < > draft-ietf-nvo3-evpn-applicability@ietf.org> > *Cc: *nvo3@ietf.org <nvo3@ietf.org>, bess@ietf.org <bess@ietf.org> > *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 > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >
- [nvo3] Problematic text in RFC 9469 Alexander Vainshtein
- Re: [nvo3] Problematic text in RFC 9469 Jorge Rabadan (Nokia)
- Re: [nvo3] Problematic text in RFC 9469 Alexander Vainshtein
- Re: [nvo3] Problematic text in RFC 9469 Jorge Rabadan (Nokia)
- Re: [nvo3] Problematic text in RFC 9469 Alexander Vainshtein
- Re: [nvo3] Problematic text in RFC 9469 Aldrin Isaac
- Re: [nvo3] [EXTERNAL] Re: Problematic text in RFC… Alexander Vainshtein