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

[Greg Mirsky <[e-mail]>]

Hi Lou,
thank you for your kind consideration. I've uploaded the new version with
the update. Please advise on the next step to progress this draft.

Regards,
Greg

On Mon, May 22, 2023 at 12:40 PM Lou Berger <[e-mail]> wrote:

> 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
>>
>