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.boucad...@orange.com> wrote: > Hi Greg, > > > > This works for me. I would s/QoS treatment/forwarding behavior, though. > > > > Thank you. > > > > Cheers, > > Med > > > > *De :* Greg Mirsky <gregimir...@gmail.com> > *Envoyé :* jeudi 26 septembre 2024 18:22 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > *Cc :* Donald Eastlake <d3e...@gmail.com>; rtg-...@ietf.org; bess@ietf.org; > draft-ietf-bess-evpn-bfd....@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.boucad...@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 <d3e...@gmail.com> > > Envoyé : mercredi 25 septembre 2024 22:18 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > > Cc : rtg-...@ietf.org; bess@ietf.org; draft-ietf-bess-evpn- > > bfd....@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 <nore...@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 d3e...@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 mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
