Re: [Detnet] some comments on draft-ietf-detnet-ip-oam

[Greg Mirsky <[e-mail]>]

Hi Lou,
David, Mach, and I discussed your comments and propose the following update:
OLD TEXT:
   IP OAM protocols that use UDP transport, e.g., BFD [RFC5880] and
   STAMP [RFC8762], can be used to detect failures or performance
   degradation that affects an IP DetNet flow.  When the UDP destination
   port number used by the OAM protocol is one of the assigned by IANA,
   then the UDP source port can be used to achieve co-routedness of OAM,
   and the monitored IP DetNet flow in the multipath environments, e.g.,
   Link Aggregation Group or Equal Cost Multipath.  (That also applies
   to encapsulation techniques described in Section 3.2 and
   Section 3.3.)  To maximize the accuracy of OAM results in detecting
   failures and monitoring performance of IP DetNet, test packets should
   receive the same treatment by the nodes as experienced by the IP
   DetNet packet.  Hence, the DSCP value used for a test packet MUST be
   mapped to DetNet.
NEW TEXT:
   IP OAM protocols are used to detect failures (e.g., BFD [RFC5880])
   and performance degradation (e.g., STAMP [RFC8762]) that affect an IP
   DetNet flow.  When the UDP destination port number used by the OAM
   protocol is one of the assigned by IANA, then the UDP source port can
   be used to achieve co-routedness of OAM, and the monitored IP DetNet
   flow in the multipath environments, e.g., Link Aggregation Group or
   Equal Cost Multipath.  (That also applies to encapsulation techniques
   described in Section 3.2 and Section 3.3.)  To ensure the accuracy of
   OAM results in detecting failures and monitoring the performance of
   IP DetNet, it is essential that test packets not only traverse the
   same path as the monitored IP DetNet flow but also receive the same
   treatment by the nodes, e.g., shaping, filtering, policing, and
   availability of the pre-allocated resources, as experienced by the IP
   DetNet packet.  That correlation between the particular IP OAM
   protocol session and the monitored IP DetNet flow can be achieved
   using the DetNet YANG model [I-D.ietf-detnet-yang].  Each IP OAM
   protocol session is presented as DetNet Application with related
   service and forwarding sub-layers.  The forwarding sub-layer of the
   IP OAM session is identical to the forwarding sub-layer of the
   monitored IP DetNet flow, except for information in the grouping ip-
   header, defined in [I-D.ietf-detnet-yang].

Please let us know if the new text sufficiently addresses your concerns.

Best regards,
Greg


On Sun, Mar 12, 2023 at 2:46 PM Lou Berger <[e-mail]> wrote:

> Authors (WG),
>
> The document seems to be a bit light on how OAM and IP flows are treated
> the same way by a DetNet when an extra encapsulation layer is NOT used
> (see section 3.1). I also don't understand the meaning/rational of:
>
>  > Hence, the DSCP value used for a test packet MUST be mapped to DetNet.
>
> I think it would be very helpful to provide some examples of how the
> detnet yang model could be used to accomplish such aggregation/shared
> traffic treatment.  Is this something you could look into/add?
>
> Thanks,
> Lou
>