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

[Greg Mirsky <[e-mail]>]

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.


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

>
> 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!
>
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.



> Thank you,
> Lou
>