Re: [Detnet] comments on draft-ietf-detnet-oam-framework-06

[Lou Berger <[e-mail]>]

Hi Greg,

see below. I think the version you sent doesn't address everything 
discussed below.

Also - this is important -  please update the draft with a current email 
address for Georgios as his current address bounces. If you don't have 
one, he must be moved to contributor.

On 9/28/2022 12:47 PM, Greg Mirsky wrote:
> Hi Lou,
> thank you for your quick response and helpful suggestions to improve 
> the document. I've applied them all. As usual, I've attached the diff 
> to highlight all the updates and the working version of the draft.
> RE: the number of authors on the first page. I agree with the response 
> you've proposed. I hope that IESG will thoughtfully consider this case.
>
> Regards,
> Greg
>
> On Wed, Sep 28, 2022 at 4:52 AM Lou Berger <[e-mail]> wrote:
>
>     Hi Greg,
>
>         Thanks for the response/update -- please see below.
>
>     On 9/27/2022 5:52 PM, Greg Mirsky wrote:
>>     Hi Lou,
>>     thank you for the review, comments, and helpful suggestions.
>>     Please find my notes and responses inlined below under the GIM>>
>>     tag. Attached is the working version of the draft and the diff
>>     highlighting all updates.
>>
>>     Regards,
>>     Greg
>>
>>     On Fri, Sep 23, 2022 at 11:13 AM Lou Berger <[e-mail]> wrote:
>>
>>         Hi,
>>
>>         In preparing my shepherd write up, I noticed a few
>>         minor/editorial
>>         points that should be addressed before submission for
>>         publication to the
>>         IESG.
>>
>>         - Number of authors:
>>         The IESG requires justification for more than 5 authors
>>         listed on the
>>         font page.  This document has 6.  Is anyone willing to move to
>>         contributor? If not, can you provide a justification for more
>>         than 5
>>         authors
>>
>>     GIM>> I believe that all authors, in the course of developing
>>     this document, provided essential contributions.
>
>     The question that needs to be answered in the Shepherd write up is
>     as follows:
>
>
>     13. ... If the total number of authors and editors on the front page
>         is greater than five, please provide a justification.
>
>     Do you want me to just say?
>
>         The authors believe all listed have provided essential
>     contributions in the course of developing this document.
>
>     Keep in mind the IESG pushes back hard on more than 5 authors. If
>     the authors have a stronger justification, can you (authors)
>     provide it.
>
I will try, but I expect that we will receive strong push back on this.


>>
>>         - Inclusion of conformance boilerplate (Section 1.3) and
>>         conformance
>>         language.
>>
>>         Generally informational documents do not include the conformance
>>         boilerplate or related language.  For example, there is none
>>         in the
>>         DetNet framework, RFC8939.  On the other hand RFC 4377, OAM
>>         Requirements
>>         for MPLS Networks, does.
>>
>>         Is there really a need for such in this document? If you do,
>>         the scope
>>         of the requirement needs to be clear. (E.g, the requirements
>>         are on
>>         future solutions "DetNet OAM solutions MUST..." or "solutions
>>         providing
>>         DetNet OAM MUST..."). Or perhaps just a statement to this
>>         effect at the
>>         end of section 1.3 or start of section 6.
>>
>>      GIM>>  I propose appending Section 1.3 with the following:
>>        The requirements language in Section 6
>>        applies to future implementations of DetNet OAM.
>
>     How about
>
>     The requirements language is used in Section 6 and applies to
>     future implementations of DetNet OAM.
>
I still see requirements terms in sections other than 6 in the version 
you sent out, e.g.,

   3.  Operation

    OAM features will enable DetNet with robust operation both for
    forwarding and routing purposes.

    It is worth noting that the test and data packets MUST follow the
    same path, i.e., the connectivity verification has to be conducted
    in-band without impacting the data traffic.  Test packets MUST share
    fate with the monitored data traffic without introducing congestion
    in normal network conditions.

>>
>>         Section 3-5 I really don't see the need for conformance
>>         language in this
>>         section.
>>
>>     GIM>> Upon reviewing the last paragraph, propose to remove it
>>     altogether:
>>     OLD TEXT:
>>        DetNet OAM mechanisms SHOULD allow a fault detection in real time.
>>        They MAY, when possible, predict faults based on current network
>>        conditions.  They MAY also identify and report the cause of the
>>        actual/predicted network failure.
>>
>>
>>         - Section 3.4, s/NOT RECOMMENDED/expected
>>
>>     GIM>> We've discussed this and propose the following update:
>>      OLD TEXT:
>>        DetNet is not expected to use multiple paths or links, i.e.,
>>     Equal-
>>        Cost Multipath (ECMP) [RFC8939].  As the result, OAM in ECMP
>>        environment is outside the scope of this document.
>>     NEW TEXT
>>        DetNet is not expected to use Equal-Cost Multipath (ECMP)
>>     [RFC8939].
>>        As the result, DetNet OAM in ECMP environment is outside the
>>     scope of this
>>        document.
>>
>>
>>         - Section 5.2
>>         Can you rephrase/clarify the following sentence.  I frankly
>>         have no idea
>>         what is meant by it:
>>
>>              We need to provide mechanisms to patch the network
>>             configuration.
>>
>>     GIM>> Thank you for pointing out this sentence to us. It is not
>>     really related to OAM but seems more in place in a discussion of
>>     the management plane. Hence, propose removing the sentence.
>>
>>
>>         That's it!
>>
>     The above all looks good -- thanks!
>
>>     GIM>> In the course of addressing your comments, we've come up
>>     with several more editorial updates. Please let us know if these
>>     are helpful:
>>     In Section 4:
>>     OLD TEXT
>>        *  per path to detect misbehaving path when multiple paths are
>>           applied.
>>     NEW TEXT
>>        *  per path to detect misbehaving path(s) when multiple paths are
>>           used for service protection.
>>
>>     In Section 5, prepend the following new text to the first paragraph:
>>     NEW TEXT:
>>        Service protection (provided by the DetNet service sub-layer)
>>     is designed
>>        to cope with simple network failures, and it mitigates the
>>     immediate reaction
>>        of the DetNet controller to network events.
>>
>     What about the case where a controller is not used? Do you perhaps
>     mean "DetNet Controller Plane"?
>
Note this is a general comment: The document mentions controller in many 
places.  To be consistent with the DetNet Architecture the document 
should allow for any 'Controller Plane' solution.  This should be easily 
fixed,  starting in section 2.

Thank you,

Lou

>     Lou
>
>>
>>
>>         Thank you,
>>         Lou
>>