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

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 07 Apr 2021 19:04:46 -0700

John Scudder has entered the following ballot position for
draft-ietf-bess-evpn-oam-req-frmwk-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-oam-req-frmwk/

----------------------------------------------------------------------
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?

----------------------------------------------------------------------
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/

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Apr 2021 13:03:45 -0400

Hi,

On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker <
[email-masked]> wrote:
> ...

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.

OK.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: John Scudder <[email-masked]>
Date: Mon, 12 Apr 2021 17:38:19 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

Hi,

> draft-ietf-bess-evpn-oam-req-frmwk-08: Discuss

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.

OK.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]<mailto:[email-masked]>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 12 Apr 2021 18:30:52 +0000

And as  shared John’s concern, the new text looks like fixing the problem

Thank for having updated the document

-éric

From: iesg <[email-masked]> on behalf of John Scudder <jgs=[email-masked]>
Date: Monday, 12 April 2021 at 19:39
To: Donald Eastlake <[email-masked]>
Cc: Matthew Bocci <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: (with DISCUSS and COMMENT)

—John

Hi,

OK.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 12 Apr 2021 21:08:32 -0400

Hi John,

I've posted -09 which should resolve your DISCUSS and COMMENTs.

Thanks,
Donald

On Mon, Apr 12, 2021 at 1:38 PM John Scudder <[email-masked]> 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 <[email-masked]> wrote:
>
>

---

From: John Scudder <[email-masked]>
Date: Tue, 13 Apr 2021 14:41:17 +0000

Thanks, Donald. I agree that my discuss and comments are fixed by -09.

—John

On Apr 12, 2021, at 9:08 PM, Donald Eastlake <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

Thanks,
Donald

On Mon, Apr 12, 2021 at 1:38 PM John Scudder <[email-masked]<mailto:[email-masked]>> 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

Hi,

OK.

Thanks,
Donald

---

From: John Scudder <[email-masked]>
Date: Tue, 13 Apr 2021 17:30:57 +0000

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

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=[email-masked]<mailto:jgs=[email-masked]>> wrote:

—John

Hi John,

Thanks,
Donald

—John

Hi,

OK.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 15 Apr 2021 13:19:01 -0400

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

Thanks,
Donald

On Tue, Apr 13, 2021 at 1:30 PM John Scudder <[email-masked]> 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.
>
> 3 <https://tools.ietf.org/html/rfc2119#section-3>. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
> 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=[email-masked]> wrote:
>
> On Apr 12, 2021, at 9:08 PM, Donald Eastlake <[email-masked]> wrote:
>
>
>
> Hi John,
>
>> 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:
>>

---

From: John Scudder <[email-masked]>
Date: Thu, 15 Apr 2021 21:40:39 +0000

Hi Donald,

On Apr 15, 2021, at 1:19 PM, Donald Eastlake <[email-masked]<mailto:[email-masked]>> 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 implementor to write their code, or for a customer to tell if the implementation complies with the RFC-to-be.

“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.”  ??

Thanks,

—John

Thanks,
Donald

Thanks,
Donald

On Tue, Apr 13, 2021 at 1:30 PM John Scudder <[email-masked]<mailto:[email-masked]>> wrote:
Donald,

3<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc2119*section-3__;Iw!!NEt6yMaO-gk!TjN78Dsjo7L0tzM_ksgiVqMmUw_K_dcfJvUpVvwwlY7MX-bgZX5MJHys39WyiQ$>. SHOULD

Thanks,

—John

—John

Hi John,

Thanks,
Donald

—John

Hi,

OK.

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 15 Apr 2021 18:35:00 -0400

Hi John,

On Thu, Apr 15, 2021 at 5:40 PM John Scudder <[email-masked]> wrote:
> Hi Donald,
>
> On Apr 15, 2021, at 1:19 PM, Donald Eastlake <[email-masked]> 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
>>  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
>>  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-masked]

>  Thanks,
>
> —John
>
>> Thanks,
>> Donald >
>> =============================== >  Donald E. Eastlake 3rd
>> +1-508-333-2270 (cell) >  2386 Panoramic Circle, Apopka, FL 32703
>> USA >  [email-masked] > > Thanks, > Donald >

---

From: John Scudder <[email-masked]>
Date: Thu, 15 Apr 2021 23:24:33 +0000

Works for me. Thanks for the additional discussion. 

—John

> On Apr 15, 2021, at 6:35 PM, Donald Eastlake <[email-masked]> wrote:
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 15 Apr 2021 22:02:42 -0400

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

Thanks,
Donald