[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.
>
>