[bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of draft-ietf-bess-evpn-bfd-07
Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Sun, 06 October 2024 09:47 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 8E980C151524 for <bess@ietfa.amsl.com>; Sun, 6 Oct 2024 02:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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_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 (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 lNisAZXGlHFJ for <bess@ietfa.amsl.com>; Sun, 6 Oct 2024 02:47: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 ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1621C14CE2C for <bess@ietf.org>; Sun, 6 Oct 2024 02:47:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=mimecast20230413; t=1728208021; 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=+4Yl98pCGH0cHMp2Ri7q1zKZMN+KzsKpsb8POS9czXs=; b=qDbqpVXfN+UiIv60dp8mi5S/erf4hQf3Rwaco8JpdZjrK2Agp5IdIrmOhaG75XBimGV6tv aTKa8lqv9ozxXpWAIyN7SsE4wKmIWgokuBsoGebObblHbGaT9AND07vYTgIoumjkp9MhXf 8nRrOR8H6WYSWSQKVxwq/wONahVqDQI=
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id usb-mta-29-PrWjQj2QOY-XHUa1VS7z9w-2; Sun, 06 Oct 2024 02:46:49 -0700
X-MC-Unique: PrWjQj2QOY-XHUa1VS7z9w-2
Received: from PH0PR03MB6300.namprd03.prod.outlook.com (2603:10b6:510:e2::5) by BL1PR03MB6006.namprd03.prod.outlook.com (2603:10b6:208:313::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8026.20; Sun, 6 Oct 2024 09:46:44 +0000
Received: from PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::a48b:db16:775a:4a16]) by PH0PR03MB6300.namprd03.prod.outlook.com ([fe80::a48b:db16:775a:4a16%7]) with mapi id 15.20.8026.019; Sun, 6 Oct 2024 09:46:44 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Thread-Topic: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of draft-ietf-bess-evpn-bfd-07
Thread-Index: AQHbE1Esr35/+EWzhEeAKAiwrm2Y9LJ5fdRg
Date: Sun, 06 Oct 2024 09:46:44 +0000
Message-ID: <PH0PR03MB63003630B4749B1810829E0CF67C2@PH0PR03MB6300.namprd03.prod.outlook.com>
References: <172649857459.4021334.16064172944993408610@dt-datatracker-68b7b78cf9-q8rsp> <PH0PR03MB63000A6128F35CBE1273C452F6612@PH0PR03MB6300.namprd03.prod.outlook.com> <CAF4+nEFbRbtD+EGVmqXeWjBdyowqJ+jngx4Xt44Hk3on-JJ2dw@mail.gmail.com>
In-Reply-To: <CAF4+nEFbRbtD+EGVmqXeWjBdyowqJ+jngx4Xt44Hk3on-JJ2dw@mail.gmail.com>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR03MB6300:EE_|BL1PR03MB6006:EE_
x-ms-office365-filtering-correlation-id: 44b9017c-c622-47f9-03a2-08dce5ebc994
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018
x-microsoft-antispam-message-info: wQaknV4coNoQH6PYUdvNMKmckzNPznh05UWSprEwI/NNtIloPAbZTCH7gnuwBRYPHDCps3tU6DmKop+20XguUa4UYuQ0GIlhwVTw9OeiYbPAQMZmKPRw2wc3mKO3NH3+iRYR8MBYnLucPHPSZTZEVXooHapDTDcebytRdjJL3k0EFOMj8GNlHpNr6khvaDDb3na54UCd8iYsnGxvab7JSyTzQ8pprp+OrZoHT7lvs5lUt4WuXXuYTaTZ3RpEMA/lRX8g8e0NLQwMyrQaySLYZJA38OL4wUIJFmOEDMrzupBhIvCVGeqWyycs18frJelQxtGbtPTP0YSWv+FITcTPBGuHpany61JOZjJlnYRjeiE+NFxfxtfU+sAGHgRbWZpiUHcLcqGG+gHxg8TPZSdE1OkAmDWOIbbphnjPLe5uoU3jLqCRcKlYqGS2VxYQAWnCoHVXxFZOLc8wzw/ewATwm/r3V8P+HhVSsTwfHJvNT1PtKDUtXxBqouTNIAWffFygFu4KIClZr6BNwBveRwtUb4FR9zHUYJLxNDg0/mWhssU9ZeC+RHAgSKyihkVwxGVPuU9nnVQepnNgZiwAQ7TFu/qU0zFfNgA81LFOF86tdCFcZnPCpyRj5P4ccRVOxguC5ieDxCXcLiGrwsuuCsEql9eGimzQblZ1VUUm8nb1g31msVejkot84GEerFmEj7VjKpd5pYetQdvsg7gvQghHj+41bcPQs/hW2TfqJuw+duj7Y8fR1fFeaie9qQhoKunlL2wIQl0h8izPUdajZXQVPnE7mWCj25VoTihRlbAb/NcwWRD+Fx56yr/ROYxznUkeL4aFAexHc4TW8LK1gmgK/DNgsnyRNYJCFeI2Kg4Zgyf58yi2BcY/fSMjYuGmE17MU0r1o2Ysal8L5B0P4XdLT43Q8UfUzYXnLaP4owCjPgZJGqhUlJ42bI+L8AbHleN4qzMH0bwvaJcI3MTNWsLHVS/MX4RFG1+t308j1EnyuiSc5zL2nTY36A3O4YkEai4qAm/TS8HiYeLYwnhAvW4otIBlCI1OQdmGu4r+u7i6rSpfo5kAJUNwV93e2Nk/GG3SKISwIFVTuYSjxqDXGLV9xQ7ZswWzhR7BqzEihOJqe0JFpmhQrOL5ZhO6w468YqPugVfflr9RkACGKYDcfqK6XCxL5rw3f/tgfvv5iQ4Pcpz+paJ7wILVEBdlfRZPHWRCbUu2bKPbbyaUjeYOQpcDc2dPUfFPYFyXHsL+9GnysxFC7+1aH2ahtbBvBxuif5HiJ5vNAKyo4neFqKukRT+J1Itko31aZbFiE5TDx7tuEf4=
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:(13230040)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1102
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 9HtxcCYGj+tumaSLluQL2dbJBbCBTttrwU7scsy6pkIRWLX1gow0ecSC2rWtIDtUF2j0XzNl8s70FQ9Mzx7WZU/Nhw5aJ6xPxin+NBJhyqkUXFuZJc3fAyXizIF1XUrdSRZvagYPokQT3LxuLAJHYD6To+oxYYVYZcxwi3BRzqyty2ZsJe6KOttH5vo/Nv5Ok/WaT5Fpj9Cytgc0b4QrEQXHHxszs/TwZElLJtOPKzsXkqnJ1opqJ0XhimEuAjy80G6hVdbIt+KLHVu7CMVOBz9ATPoc5UAJLiDLxFE8r7kL8AhmE0wIakSLTfRZYr09H+sLzUzS8nmBXtEhXuOIfG16CQ0Vv9D2Q6vsyLpkKUWYX4QaqaXT6F7v1gK5dppFFkTcVxJkvz/ulOQzexL716ml0XMZoYwLwCB5BZnAZhizHbIq529tl59jPJbz4oCXA+tKRmxxsPtQ7Gj3aTIy08Hf2jQe1gs9+BrpVQR8mjcDvvUrE+0zbfDH6PuQOWS8IOev+x7dJz0nSFnUoH0uAVe1BTGG3AnxVMqR19y0zQDt/aP0ID+RwYi6+vJliwmI0F4cXkt7oRXBNXUtnDOJK9UpMLxoYnXG/rXBefR1imhY2TWhllxaNZVl1NwcDUzyXxL5rpRDDFrPw3r9PZ4B0TXses4OwuvRmARI0Bb4ZFzKPaib1kUGiH1uHLYcdEUJjCmy//9kHNEkcJy9YhE42CaP87YnS6zCSivxY52+Oz7xKi7eZTyI1fuJZuSdTOFUs0ksFiYYoebIyy1589piu+abP5Rb2EhTZGB5J9pEz78it9z3poYSB/wAU544sGTbHG88QGpmGC4Dap8DHwqX7mZnc7ZlaIFI0IQY6JSUYFJnsKTiCsc+portmuUniqUVScDeNjgsPkchqdIfUtCWKLA0HLr43nr/M/8IjGPAJI3+FUhA2/g20vmKJ54fKyen926Nlh9Q+CVmZWK5sjGf0Pm3ahtaiPdBj/Nev2XCNzEc99UAQyQtEHRGWi+obTL0doOVXccK/jJFupczzm9bDqfQYLmh5ziD05c1yxa8ndmkJTcEWGyxaqBwxoaduo56Awv0BEkLe3FYiMDBj7Cib1NiNPIGYJoTlmwdfd0VwU6hRDUYHp0cT1266ziJFLUGSsE9o22Xi0Y6HWf0w2oY4UX02HjxsbLBMzYbmM1iP++/jmACCMbE29uZAnfCTXAwOZyzPNSt9ZfvkPjKIDSpsjiyQmLIfQCeV8SizZZz7eboFV+443V3gaoBtGsuG6y5DCFzPR/KCSaty7xo80drEZxYnC0My23bsjnr0z7EBnFvxDxDAmczvgDq+h1V5ZWDg43w85mFVDji0LSrMDY/BoLecCtkk7cfATHk94HF20M+zMEoZ39hSbj0VJRc2dOxjp+sXkKy0Kqq6ANOjB6GlbpuzQOhVEBM94PZj06oFbyr39pn9peJC/JHu+ysN7rxXqVqeOHWje9p17XwBpuRZCbAhbphFYHj/fiqg+M52iVYr2vNXDoiRkP7JcbHLoo7aWaABxXc+70sVm0WTkNUjCpX9FYUau2V2vduDA/kbTQ=
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: 44b9017c-c622-47f9-03a2-08dce5ebc994
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2024 09:46:44.1269 (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: 2p3l6r+3KgZyW042FscjGLEoC29xutDnTkxMsj79T5DxQY09RU0LwZoUI+ZnmTisYMN8Jkg1ea+orSYK8L2yFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR03MB6006
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: rbbn.com
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_PH0PR03MB63003630B4749B1810829E0CF67C2PH0PR03MB6300namp_"
Message-ID-Hash: XZC5TW6JMGQCU323IWUU7FLR42DVD4QJ
X-Message-ID-Hash: XZC5TW6JMGQCU323IWUU7FLR42DVD4QJ
X-MailFrom: alexander.vainshtein@rbbn.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Mohamed Boucadair <mohamed.boucadair@orange.com>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-bfd.all@ietf.org" <draft-ietf-bess-evpn-bfd.all@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of draft-ietf-bess-evpn-bfd-07
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/rkm7HacKp9JSSDNCKmgrpNcucs0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>
Hi Donald, My apologies for a much-delayed response to your email. I am now reading the -08 version of the draft, and I will send a detailed response based on this document. At the same time, I would like to bring to your attention my detailed comments on the -07 version of the draft<https://mailarchive.ietf.org/arch/msg/bess/lXi2BB6Fn95UW3bbJc0tL1mgiKQ/> which I have asked to consider as any other LC comments on the draft. I cannot yet say whether the -08 version addresses these comments or not. Regards, Sasha From: Donald Eastlake <d3e3e3@gmail.com> Sent: Monday, September 30, 2024 6:54 PM To: Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org> Cc: Mohamed Boucadair <mohamed.boucadair@orange.com>; bess@ietf.org; draft-ietf-bess-evpn-bfd.all@ietf.org; rtg-dir@ietf.org Subject: [RTG-DIR]Re: [EXTERNAL] Rtgdir early review of draft-ietf-bess-evpn-bfd-07 Hi Sasha, On Tue, Sep 17, 2024 at 8:27 AM Alexander Vainshtein <Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org<mailto:Alexander.Vainshtein=40rbbn.com@dmarc.ietf.org>> wrote: > > Mohammed, > > Lots of thanks for the review. > > I have posted my concerns about the draft in question some time ago, and they are mainly orthogonal to the issues you raise. > > However, there is one important point that you are raising and that overlaps, to some extent, with some of my comments. > > You have written that you have failed finding “EVPN network layer” in 7432 or 7432bis, and your guess is that the authors may refer to the definition in Section 2.1 of RFC 9062. Yes, the draft does intend to refer to the network layer specified in Section 2.1 of RFC 9062 and hopefully that is clearer in the latest revision of the draft. > But I think that the real question here should be whether EVPN network layer exists at all, and, if yes, whether it could be monitored using BFD. Well, it seems to me that PEs exist and the paths between PEs that are used by EVPN exist and it can be useful to monitor those paths. It is convenient to have some name to use for the set of such paths. Is there some name you would prefer to "network layer"? It also seems to me that it can be monitored with BFD but it could be monitored in other ways. > Quoting from Section 9.2.1 of RFC 7432 (the relevant text is highlighted): > > > A PE may advertise the same single EVPN label for all MAC addresses > in a given MAC-VRF. This label assignment is referred to as a per > MAC-VRF label assignment. Alternatively, a PE may advertise a unique > EVPN label per <MAC-VRF, Ethernet tag> combination. This label > assignment is referred to as a per <MAC-VRF, Ethernet tag> label > assignment. As a third option, a PE may advertise a unique EVPN > label per <ESI, Ethernet tag> combination. This label assignment is > referred to as a per <ESI, Ethernet tag> label assignment. As a > fourth option, a PE may advertise a unique EVPN label per MAC > address. This label assignment is referred to as a per MAC label > assignment. All of these label assignment methods have their > trade-offs. The choice of a particular label assignment methodology > is purely local to the PE that originates the route. > > > This is definition is re-phrased (without any change in the semantics) in Section 9.2.1 of 7432bis as following: > > > The choice of a particular label assignment methodology is purely local to the PE that originates the route :¶ > · A PE may advertise the same single EVPN label for all MAC addresses in a given MAC-VRF. This label assignment is referred to as a per MAC-VRF label assignment. > · Alternatively, a PE may advertise a unique EVPN label per <MAC-VRF, Ethernet tag> combination. This label assignment is referred to as a per <MAC-VRF, Ethernet tag> label assignment. > · As a third option, a PE may advertise a unique EVPN label per <ESI, Ethernet tag> combination. This label assignment is referred to as a per <ESI, Ethernet tag> label assignment. > · As a fourth option, a PE may advertise a unique EVPN label per MAC address. This label assignment is referred to as a per MAC label assignment. > All of these label assignment methods have their trade‑offs. An assignment per MAC-VRF label requires the least number of EVPN labels but requires a MAC lookup in addition to an MPLS lookup on an egress PE for forwarding. On the other hand, a unique label per <ESI, Ethernet tag> or a unique label per MAC allows an egress PE to forward a packet that it receives from another PE to the connected CE, after looking up only the MPLS labels without having to perform a MAC lookup. This includes the capability to perform appropriate VLAN ID translation on egress to the CE. > > > In both cases 4 (four) different options for allocating labels carried in the Label1 field of the NLRI of EVPN Type 2 routes are listed, and 7432bis explains that each of these options has its own trade-offs. > > > At the same time, Section 2.3 EVPN Network Layer OAM” of RFC 9062 says: > > EVPN Network OAM is visible to the PE nodes only. This OAM layer is analogous to Virtual Circuit Connectivity Verification (VCCV) [RFC5085] in the case of VPLS/VPWS. It provides mechanisms to check the correct operation of the data plane as well as a mechanism to verify the data plane against the control plane. This includes the ability to perform fault detection and diagnostics on:¶ > · the MP2P tunnels used for the transport of unicast traffic between PEs. EVPN allows for three different models of unicast label assignment: label per EVI, label per <ESI, Ethernet Tag>, and label per MAC address. In all three models, the label is bound to an EVPN Unicast Forwarding Equivalence Class (FEC). EVPN Network OAM MUST provide mechanisms to check the operation of the data plane and verify that operation against the control plane view. > > > This text is slightly inconsistent with the text in 7432/7432bis (one of the four options of the latter is missing in the former). But in any case, the “EVPN network layer” in the specific PE may be associated not just with a specific MAC-VRF (or with a specific BD within a MAC-VRF) but with a specific NAC-VRF, locally attached Ethernet Segment} pair or even with a specific <MAC-VRF, locally learned MAC address> pair. An Errata should be filed against RFC 9062. Do you want to do this or should I? > And this raises a question about the number of EVPN BFD sessions that could be required to monitor such EVPN Network layer. If there are a vast number of logically distinct paths used by EVPN between PEs, then monitoring them all may be impractical. > Hope these notes will be useful. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com<mailto:d3e3e3@gmail.com> > Regards, > > Sasha > > > > From: Mohamed Boucadair via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> > Sent: Monday, September 16, 2024 5:56 PM > To: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org> > Cc: bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-evpn-bfd.all@ietf.org<mailto:draft-ietf-bess-evpn-bfd.all@ietf.org> > Subject: [EXTERNAL] [RTG-DIR]Rtgdir early review of draft-ietf-bess-evpn-bfd-07 > > > > Reviewer: Mohamed Boucadair > Review result: Has Issues > > Hi authors, > > Thanks for the effort put into this document. > > Overall, the document reads well. The specification leverages existing > specifications with exceptions called out it in the document. This approach > seems reasonable, but there are some issues that need to be fixed. These are > highlighted in the detailed review (see below). A subset of them are > highlighted hereafter: > > # Better position the document: For example, I failed to find this "network > layer" defined in RFC7432 or 7432bis. I think that you are referring to the > layering in 2.1 of 9062. For example, you can consider adding a sentence in the > introduction about 2.1 of 9062 to position the layer you are considering. > > # 7432 or 7432bis: Any reason why the bis is cited explicitly here? Are there > parts of the spec that are not applicable to 7432? I don't think so, but it is > better clarify this in the doc rather than leaving the readers guess. > > # "future versions of this document" vs "other documents": The document says in > several places that "It is intended to address this in future versions of this > document.". The intended scope should be clarified. > > # Internal inconsistency: > > ## The document refers to TBD3 and cites Section 8, but there is no such > definition in the IANA section ## The document cites "dedicated unicast MAC" > and "dedicated multicast MAC" but these are not defined in the document. > > ## RFC 9026 > > Previous sections state that 9026 is not mandatory and other mechanisms can be > used. However, Section This text seems to assume that it is always used: > > "It also contains a BFD Discriminator > Attribute [RFC9026] with BFD Mode TDB4 giving the BFD discriminator > that will be used by the tail. > " > > (note that s/TDB4/TBD2) > > # Redundant requirements: For example, the document says > > " The mechanisms specified in BFD for MPLS LSPs [RFC5884] [RFC7726] and > BFD for VXLAN [RFC8971] are, except as otherwise provided herein, > applied to test loss of continuity for unicast EVPN traffic. > " > but then > > " Once the BFD session is UP, the ends of the BFD session MUST NOT > change the local discriminator values of the BFD Control packets they > generate, unless they first bring down the session as specified in > [RFC5884]. > " > > the intended behavior vs "local discriminator values" here is redundant with > this part in Section 7 of 5884: > > "Note that once the BFD session for the MPLS LSP is UP, either end of the BFD > session MUST NOT change the source IP address and the local discriminator > values of the BFD Control packets it generates, unless it first brings down the > session." > > No? > > # Detailed review can be found here, fwiw: > > * pdf: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.pdf<https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.pdf> > * doc: > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.doc<https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-bess-evpn-bfd-07-rev%20Med.doc> > > Feel free to grab whatever you think useful. > > Hope this helps. > > Cheers, > Med > > > > 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.
- [bess] Rtgdir early review of draft-ietf-bess-evp… Mohamed Boucadair via Datatracker
- [bess] Re: [EXTERNAL] [RTG-DIR]Rtgdir early revie… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… mohamed.boucadair
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Donald Eastlake
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… mohamed.boucadair
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… Greg Mirsky
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Donald Eastlake
- [bess] Re: Rtgdir early review of draft-ietf-bess… Donald Eastlake
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: [EXTERNAL] Rtgdir early r… Donald Eastlake
- [bess] My comments on draft-ietf-bess-evpn-bfd (w… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… mohamed.boucadair
- [bess] Re: My comments on draft-ietf-bess-evpn-bf… Alexander Vainshtein
- [bess] Re: [RTG-DIR]Re: Rtgdir early review of dr… Greg Mirsky