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

[Lou Berger <[e-mail]>]

Greg,

I suggest you instead reference RFC8655, the Deterministic Networking 
Architecture. It uses consistent capitalization for the "DetNet 
Controller Plane" term.

I think you still have a few more instances of " centralized/central" 
controller to clarify.

Thanks!

Lou

On 10/3/2022 4:08 PM, Greg Mirsky wrote:
> Hi Lou,
> apologies for missing the normative verbs and necessary updates to 
> "DetNet controller plane" terminology. I've added the reference to 
> draft-ietf-detnet-controller-plane-framework 
> <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework-02> as 
> Informational. A minor question about the capitalization of "DetNet 
> controller plane". It seems like the draft uses 
> capitalization interchangeably. I've used only lower case in the OAM 
> draft. Please let me know if that is acceptable.
>
> Attached, please find the diff and the new working version of the draft.
>
> Regards,
> Greg
>
> On Fri, Sep 30, 2022 at 5:17 AM Lou Berger <[e-mail]> wrote:
>
>     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
>>>