[bess] Re: [RTG-DIR]Re: Rtgdir early review of draft-ietf-bess-evpn-bfd-07

[[e-mail]]

Hi Greg,

This works for me. I would s/QoS treatment/forwarding behavior, though.

Thank you.

Cheers,
Med

De : Greg Mirsky <[e-mail]>
Envoyé : jeudi 26 septembre 2024 18:22
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Donald Eastlake <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
> Envoyé : mercredi 25 septembre 2024 22:18
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
> Cc : [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; draft-ietf-bess-evpn-
> [e-mail]<mailto:[e-mail]>
> 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 <[e-mail]<mailto:[e-mail]>> 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<http://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<http://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<http://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<http://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   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA  [e-mail]<mailto:[e-mail]>
>
> > 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.