Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-ip-oam-12: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Éric,
thank you for your kind words and support of this work. Please find my
notes below tagged GIM>>.

Regards,
Greg

On Mon, Feb 12, 2024 at 8:33 AM Éric Vyncke via Datatracker <
[e-mail]> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-detnet-ip-oam-12: 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-ip-oam/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-detnet-ip-oam-12
>
> Thank you for the work put into this document.
>
GIM>> Thank you for your kind words.

>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and one nit.
>
> Special thanks to János Farkas for the shepherd's detailed write-up
> including
> the WG consensus and the justification of the intended status.
>
> Other thanks to Roman Danyliw as the acting AD ;-)
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # COMMENTS (non-blocking)
>
> ## Section 1
>
> Is the 1st paragraph defining what is OAM a little too light ? Operations
> cover
> more than performance monitoring. But, this is not critical for this I-D.
>
GIM>> Traditionally, OAM is viewed as providing Fault Management and
Performance Monitoring support, i.e., 'F' and 'P' in the FCAPS network
management model. The fault management, in turn, includes tasks of
detection and localization of defects. It seems like all these OAM
functions are called out. One function not mentioned in the document is
protection switchover coordination, e.g., APS. Although APS could be used
in the DetNet forwarding sub-layer, protection of the DetNet service
sub-layer is provided using PREOF and thus is outside the scope of DetNet
OAM.

>
> ## Section 2.1
>
> Should there be a reference for diff serv and ICMPv[46]?
>
GIM>> References to ICMP-defining documents are in Section 3, where the
applicability of ICMP/ICMPv6 in DetNet networks is discussed. Do you think
that is acceptable?

>
> Isn't it a little weird to use in an IP-only document the sentence `MPLS
> networks providing LSP connectivity between DetNet nodes are an example of
> the
> underlay layer` ?
>
GIM>> I think I can see that the definition of the underlay network is not
linked to the case of DetNet IP. Would the following update make it clearer:
OLD TEXT:
   Underlay Network or Underlay Layer: The network that provides
   connectivity between DetNet nodes.  MPLS networks providing LSP
   connectivity between DetNet nodes are an example of the underlay
   layer.
NEW TEXT:
   Underlay Network or Underlay Layer: The network that provides
   connectivity between DetNet nodes.  MPLS networks providing LSP
   connectivity between DetNet nodes are an example of the DetNet IP
   network underlay layer.

>
> ## Section 3
>
> I will let my fellow OPS ADs to chime in, but `OAM protocols and
> mechanisms act
> within the data plane of the particular networking layer` is of course
> applicable for the in-path monitoring part of OAM, but probably not for the
> control part of OAM, e.g., netconf can be in a separate plane.
>
GIM>> I agree that that is a good question for a discussion of what is an
OAM method of measurement, defect detection, on one hand, and a part of the
management plane that can be used to collect data reflecting the
operational state and telemetry information. Personally, I think that some
OAM methods do not require traversing the same set of nodes and links as
the monitored DetNet flow while fulfilling an OAM function, e.g., direct
loss measurement. But the NETCONF, in my opinion, is the realization of the
management plane and can be used to collect operational state and telemetry
information based on data models.

>
> What about the use of IPv6 flow label ? Would it help for the IPv6 flows ?
>
GIM>> Yes, the IPv6 Flow label is a useful mechanism to identify a DetNet
flow. This document describes active DetNet IP OAM for the data plane that
conforms to Section 6 RFC 8939:
   The DetNet data plane encapsulation in a transport network with IP
   encapsulations specified in Section 6 of [RFC8939].
That section, among other requirements, includes one related to the IPv6
Flow Label:
   *  IPv6 Flow Label field.  This field can be optionally used for
      matching.  When used, this field can be used instead of matching
      against the Next Header field.
Would you suggest a text to make the optional use of the IPv6 Flow Label
clearer in this document?

>
> ## Section 3.1
>
> While I am far from being a "flow hash" expert, is it really possible for
> compute UDP ports having the same hash value ? Especially when most
> vendors do
> not make their flow hash algorithms public ?
>
GIM>> You are right and the message that we wanted to convey Using UDP port
numbers to identify a DetNet flow severely complicates the task of applying
active OAM.

>
> To be honest, the intent of sections 3.1 to 3.4 are unclear to me, hence my
> above question.
>
> ## Section 7
>
> I was really about to raise a DISCUSS for this, but it is too trivial to
> fix:
> please either remove this section or add some contents.
>
GIM>> Oops ;) Done.

>
> # NITS (non-blocking / cosmetic)
>
> ## Oxford comma ?
>
> Should there be an Oxford comma in `Administration and Maintenance`?
> Notably in
> the title and other places.
>
GIM>> Thank you for catching this. Fixed throughout the document.