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

[Donald Eastlake <[e-mail]>]

Revision -10 just posted has only this change (and the version and
dates bumped).

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Thu, Apr 15, 2021 at 7:24 PM John Scudder <[e-mail]> wrote:
>
> 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]