Re: [RTG-DIR] RtgDir Early review: draft-ietf-detnet-oam-framework

[Greg Mirsky <[e-mail]>]

Dear Tal,
thank you for your kind consideration. I've uploaded the new version and
the authors are ready for the next step in progressing this work.

Regards,
Greg

On Wed, Feb 1, 2023 at 1:49 AM Tal Mizrahi <[e-mail]>
wrote:

> Dear Greg,
>
> Thanks for considering my comments.
> I believe the suggested changes resolve my comments.
>
> Cheers,
> Tal.
>
> On Tue, Jan 31, 2023 at 10:42 PM Greg Mirsky <[e-mail]>
> wrote:
> >
> > Hi Tal,
> > many thanks for your thorough review and thoughtful comments. Please
> find our responses below under the GIM>> tag. Also, the attached diff
> highlights the proposed updates.
> >
> > Best regards,
> > Greg
> >
> > On Thu, Jan 19, 2023 at 2:32 AM Tal Mizrahi <[e-mail]>
> wrote:
> >>
> >> Hello,
> >>
> >> I have been selected to do a routing directorate “early” review of this
> draft.
> >> https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/
> >>
> >> The routing directorate will, on request from the working group chair,
> >> perform an “early” review of a draft before it is submitted for
> >> publication to the IESG. The early review can be performed at any time
> >> during the draft’s lifetime as a working group document. The purpose
> >> of the early review depends on the stage that the document has
> >> reached.
> >>
> >> For more information about the Routing Directorate, please see
> >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> >>
> >> Document: draft-ietf-detnet-oam-framework-07
> >> Reviewer: Tal Mizrahi
> >> Review Date: January 19th, 2023
> >> Intended Status: Informational
> >>
> >> Summary:
> >> This document is basically ready for publication, but has nits that
> >> should be considered prior to being submitted to the IESG.
> >>
> >> Comments:
> >>
> >> The document summarizes the OAM requirements of DetNet networks. The
> >> document provides a good background of the necessary OAM components
> >> and presents the requirements of the OAM solutions.
> >>
> >>> Issues:
> >>>
> >>> - It would be helpful if the abstract would say that the target
> >>>
> >>> audience of this document is the DetNet working group members, and is
> >>>
> >>> intended to be used as a set of requirements for future work in the
> >>>
> >>> DetNet working group.
> >>>
> >>> GIM>> Thank you for the suggestion. Would adding the following
> sentence be helpful?
> >>>
> >>> NEW TEXT:
> >>>
> >>>    The document will
> >>>
> >>>    be used in future work that defines the applicability of and
> extension
> >>>
> >>>    of OAM protocols for a deterministic network.
> >>>
> >>>
> >>> - Section 3 - Operation:
> >>>
> >>>   - For each of the sections 3.2-3.7 it would be helpful if you could
> >>>
> >>> specify how PREOF affects each of these functions. For example,
> >>>
> >>> continuity checking: what happens if MEP A and MEP B are two PREOF
> >>>
> >>> endpoints - is continuity checking performed individually for each of
> >>>
> >>> the PREOF paths, or is PREOF transparent to the CC?
> >>>
> >>> GIM>> Thank you for your thoughtful suggestion. We've added notes in
> Sections 3.2 and 3.3. As CC and CV are used in DetNet forwarding sub-layer,
> PREOF does not affect them. Section 3.4 notes that route tracing, i.e.,
> ping and traceroute, can be used to discover PREOF capabilities. Other
> sections added text referencing CC, CV, and ping/traceroute. Do these
> changes clearly describe the interaction between PREOF and OAM?
> >>>
> >>>   - "information is collected and sent using the DetNet Controller
> >>>
> >>> Plane" - isn't it collected by the management plane? It may be worth
> >>>
> >>> clarifying in the document the exact breakdown between the management
> >>>
> >>> plane and the controller plane in the context of this document.
> >>>
> >>> GIM>> Section 4.4.2 of RFC 8655 defines the DetNet Controller Plane as
> the aggregation of Management and Control Planes. Thus, based on the
> interpretation of the DetNet Controller Plane, the management plane plays
> the essential role in collecting OAM information.
> >>>
> >>>
> >>> - Section 8 - Security Considerations:
> >>>
> >>>   You may want to mention that specifically, the security
> >>>
> >>> considerations of OAM in the context of DetNet are discussed in
> >>>
> >>> Section 9 of [RFC 9055].
> >>>
> >>> GIM>> Thank you for the suggestion. Done.
> >>>
> >>>
> >>> Nits:
> >>>
> >>> GIM>> Thank you for your careful review and pointing out these nits.
> Fixed them all. Please see in the attached diff.
> >>>
> >>> - Section 2.1 [RFC8655]  ==> Section 2.1 of [RFC8655]
> >>>
> >>> - Maintenance Intermediate endPoint (MIP) ==> [according to IEEE
> >>>
> >>> 802.1] Maintenance Intermediate Point (MIP)
> >>>
> >>> - In-band OAM is an active OAM is considered ==> In-band OAM is an
> >>>
> >>> active OAM considered
> >>>
> >>> - therefore, PM is a key topic ==> please add "PM" to the acronym list
> >
> > GIM>> Done
> >>>
> >>> - DetNet service sub-layer functions using a sequence number. ==>
> >>>
> >>> DetNet service sub-layer functions use sequence numbers for PREOF.
> >
> > GIM>> Agree, thank you.
> >>>
> >>> - Control Plane / Controller Plane - please be consistent, or clarify
> >>>
> >>> the difference between the two terms.
> >>>
> >>> GIM>> As noted above, the DetNet Controller Plane is viewed as the
> aggregation of the management and control planes. The reference to the
> control plane is specific to the use of the distributed control model.
> >
> > - perfromence metris ==> performance metrics
> > - systemto ==> system to
> > GIM>> Done and done.
> > - downstream MEP ==> the term is used without definition
> >  GIM>> Updated text as follows:
> >
> >    1.   It MUST be possible to initiate a DetNet OAM session from a MEP
> >         located at a DetNet node towards MEP(s) downstream from that
> >         DetNet node within the given domain at a particular DetNet sub-
> >         layer.
> >
> >
>