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

[Lou Berger <[e-mail]>]

Greg,

This version looks ready!

Thank you

Lou

On 10/4/2022 11:59 AM, Greg Mirsky wrote:
> Hi Lou,
> I've switched the reference as you suggested (also removed the 
> unnecessary I've introduced). I've updated the text to reference the 
> DetNet Control Plane with "controller" as an example.
> Many thanks for your patience and help.
>
> Attached are the diff and the working version of the draft.
>
> Regards,
> Greg
>
> On Mon, Oct 3, 2022 at 1:17 PM Lou Berger <[e-mail]> wrote:
>
>     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
>>>>