Revision -10 just posted has only this change (and the version and dates bumped).
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Thu, Apr 15, 2021 at 7:24 PM John Scudder <[email protected]> wrote: > > Works for me. Thanks for the additional discussion. > > —John > > > On Apr 15, 2021, at 6:35 PM, Donald Eastlake <[email protected]> wrote: > > > > [External Email. Be cautious of content] > > > > > > Hi John, > > > >> On Thu, Apr 15, 2021 at 5:40 PM John Scudder <[email protected]> wrote: > >> Hi Donald, > >> > >>> On Apr 15, 2021, at 1:19 PM, Donald Eastlake <[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 implementer to write their code, or for a customer to tell if the > >> implementation complies with the RFC-to-be. > > > > I agree. > > > >> “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.” ?? > > > > Something close to that is fine with me. I think it should refer to > > "OAM test messages" or the like -- I don't think this applies exactly > > to OAM control messages. So I would say > > > > "It is desirable, to the extent practical, for OAM test messages > > to share fate with data messages. Details of how to achieve this > > are beyond the scope of this document." > > > > Thanks, > > Donald > > ============================= > > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > > 2386 Panoramic Circle, Apopka, FL 32703 USA > > [email protected] > > > >> Thanks, > >> > >> —John > >> > >>> Thanks, > >>> Donald > > >>> =============================== > Donald E. Eastlake 3rd > >>> +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 > >>> USA > [email protected] > > Thanks, > Donald > > >>> =============================== > >> Donald E. Eastlake 3rd > >>> +1-508-333-2270 (cell) > >> 2386 Panoramic Circle, Apopka, FL 32703 USA > >> [email protected] _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
