Donald, It being an AD’s prerogative to change his mind :-/ I’d like to discuss (if not necessarily DISCUSS, yet) this some more.
Let’s remember what SHOULD means: 3<https://tools.ietf.org/html/rfc2119#section-3>. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. It’s basically a MUST with caveats, it doesn’t mean “try your best but if you can’t, oh well." Your new text is EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities. OAM messages SHOULD be encoded so that they exhibit similar entropy characteristics to data traffic in order maximize the fate sharing between OAM and data. I’m now scratching my head and wondering how, as an implementor, I’m supposed to do this and what the “particular circumstances” are that allow me to not do it. If the text just means “gee, it would be awful nice if the implementor can figure this out, but if not oh well”, then at the very least I think the 2119 keyword isn’t justified, and the language could be softened even further as in “It’s desirable for OAM messages to be encoded so that…” But that’s so soft, that maybe even better would be to simply state that fate-sharing is out of scope (if the authors really can’t provide specifics on how to do it). On the other hand, if you (and your co-authors) *are* able to be more specific, then of course the sentence could be replaced with more detailed recommendations. The proof of the pudding would be that I SHOULD ;-) be able to look at your text and say “ok if I’m using VXLAN then I should set the fields in the OAM packet to thus-and-such”. But right now, I think it’s neither fish nor fowl. Thanks, —John On Apr 13, 2021, at 10:41 AM, John Scudder <jgs=40juniper....@dmarc.ietf.org<mailto:jgs=40juniper....@dmarc.ietf.org>> wrote: Thanks, Donald. I agree that my discuss and comments are fixed by -09. —John On Apr 12, 2021, at 9:08 PM, Donald Eastlake <d3e...@gmail.com<mailto:d3e...@gmail.com>> wrote: Hi John, I've posted -09 which should resolve your DISCUSS and COMMENTs. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com<mailto:d3e...@gmail.com> On Mon, Apr 12, 2021 at 1:38 PM John Scudder <j...@juniper.net<mailto:j...@juniper.net>> wrote: Thanks for hopping threads, I shoulda caught that last one. Your proposed change looks fine, I’ll remove my DISCUSS in anticipation of you issuing a new version. (One nit on your new text, “in order maximize” should be “in order to maximize”.) —John On Apr 12, 2021, at 1:03 PM, Donald Eastlake <d3e...@gmail.com<mailto:d3e...@gmail.com>> wrote: [External Email. Be cautious of content] Hi, On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: > > John Scudder has entered the following ballot position for > draft-ietf-bess-evpn-oam-req-frmwk-08: Discuss > > ... > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 2.3: > > EVPN Network OAM mechanisms MUST provide in-band monitoring > capabilities. As such, OAM messages MUST be encoded so that they > exhibit identical entropy characteristics to data traffic in order > that they share the same fate. > > It’s not obvious to me what you mean by “identical entropy characteristics to > data traffic”. Surely, different flows may have different entropy > characteristics, so, *which* data traffic? Similarly, with which data traffic > are you saying the OAM messages must share fate? I guess when you changed your COMMENT to a DISCUSS it creates a new thread so I should reply here as I did to this when it was a COMMENT: How about something more like: EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities. OAM messages SHOULD be encoded so that they exhibit similar entropy characteristics to data traffic in order maximize the fate sharing between OAM and data. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for the clear and readable document. I have one nit and one question. > > 1. Section 1, nit: > > “EVPN is an Layer 2” s/an/a/ OK. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com<mailto:d3e...@gmail.com>
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
