Hi Donald, On Apr 15, 2021, at 1:19 PM, Donald Eastlake <[email protected]<mailto:[email protected]>> wrote:
Hi John, First, an aside: RECOMMEND really isn't the same as SHOULD no matter what the RFCs say. As any native English speaker knows, "recommend" is weaker than "should" and pretty much everyone, including ADs, usually treats it as such. I pretty regularly see AD comments about how "should" is almost "must" and authors need to say something about when you can violate the "should" etc. On the other hand, while I'm sure it has happened, I don't recall ever seeing such comments about "recommend". So I think the RFCs should be adjusted to correspond to actual practice. But, of course, none of this has anything to do with what you want to talk about. I look forward to your draft to update RFC 2119! How about: EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities. Such OAM messages SHOULD be encoded so that they exhibit similar characteristics to data traffic in order maximize the fate sharing between OAM and data: they SHOULD have a similar distribution of packet lengths, header fields and flags SHOULD have the value or values present in data packets, and bit patterns in much of the OAM packets should be similar to data. However this might not all be possible or practical: Delivery of OAM traffic to nodes that will erroneously process it as data intended for that node is normally worse that deviation from congruence with data; furthermore, there will be restrictions for proper processing of OAM typically including minimum length and value of some header field or flag that require some deviation from data; and, some characteristics of data flows that are or will be encountered may be unpredictable making it impossible or impractical to adjust OAM packets as herein advised. Let me be blunt: do you need to say anything at all about this? As far as I can tell the additional words didn’t make it any easier for an implementor to write their code, or for a customer to tell if the implementation complies with the RFC-to-be. “To the extent practicable, it is desirable for OAM messages to share fate with data. Details of how to achieve this are beyond the scope of this document.” ?? Thanks, —John Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected]<mailto:[email protected]> Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected]<mailto:[email protected]> On Tue, Apr 13, 2021 at 1:30 PM John Scudder <[email protected]<mailto:[email protected]>> wrote: 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc2119*section-3__;Iw!!NEt6yMaO-gk!TjN78Dsjo7L0tzM_ksgiVqMmUw_K_dcfJvUpVvwwlY7MX-bgZX5MJHys39WyiQ$>. 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> On Mon, Apr 12, 2021 at 1:38 PM John Scudder <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: [External Email. Be cautious of content] Hi, On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
