Re: [Detnet] Robert Wilton's No Objection on draft-ietf-detnet-oam-framework-10: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Rob,
thank you for your suggestions. I agree with the merge of ## 7 and 8 (with
a minor editorial modification proposed below), and with the removal of #6.
OLD TEXT:
   7.   DetNet OAM MUST support bi-directional DetNet flows.

   8.   DetNet OAM MAY support bi-directional OAM methods for bi-
        directional DetNet flows.  OAM test packets used for monitoring
        and measurements MUST be in-band in both directions.
NEW TEXT:
   6.   DetNet OAM MUST support bi-directional DetNet flows, but is not
        required to support bi-directional OAM methods for bi-
        directional DetNet flows.  DetNet OAM test packets used for
        monitoring and measurements of a bi-directional DetNet flow MUST
        be in-band in both directions.

I'll wait for your feedback before uploading the working version that
combines all the updates addressing comments received in the course of the
IESG review.

Regards,
Greg

On Thu, Jan 4, 2024 at 2:04 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Hi Greg,
>
>
>
> Please see inline …
>
>
>
> *From:* Greg Mirsky <[e-mail]>
> *Sent:* Thursday, January 4, 2024 12:54 AM
> *To:* Rob Wilton (rwilton) <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: Robert Wilton's No Objection on
> draft-ietf-detnet-oam-framework-10: (with COMMENT)
>
>
>
> Hi Rob,
>
> thank you for your kind words and helpful comments. Please find my notes
> below tagged GIM>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 3, 2024 at 4:35 AM Robert Wilton via Datatracker <
> [e-mail]> wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-detnet-oam-framework-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi,
>
> Thanks for this document, I found it easy to read and understand.
>
> I only have some minor comments that may help improve the document:
>
> Minor level comments:
>
> (1) p 6, sec 3.1.  Information Collection
>
>    Information about the state of the network can be collected using
>    several mechanisms.  Some protocols, e.g., Simple Network Management
>    Protocol, send queries.  Others, e.g., YANG-based data models,
>    generate notifications based on the publish-subscribe method.  In
>    either way, information is collected and sent using the DetNet
>    Controller Plane.
>
> A few suggestions:
> 1. For SNMP, perhaps "polls for updated data" rather than "send queries".
>
> GIM>> Thank you! Accepted.
>
> 2. YANG data models don't in themselves generate notifications, but only
> define
> notifications that could be generated when particular events occur.  But
> really, it is protocols, such as YANG Push, that are used to setup
> subscriptions for the data defined in the YANG data models to be published
> either on a periodic basis, or when the underlying data changes.
>
> GIM>> Thank you for the important clarification. Would the following
> update, that benefits from your text, makes it clearer:
>
> OLD TEXT:
>
>    Others, e.g., YANG-based data models,
>
>    generate notifications based on the publish-subscribe method.
>
> NEW TEXT:
>
>    Other protocols, such as YANG-Push
>
>    [RFC8641], can be used to set up subscriptions for the data defined
>
>    in the YANG data models to be published periodically or when the
>
>    underlying data changes.
>
> *[Rob Wilton (rwilton)] *
>
> *Yes, looks good, thanks.*
>
>
> (2) p 10, sec 5.1.  Replication / Elimination
>
>        Figure 1: Packet Replication: S transmits twice the same data
>                          packet, to nodes A and B.
>
> I wasn't really sure what this diagram was intending to convey (i.e., the
> text
> only mentions S, A, and B and none of the other nodes in the diagram).
> E.g.,
> perhaps make is clearer that the desination is R rather than A or B?
>
> GIM>> Would clarifying that in the text and shortening the caption be
> acceptable:
>
> OLD TEXT:
>
>    For instance, in Figure 1, the source device S is
>
>    transmitting a packet to devices A and B.
>
> NEW TEXT:
>
>    For instance, in Figure 1, the source device S
>
>    transmits a packet to devices A and B to reach the destination node
>
>    R.
>
> *[Rob Wilton (rwilton)] *
>
> *Yes, that helps clarify.*
>
>
>
>                         Figure 1: Packet Replication
>
>
> (3) p 11, sec 6.  Requirements
>
>    6.   OAM methods MAY combine in-band monitoring or measurement in the
>         forward direction and out-of-bound notification in the reverse
>         direction, i.e., towards the ingress MEP.
>
> Given that this is "MAY" is doesn't appear to technically be an actual
> requirement, since implementations are not required (or even recommended)
> to
> support it.
>
> GIM>> Would changing the title of the section to Requirements and
> Recommendations (although MAY is not a recommendation either) work?
>
> *[Rob Wilton (rwilton)] *
>
>
>
> *I don’t think that really changes anything.  For 7/8 you could
> potentially combine them: *
>
> *OLD:*
>
>    7.   DetNet OAM MUST support bi-directional DetNet flows.
>
>
>
>    8.   DetNet OAM MAY support bi-directional OAM methods for bi-
>
>         directional DetNet flows.  OAM test packets used for monitoring
>
>         and measurements MUST be in-band in both directions.
>
>
>
> *NEW:*
>
>    7.   DetNet OAM MUST support bi-directional DetNet flows, but are
>
>          not required to support bi-directional OAM methods for bi-
>
>          directional DetNet flows.  OAM test packets used for monitoring
>
>          and measurements MUST be in-band in both directions.
>
>
>
> *For 6, does it need to be stated at all, or would it be better to just
> remove the text?*
>
>
>
> *Regards,*
>
> *Rob*
>
>
>
>
> (4) p 11, sec 6.  Requirements
>
>    8.   DetNet OAM MAY support bi-directional OAM methods for bi-
>         directional DetNet flows.  OAM test packets used for monitoring
>         and measurements MUST be in-band in both directions.
>
> Given that this is "MAY" is doesn't appear to technically be an actual
> requirement, since implementations are not required (or even recommended)
> to
> support it.
>
> Nit level comments:
>
> (5) p 10, sec 6.  Requirements
>
>    2.   It MUST be possible to initiate a DetNet OAM session from using
>         any of DetNet Controller Plane solution, e.g., centralized
>         controller.
>
> Perhaps "by using any of the DetNet Controller Plane solutions"?
>
> GIM>>Yes, the plural is the right form.
>
>
> Regards,
> Rob
>
>
>