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

[Lou Berger <[e-mail]>]

Greg,

While a more complete/explicit example would be nice, I do think your 
changes address the core of my comment.

Thank you!

Lou

On 5/18/2023 3:14 PM, Greg Mirsky wrote:
> 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
>