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,

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.


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.


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]


On Tue, Apr 13, 2021 at 1:30 PM John Scudder <[e-mail]> wrote:

> Donald,
>
> It being an AD’s prerogative to change his mind :-/ I’d like to discuss
> (if not necessarily DISCUSS, yet) this some more.
>
> Let’s remember what SHOULD means:
>
> 3 <https://tools.ietf.org/html/rfc2119#section-3>. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.
>
>
> It’s basically a MUST with caveats, it doesn’t mean “try your best but if
> you can’t, oh well." Your new text is
>
> EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities.
>> OAM messages SHOULD be encoded so that they exhibit similar entropy
>> characteristics to data traffic in order maximize the fate sharing between
>> OAM and data.
>>
>>
> I’m now scratching my head and wondering how, as an implementor, I’m
> supposed to do this and what the “particular circumstances” are that allow
> me to not do it. If the text just means “gee, it would be awful nice if the
> implementor can figure this out, but if not oh well”, then at the very
> least I think the 2119 keyword isn’t justified, and the language could be
> softened even further as in “It’s desirable for OAM messages to be encoded
> so that…” But that’s so soft, that maybe even better would be to simply
> state that fate-sharing is out of scope (if the authors really can’t
> provide specifics on how to do it).
>
> On the other hand, if you (and your co-authors) *are* able to be more
> specific, then of course the sentence could be replaced with more detailed
> recommendations. The proof of the pudding would be that I SHOULD ;-) be
> able to look at your text and say “ok if I’m using VXLAN then I should set
> the fields in the OAM packet to thus-and-such”. But right now, I think it’s
> neither fish nor fowl.
>
> Thanks,
>
> —John
>
> On Apr 13, 2021, at 10:41 AM, John Scudder <
> jgs=[e-mail]> wrote:
>
> Thanks, Donald. I agree that my discuss and comments are fixed by -09.
>
> —John
>
> On Apr 12, 2021, at 9:08 PM, Donald Eastlake <[e-mail]> wrote:
>
>
>
> Hi John,
>
> I've posted -09 which should resolve your DISCUSS and COMMENTs.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]
>
>
> On Mon, Apr 12, 2021 at 1:38 PM John Scudder <[e-mail]> wrote:
>
>> Thanks for hopping threads, I shoulda caught that last one. Your proposed
>> change looks fine, I’ll remove my DISCUSS in anticipation of you issuing a
>> new version. (One nit on your new text, “in order maximize” should be “in
>> order to maximize”.)
>>
>> —John
>>
>> On Apr 12, 2021, at 1:03 PM, Donald Eastlake <[e-mail]> wrote:
>>
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi,
>>
>> On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker <
>> [e-mail]> wrote:
>> >
>> > John Scudder has entered the following ballot position for
>> > draft-ietf-bess-evpn-oam-req-frmwk-08: Discuss
>> >
>> > ...
>> >
>> > ----------------------------------------------------------------------
>> > DISCUSS:
>> > ----------------------------------------------------------------------
>> >
>> > Section 2.3:
>> >
>> >    EVPN Network OAM mechanisms MUST provide in-band monitoring
>> >    capabilities. As such, OAM messages MUST be encoded so that they
>> >    exhibit identical entropy characteristics to data traffic in order
>> >    that they share the same fate.
>> >
>> > It’s not obvious to me what you mean by “identical entropy
>> characteristics to
>> > data traffic”. Surely, different flows may have different entropy
>> > characteristics, so, *which* data traffic? Similarly, with which data
>> traffic
>> > are you saying the OAM messages must share fate?
>>
>> I guess when you changed your COMMENT to a DISCUSS it creates a new
>> thread so I should reply here as I did to this when it was a COMMENT:
>>
>> How about something more like:
>>
>> EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities.
>> OAM messages SHOULD be encoded so that they exhibit similar entropy
>> characteristics to data traffic in order maximize the fate sharing between
>> OAM and data.
>>
>>
>> > ----------------------------------------------------------------------
>> > COMMENT:
>> > ----------------------------------------------------------------------
>> >
>> > Thanks for the clear and readable document. I have one nit and one
>> question.
>> >
>> > 1. Section 1, nit:
>> >
>> > “EVPN is an Layer 2” s/an/a/
>>
>> OK.
>>
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  [e-mail]
>>
>>
>>
>
>