Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Works for me. Thanks for the additional discussion. 

—John

> On Apr 15, 2021, at 6:35 PM, Donald Eastlake <[e-mail]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
>> On Thu, Apr 15, 2021 at 5:40 PM John Scudder <[e-mail]> wrote:
>> Hi Donald,
>> 
>>> On Apr 15, 2021, at 1:19 PM, Donald Eastlake <[e-mail]> 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   [phone] (cell)
> 2386 Panoramic Circle, Apopka, FL 32703 USA
> [e-mail]
> 
>> Thanks,
>> 
>> —John
>> 
>>> Thanks,
>>> Donald >
>>> =============================== >  Donald E. Eastlake 3rd
>>> [phone] (cell) >  2386 Panoramic Circle, Apopka, FL 32703
>>> USA >  [e-mail] > > Thanks, > Donald >
>>> ===============================
>> Donald E. Eastlake 3rd
>>> [phone] (cell)
>> 2386 Panoramic Circle, Apopka, FL 32703 USA
>> [e-mail]