[bess] Re: [RTG-DIR]Re: Rtgdir early review of draft-ietf-bess-evpn-bfd-07
Greg Mirsky <gregimirsky@gmail.com> Thu, 26 September 2024 17:58 UTC
Return-Path: <gregimirsky@gmail.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 DB058C14F602; Thu, 26 Sep 2024 10:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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 6zmnmNq0aucS; Thu, 26 Sep 2024 10:58:05 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE05C14F6FF; Thu, 26 Sep 2024 10:58:05 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-42cafda818aso12470305e9.2; Thu, 26 Sep 2024 10:58:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727373483; x=1727978283; 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=+09nIJNtRHBqeO8M+qLb92dSpESaYmNdijR8gez8rYE=; b=S07W2hb/XKB91y5yzKvOUusw9nMRczg4RE/ItxlNR82jeC4RK68/WJp7RW026CTqt9 D1tfLgU5nt+fzNMF3acgY9tVaHVfF5kwk/7x9EOrhGGF0WPDiZwG4N4e9rTBnCDsfLOa odP+EKCmkmK8g9y2QuhekTuO1PylWStlTiwNTRhyRvpOgnLs9bnrPNX1ALX1YDdzI9Cx 9ypn4bB2/TDiwOll7wDRpwTcEyc47PFQpC5bhLyzFlqrcALiZ1tRQ29fhBkO+nZDPNHO Y9AcBtV1avDviSYLEbxgn+zCjkBjCGfSGwB/swSEtIIrDgADT7I/avR9g9cg7IG8Jppq 5htA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727373483; x=1727978283; 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=+09nIJNtRHBqeO8M+qLb92dSpESaYmNdijR8gez8rYE=; b=lkPN+atMk0ShPW5TOy+6+Veb0sPSFZFl3hj4/br2i5vVdUkLom+1+mdiCVRQ6SCX3U oBfTRzzDOexsWa2jXRAHK4lblBD5m4qbZebn/z86NYZgZHnP5A7OIgFuO1+q485lUEwu jcNAY5YwgiztEWR9JL/En4477rSzdZFZrRY266E/yhxMI9XIrWxVrN+9NWCpaejr/utf B3IiylBhHOUBk7TLyqZaxgbzEbBCj420HoQ9A8YL2VP+Smv58xwyf9n7iTGfdjP86mj8 kWSdXVyWFnT8I79kVBO+wTXloJTrCkrVE/RxklE1IndV/z0F+gWfQ9GudMJ0ay/x1l3T vDKA==
X-Forwarded-Encrypted: i=1; AJvYcCU6w8CDj3vDd3qJQ/V+h3/FAVVAd4Cho4t3JejqUnievccx4JBYjSQPk0j+S2nrZZhI96ZW7f/a2w==@ietf.org, AJvYcCVtqD1GgT2/AY+zAa01OCfx9lFm4R8SJ8ggL8+WiZtgNIBjc8bWSQxgVqzo89S57kJV5+lx8aMZ7JIj7uvhCxyEDX9OLmDY1CGeYOrlgg==@ietf.org, AJvYcCXxGHBdtPwp4ScNI+HFAILLX+VhlA9Bfab6dqwtxpfC+iK/z5qq9nUhNtDxckKP/BES3chJ@ietf.org
X-Gm-Message-State: AOJu0YwAG577M/EaRas+H6/PQnLxACDsOfmw9Mv0ETv8Nw8VTUAS7F7N 5c1sM7kphF+c2uBMFpbmaonDUzEQZiZVN9VGZy5JYhrQDoMfmgKyR1sh+/FFBvdcZOZuqBJdYpT ee11YaU5bHsNHumk0x0HRtMRFv3U=
X-Google-Smtp-Source: AGHT+IF0G31ILwSVPZyfdY9F+Q4fTUs8EzVXux7p5HzcHeizPwhb82YFyFSLAo2stdlpFZQWIDCEL73bkd5/kbXkx/8=
X-Received: by 2002:a05:600c:1ca2:b0:428:f0c2:ef4a with SMTP id 5b1f17b1804b1-42f58433166mr2359365e9.13.1727373482760; Thu, 26 Sep 2024 10:58:02 -0700 (PDT)
MIME-Version: 1.0
References: <172649857459.4021334.16064172944993408610@dt-datatracker-68b7b78cf9-q8rsp> <CAF4+nEHdtV0KHDewRrGQ6i-x4Fm7Vjgp2GrbHN0M03vGyBq25A@mail.gmail.com> <DU2PR02MB10160E50D00E78DB06C3F264D886A2@DU2PR02MB10160.eurprd02.prod.outlook.com> <CA+RyBmWm=gtTtC+FUGGVCLHcRojB6Xxg77KX0E_6t6W0i=m45Q@mail.gmail.com> <DU2PR02MB101609F6F3F28A12B8ABE34A3886A2@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB101609F6F3F28A12B8ABE34A3886A2@DU2PR02MB10160.eurprd02.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 26 Sep 2024 10:57:52 -0700
Message-ID: <CA+RyBmXLXB-g0Oc=ckUh+TtDDojYAFiszXNDZvU-V5D1dPpC0g@mail.gmail.com>
To: mohamed.boucadair@orange.com
Content-Type: multipart/alternative; boundary="000000000000d5a5f10623097ac7"
Message-ID-Hash: ZELTXRLT6MC7653HBMAPP7BU3Z5X6UYF
X-Message-ID-Hash: ZELTXRLT6MC7653HBMAPP7BU3Z5X6UYF
X-MailFrom: gregimirsky@gmail.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: Donald Eastlake <d3e3e3@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-bfd.all@ietf.org" <draft-ietf-bess-evpn-bfd.all@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [bess] Re: [RTG-DIR]Re: 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/YPKP0k7g5Fw2rfJA3kYEV7tjFkA>
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 Med, thank you for your quick response and a great suggestion. Will use it in the next update of the draft. Regards, Greg On Thu, Sep 26, 2024 at 10:13 AM <mohamed.boucadair@orange.com> wrote: > Hi Greg, > > > > This works for me. I would s/QoS treatment/forwarding behavior, though. > > > > Thank you. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky <gregimirsky@gmail.com> > *Envoyé :* jeudi 26 septembre 2024 18:22 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> > *Cc :* Donald Eastlake <d3e3e3@gmail.com>; rtg-dir@ietf.org; bess@ietf.org; > draft-ietf-bess-evpn-bfd.all@ietf.org > *Objet :* [RTG-DIR]Re: Rtgdir early review of draft-ietf-bess-evpn-bfd-07 > > > > Hi Mohamed, > > thank you for your thoughtful review and constructive comments. In regard > to your question about the interpretation of "in-band" in Abstract, I > propose the following update in Introduction: > > OLD TEXT: > > The mechanisms > > specified in this document use the widely adopted Bidirectional > > Forwarding Detection (BFD) [RFC5880] protocol, which is a lightweight > > protocol using fixed length messages suitable for implementation in > > hardware, and other protocols as necessary. > > NEW TEXT: > > The mechanisms > > specified in this document use the widely adopted Bidirectional > > Forwarding Detection (BFD) [RFC5880] protocol, which is a lightweight > > protocol using fixed length messages suitable for implementation in > > hardware, and other protocols as necessary. All these mechanisms > > are applied as active in-band OAM methods, i.e., specially constructed > > OAM packets traverse the same set of links and interfaces receiving > > the same QoS treatment as the monitored EVPN flow. > > END > > Would the update address your concern? > > > > Regards, > > Greg > > > > On Thu, Sep 26, 2024 at 2:03 AM <mohamed.boucadair@orange.com> wrote: > > Hi Donald, > > Thank you for the detailed replies and for the changes in -08. This looks > much more better to me. > > I wonder whether you checked the scalability point raised by Sasha as > well. Wouldn't that be a point that is worth be more elaborated in Section > 7? > > Aah, I expected the "in-band" thing to be elaborated further in the core > document or simply be removed. > > Cheers, > Med > > > -----Message d'origine----- > > De : Donald Eastlake <d3e3e3@gmail.com> > > Envoyé : mercredi 25 septembre 2024 22:18 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com> > > Cc : rtg-dir@ietf.org; bess@ietf.org; draft-ietf-bess-evpn- > > bfd.all@ietf.org > > Objet : [RTG-DIR]Re: Rtgdir early review of draft-ietf-bess-evpn- > > bfd-07 > > > > > > Hi Med, > > > > On Mon, Sep 16, 2024 at 10:56 AM Mohamed Boucadair via > > Datatracker <noreply@ietf.org> wrote: > > > 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, > > > > Thanks. > > > > > 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. > > > > Will add such a reference to the Abstract and will add some more > > and more specific references to 9062. I would point out that the > > very first two sentences of the Introduction are as follows: > > > > [RFC9062] outlines the OAM requirements of Ethernet VPN > > networks > > (EVPN) [rfc7432bis]. This document specifies mechanisms for > > proactive fault detection at the network (overlay) layer of > > EVPN, > > that is to say between PEs (Provider Edge nodes). > > > > > # 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. > > > > If a base document is undergoing revision for clarification and > > perhaps minor corrections, I believe that it is best practice to > > reference the revision because it would normally be a better > > document than the base document, that is, clearer and more > > complete/correct. > > > > > # "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. > > > > I think what the authors had in mind was a future expanded RFC > > that obsoleted or updated the RFC this draft is intended to > > become. I will change the wording to avoid confusion. > > > > > # 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. > > > > Will fix this. I think a previous change was incorrectly > > implemented. > > > > > ## 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) > > > > Will reword to clarify/correct this. > > > > > # 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? > > > > OK but I think noting this is useful so I'll replace the current > > text with a clearly labeled quote from RFC 5884 elsewere in the > > draft. > > > > > # Detailed review can be found here, fwiw: > > > > > > * pdf: > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252> > > Fgith > > > ub.com%2Fboucadair%2FIETF-Drafts- > > Reviews%2Fblob%2Fmaster%2F2024%2Fdraf > > > t-ietf-bess-evpn-bfd-07- > > rev%2520Med.pdf&data=05%7C02%7Cmohamed.boucada > > > > > ir%40orange.com%7C0807f9981e1f4fde5f0b08dcdd9f2821%7C90c7a20af34b > > 40bfb > > > > > c48b9253b6f5d20%7C0%7C0%7C638628924101431762%7CUnknown%7CTWFpbGZs > > b3d8e > > > > > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > > %7C0% > > > > > 7C%7C%7C&sdata=MjURWrvBsrt9zc1ZbqqTrwLIttbKtsBmVLDb4eMS7DM%3D&res > > erved > > > =0 > > > * doc: > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%252> > > Fgith > > > ub.com%2Fboucadair%2FIETF-Drafts- > > Reviews%2Fblob%2Fmaster%2F2024%2Fdraf > > > t-ietf-bess-evpn-bfd-07- > > rev%2520Med.doc&data=05%7C02%7Cmohamed.boucada > > > > > ir%40orange.com%7C0807f9981e1f4fde5f0b08dcdd9f2821%7C90c7a20af34b > > 40bfb > > > > > c48b9253b6f5d20%7C0%7C0%7C638628924101460216%7CUnknown%7CTWFpbGZs > > b3d8e > > > > > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > > %7C0% > > > > > 7C%7C%7C&sdata=mokWM9C4zkeDuGoifnEASA7Pdhhpkvl0vQ5A5SsLHAw%3D&res > > erved > > > =0 > > > > > > Feel free to grab whatever you think useful. > > > > Thanks for all the detailed comments. I will adopt most of them. > > See responses attached. > > > > > Hope this helps. > > > > Yes. While I don't agree with 100% of your comments, I believe > > the ones I have adopted substantially improve the documents. > > > > I will post a revised draft. > > > > Thanks, > > Donald > > =============================== > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > > > > > Cheers, > > > Med > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > >
- [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