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

[Donald Eastlake]

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

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Thu, Apr 15, 2021 at 7:24 PM John Scudder  wrote:
>
> Works for me. Thanks for the additional discussion.
>
> —John
>
> > On Apr 15, 2021, at 6:35 PM, Donald Eastlake  wrote:
> >
> > [External Email. Be cautious of content]
> >
> >
> > Hi John,
> >
> >> On Thu, Apr 15, 2021 at 5:40 PM John Scudder  wrote:
> >> Hi Donald,
> >>
> >>> On Apr 15, 2021, at 1:19 PM, Donald Eastlake  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   +1-508-333-2270 (cell)
> > 2386 Panoramic Circle, Apopka, FL 32703 USA
> > d3e...@gmail.com
> >
> >> Thanks,
> >>
> >> —John
> >>
> >>> Thanks,
> >>> Donald >
> >>> === >  Donald E. Eastlake 3rd
> >>> +1-508-333-2270 (cell) >  2386 Panoramic Circle, Apopka, FL 32703
> >>> USA >  d3e...@gmail.com > > Thanks, > Donald >
> >>> ===
> >> Donald E. Eastlake 3rd
> >>> +1-508-333-2270 (cell)
> >> 2386 Panoramic Circle, Apopka, FL 32703 USA
> >> d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[John Scudder]

Works for me. Thanks for the additional discussion. 

—John

> On Apr 15, 2021, at 6:35 PM, Donald Eastlake  wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
>> On Thu, Apr 15, 2021 at 5:40 PM John Scudder  wrote:
>> Hi Donald,
>> 
>>> On Apr 15, 2021, at 1:19 PM, Donald Eastlake  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   +1-508-333-2270 (cell)
> 2386 Panoramic Circle, Apopka, FL 32703 USA
> d3e...@gmail.com
> 
>> Thanks,
>> 
>> —John
>> 
>>> Thanks,
>>> Donald >
>>> === >  Donald E. Eastlake 3rd
>>> +1-508-333-2270 (cell) >  2386 Panoramic Circle, Apopka, FL 32703
>>> USA >  d3e...@gmail.com > > Thanks, > Donald >
>>> ===
>> Donald E. Eastlake 3rd
>>> +1-508-333-2270 (cell)
>> 2386 Panoramic Circle, Apopka, FL 32703 USA
>> d3e...@gmail.com
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Donald Eastlake]

Hi John,

On Thu, Apr 15, 2021 at 5:40 PM John Scudder  wrote:
> Hi Donald,
>
> On Apr 15, 2021, at 1:19 PM, Donald Eastlake  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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

>  Thanks,
>
> —John
>
>> Thanks,
>> Donald >
>> === >  Donald E. Eastlake 3rd
>> +1-508-333-2270 (cell) >  2386 Panoramic Circle, Apopka, FL 32703
>> USA >  d3e...@gmail.com > > Thanks, > Donald >
>>  ===
>  Donald E. Eastlake 3rd
>>  +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[John Scudder]

Hi Donald,

On Apr 15, 2021, at 1:19 PM, Donald Eastlake 
mailto:d3e...@gmail.com>> 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
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Tue, Apr 13, 2021 at 1:30 PM John Scudder 
mailto:j...@juniper.net>> 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.
 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 
mailto:jgs=40juniper@dmarc.ietf.org>> 
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 
mailto:d3e...@gmail.com>> wrote:



Hi John,

I've posted -09 which should resolve 

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

[Donald Eastlake]

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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Tue, Apr 13, 2021 at 1:30 PM John Scudder  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 . 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=40juniper@dmarc.ietf.org> 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  wrote:
>
>
>
> Hi John,
>
> I've posted -09 which should resolve your DISCUSS and COMMENTs.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
>
> On Mon, Apr 12, 2021 at 1:38 PM John Scudder  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  wrote:
>>
>>
>> [External Email. Be cautious of content]
>>
>>
>> Hi,
>>
>> On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker <
>> 

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

[John Scudder]

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. 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 
mailto:jgs=40juniper@dmarc.ietf.org>> 
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 
mailto:d3e...@gmail.com>> wrote:



Hi John,

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

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Mon, Apr 12, 2021 at 1:38 PM John Scudder 
mailto:j...@juniper.net>> 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 
mailto:d3e...@gmail.com>> wrote:


[External Email. Be cautious of content]


Hi,

On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker 
mailto:nore...@ietf.org>> 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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com



___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[John Scudder]

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

—John

On Apr 12, 2021, at 9:08 PM, Donald Eastlake 
mailto:d3e...@gmail.com>> wrote:



Hi John,

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

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Mon, Apr 12, 2021 at 1:38 PM John Scudder 
mailto:j...@juniper.net>> 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 
mailto:d3e...@gmail.com>> wrote:


[External Email. Be cautious of content]


Hi,

On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker 
mailto:nore...@ietf.org>> 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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Donald Eastlake]

Hi John,

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

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


On Mon, Apr 12, 2021 at 1:38 PM John Scudder  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  wrote:
>
>
> [External Email. Be cautious of content]
>
>
> Hi,
>
> On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker <
> nore...@ietf.org> 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   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Eric Vyncke (evyncke)]

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

Thank for having updated the document

-éric

From: iesg  on behalf of John Scudder 

Date: Monday, 12 April 2021 at 19:39
To: Donald Eastlake 
Cc: Matthew Bocci , "bess-cha...@ietf.org" 
, "draft-ietf-bess-evpn-oam-req-fr...@ietf.org" 
, The IESG , 
"bess@ietf.org" 
Subject: Re: John Scudder's Discuss on draft-ietf-bess-evpn-oam-req-frmwk-08: 
(with DISCUSS and COMMENT)

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 
mailto:d3e...@gmail.com>> wrote:


[External Email. Be cautious of content]


Hi,

On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker 
mailto:nore...@ietf.org>> 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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com<mailto:d3e...@gmail.com>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[John Scudder]

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 
mailto:d3e...@gmail.com>> wrote:


[External Email. Be cautious of content]


Hi,

On Wed, Apr 7, 2021 at 10:04 PM John Scudder via Datatracker 
mailto:nore...@ietf.org>> 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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess