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
