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

[Donald Eastlake <[e-mail]>]

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]