Re: [bess] Problematic text in RFC 9469

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Tue, 24 October 2023 08:24 UTC

Return-Path: <alexander.vainshtein@rbbn.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4EEC1524A3 for <bess@ietfa.amsl.com>; Tue, 24 Oct 2023 01:24:05 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rbbn.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 BWA0I9OK0B_Q for <bess@ietfa.amsl.com>; Tue, 24 Oct 2023 01:24:02 -0700 (PDT)
Received: from usb-smtp-delivery-110.mimecast.com (usb-smtp-delivery-110.mimecast.com [170.10.151.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 D1DE4C14CE52 for <bess@ietf.org>; Tue, 24 Oct 2023 01:24:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20230413; t=1698135841; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jq0kUriILdbItCgSRpQEIimcKnNFP9b3rvJ5yW5iEz4=; b=dlDwDzb2rh+KKCmfzx9lTvi1/5vOw0rVaX1hNfdv1OuWlrPOgmDo9cVQuZ0QXzrJc7alf+ VXG8OEerkllRdZbmFoZFFVt9kQhZ5vWiKO17wiVHTI+nnARlurHjuKU39ASsg+gDEuzIeT +3QnAEW1plyK78q0QUWpWnsJBhs0bno=
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02lp2040.outbound.protection.outlook.com [104.47.51.40]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id usb-mta-22-7FqNa4T_ORSM_PzcFoejhQ-1; Tue, 24 Oct 2023 01:22:36 -0700
X-MC-Unique: 7FqNa4T_ORSM_PzcFoejhQ-1
Received: from PH0PR03MB6300.namprd03.prod.outlook.com (2603:10b6:510:e2::5) by MW4PR03MB6666.namprd03.prod.outlook.com (2603:10b6:303:121::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6933.14; Tue, 24 Oct 2023 08:22:31 +0000
Received: from PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::4280:f75e:2eb2:ee97]) by PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::4280:f75e:2eb2:ee97%6]) with mapi id 15.20.6933.014; Tue, 24 Oct 2023 08:22:31 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
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>
Thread-Topic: Problematic text in RFC 9469
Thread-Index: AdnsbeT2RIhmTQe0Q/SL02FBo/hjOAZNWtdoACqSbcA=
Importance: high
X-Priority: 1
Date: Tue, 24 Oct 2023 08:22:31 +0000
Message-ID: <PH0PR03MB630013DAFB4ACAEA709F2BEAF6DFA@PH0PR03MB6300.namprd03.prod.outlook.com>
References: <PH0PR03MB6300D854E338B2DCC6141829F6F8A@PH0PR03MB6300.namprd03.prod.outlook.com> <DS0PR08MB94455B26682FF26C6C06876DF7D8A@DS0PR08MB9445.namprd08.prod.outlook.com>
In-Reply-To: <DS0PR08MB94455B26682FF26C6C06876DF7D8A@DS0PR08MB9445.namprd08.prod.outlook.com>
Accept-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR03MB6300:EE_|MW4PR03MB6666:EE_
x-ms-office365-filtering-correlation-id: 56a15277-f10c-400c-85b2-08dbd46a5e40
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0
x-microsoft-antispam-message-info: 6dUN1u2YUQGEA8ijup181E1UfU8Ker9vs1Ugp5lGCVJnY0MnIaS4ZtQczKmuntTJ9hs/mfLMua1ZT3s6hivHtrtbqZb5IYHOzIEVZrU/1ARPkG0RT6H5/OW6UIbLJryXI3sDxogFuZSFpY0luhJUdiIjtpZ0WJO3XRSJgp0rvA0NLhnHf8sxISvpBUvnt0qxHI74CMVdYv61+bwmA4rck9CwKBktX4z6zRQXY9t6XDjPnIyEuqeWFmP0CcrB24k+3bgP72kDtA9Iff+B2U6P05Xd7jPf3wOzJ1c8wIoREXVl0xqQiv7ocG7m7bSoK/FgvgGYnJu54bdluEKOLh/OdOfa2P16lxjd1Kd01QMVfNPbYQiwhtLHcuSe+11+9wTKoxuthcJOYFkSzf4xBlzPZkWY/aCG6jGGmMCdiTGSZWcjFHfbcqEaUh84YQWOZItIAmKivOqS1I6qtn4y2+P2ut6eW1rc20uZL+P91FccFppOy/x1cxNUY/SK8rENMWPFuVL6A5s543P+Pnsl2VWG40ZCE2BDMSWnHjprj1yNK3LfQUVdQ0eX7/1nrzNXvQhM2goHam+83HK8cDp7afY1mlqwQijNixc1qCt46z7Vxqk=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR03MB6300.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(346002)(396003)(376002)(366004)(136003)(39860400002)(230922051799003)(64100799003)(1800799009)(186009)(451199024)(166002)(71200400001)(122000001)(53546011)(6506007)(84970400001)(9686003)(83380400001)(7696005)(99936003)(66556008)(26005)(55016003)(33656002)(54906003)(66476007)(66446008)(64756008)(316002)(296002)(478600001)(38100700002)(110136005)(86362001)(76116006)(66946007)(52536014)(41300700001)(8676002)(4326008)(8936002)(38070700009)(2906002)(5660300002); DIR:OUT; SFP:1101
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: jOjeGvCsFPGe3vthO+fdvicSusqB6ONEcCkeWivg8YPDdG78bQAtQWxP8gHjyP9y1suEOba+dxYXkS8nqKny23j4ui7uRnQIpZv1bjyJpFjPQLd4MSISJQ0LoUYdYMztSEz9X86sklDn3orGqqSQv87IeUEWmTCq3O1aliGp4CX+TeywdnVTKpKgv5bqktBRIurskoC2KWaZMmR8AFZuAklAztRjulKZtni6ZsmcQ2z6xTuuFmYICi8ceF7csLkJzXDmkZ6eNsbPtyIM2o1eahE29wiefiCYMpsCV3+61Tcx8x4Gwcglpu+8ZwFQHGkj7Ua+t7YQASwgSEw2mCCbZiQ0Gf6SJMqIbOtYoVdCCq6AXXTBvYSn7LFKmsMhSVldhdmTb/c70bnO7bomlEvOfH2y+x3dpn9iwDAcVqTsPfxksMqAK4SY3WmVMQ0fkXqLtwgNqDGZN2XxNPyVUuFWb2kD72I1Kc8fhLCbzdLNk7ofozM9s7iN4tGuoEr3XEmoMETf3ArcUT+2e1jfOAIQdM6XWVrTxUf1L928VnfpYgGXlULfEG17v60XVodOl+OCnQBk9a6WhQKmxxUV4EOjWZAYfBLKn+lg4JZLGkwRwe8cPvC52T+rcTHt2XX9Q0QGKAR7Uirdqp1AZXUbdBbB6vJS20uc9W1FhfPDbCnVFUbemdWNnr0lSSptoncmKzZhZixiN9QRtAfLbfY/ZdKpWA1nsrrBkvB4lIj5cnkmzQoXgU58LYF+JjGVo9e3WJnXMXuLT4Dpnk78pp8UEVjRUFBl2UCROl3mY2+Bb9V2beeFqXf/AKueIH8ERPJBFSVYDe+wPMc4CqexeFgznt6EhAe7X62q79g9W4UklRfnyNNdboSJBQXz8ztUrGAvsPBfNx5tUQoNAhbo9TM0QTnaEPJOK65Iu/V5NOTiSViomoiKeO6zGu1yTJ3PzeptSZYLND70k5njXXRlwnfSNmH/eMMSNJoa1XnG3/N0XVuXHmvX12C68fAw6QmO/wh/8u0TkKhZzNEt5vC3iSCBeqvlRzF967wjo4r2I30QsBtMyDgGyhl32PDWS6iXRYtQIhMo7GxEIzL6k3HT78R7G66sFcn9NtIDlqP6ZSlKel1UYSOwGkLp6hNPTB2j9sDh3XoHabyAgUwYffyvveIuojS2i5DFCSlwNncmVzEv02VsmksozSj21tIrDR8kvGMod2mk71iRRbSHKd5hQkjQjPd+E+A6Rm+i7iGGnnmHQt/heEKNbivfApbo2qW4JKTyZ5kj8zXYhsmIbZX8nVzchAWjzG+3tTwNAG4I9w4UnY1cdftfp19ENNS0q8nCHrA4QgSboiiggbwQHuvgsQkDSUnWmQ7wrXP6lY+0DeFFq9sBMcSIih1o/4F+O01VjvS2P7Cwh/IRvNiL8+5R++m6lB/dncju5U0pXxrt6+sz91+XqT2NlV4XYjVFoZEbAhxeYC5lTHTD9dmZPEitUncY9rTi9miQR75At52eT2YnAPp3cfJTPCclRbs/BEH+aTLs1NcMV+HmXQh1dPwqqwfYaZlcUeeB1aKPEbN4VG++thryEJ9YJe87hd3eXzkr9DZzVxLs
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR03MB6300.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 56a15277-f10c-400c-85b2-08dbd46a5e40
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2023 08:22:31.5789 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /NCUWYtn9FkKKbiAc+4q5EeZx0C1JY1KU/lFezchafGlQbJ8tqqF4enfqAAE8Ueiy3cXF6N4BJZKC121bMZljg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR03MB6666
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Language: en-US
Content-Type: multipart/related; boundary="_004_PH0PR03MB630013DAFB4ACAEA709F2BEAF6DFAPH0PR03MB6300namp_"; type="multipart/alternative"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/jV05EYmQFqeQqJMCeNxGggAC5xo>
Subject: Re: [bess] Problematic text in RFC 9469
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Oct 2023 08:24:05 -0000

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:

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

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

o   Route Target identifying the tenant (IP-VRF).

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

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

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

o   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<mailto:Alexander.Vainshtein@rbbn.com>>
Date: Thursday, September 21, 2023 at 3:03 AM
To: draft-ietf-nvo3-evpn-applicability@ietf.org<mailto:draft-ietf-nvo3-evpn-applicability@ietf.org> <draft-ietf-nvo3-evpn-applicability@ietf.org<mailto:draft-ietf-nvo3-evpn-applicability@ietf.org>>
Cc: nvo3@ietf.org<mailto:nvo3@ietf.org> <nvo3@ietf.org<mailto:nvo3@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto: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.

[cid:image001.png@01DA0667.A8349F30]


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.