Hi Pascal,
thank you for your comments. Please note that OAM protocols perform Fault
Management tasks, e.g., continuity check, connectivity verification.
Examples are CFM/Y.1731, BFD. I think it would be helpful to mention FM
part of OAM in the architecture document. Please consider this update:

Active and hybrid OAM methods require additional bandwidth to perform fault
management and performance monitoring of the DetNet domain. OAM may, for
instance, generate special test probes or add OAM information into the data
packet.

Regards,
Greg

On Mon, Jul 9, 2018 at 6:39 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Hi David :
>
>
>
> I agree with you, but read this sentence:
>
> Active OAM techniques generate test traffic to probe the network;
>
> as if the OAM was necessarily a different frame generated end to end and
> traversing the DetNet Circuit that it probes.
>
> Since some OAM techniques (e.g., draft-ietf-ippm-ioam-data) rely on modifying a packet header, we could generalize “test traffic”.
>
> I’s suggest to expand to:
>
> Active OAM techniques require additional bandwidth for measuring the
> performance of the DetNet network; they may for instance generate separate
> test probes or add modifiable in-situ packet headers;
>
>
>
> Makes sense?
>
>
>
> Pascal
>
> *From:* detnet <detnet-bounces@ietf.org> *On Behalf Of *Black, David
> *Sent:* vendredi 6 juillet 2018 14:29
> *To:* János Farkas <janos.farkas@ericsson.com>; Greg Mirsky <
> gregimirsky@gmail.com>
>
> *Cc:* detnet@ietf.org
> *Subject:* Re: [Detnet] WG LC comments to draft-ietf-detnet-architecture
>
>
>
> >  I think it is natural that we need headroom for active OAM.
>
> >
>
> > The architecture document is intended to be high level. I think OAM is
> in there at the appropriate level.
> >
> > This level of detail would belong to an OAM document.
>
>
>
> I agree that OAM details belong in an OAM document, but a sentence to note
> that active OAM functionality interacts with DetNet’s strict requirements
> for reservations seems germane for an architecture document because it
> involves two different areas of functionality (OAM, reservations).  The OAM
> paragraph in 4.1.1 is:
>
>
>
>    Operations, Administration, and Maintenance (OAM) leverages in-band
>
>    and out-of-band signaling that validates whether the service is
>
>    effectively obtained within QoS constraints.  OAM is not shown in
>
>    Figure 2; it may reside in any number of the layers.  OAM can involve
>
>    specific tagging added in the packets for tracing implementation or
>
>    network configuration errors; traceability enables to find whether a
>
>    packet is a replica, which relay node performed the replication, and
>
>    which segment was intended for the replica.
>
>
>
> The last sentence in that paragraph does not cover Active OAM techniques
> that generate traffic to probe/measure the network.    I might rephrase
> Greg’s sentence to add to the end of that paragraph as:
>
>
>
>    Active OAM techniques generate test traffic to probe the network;
>
>    for DetNet, resources have to be reserved for such test traffic,
>
>    e.g., via headroom in reservations for other DetNet traffic or via
>
>    separate reservations for DetNet OAM traffic.
>
>
>
> Thanks, --David
>
>
>
> *From:* János Farkas [mailto:janos.farkas@ericsson.com
> <janos.farkas@ericsson.com>]
> *Sent:* Wednesday, July 4, 2018 2:16 PM
> *To:* Black, David; Greg Mirsky
> *Cc:* detnet@ietf.org
> *Subject:* Re: [Detnet] WG LC comments to draft-ietf-detnet-architecture
>
>
>
> I think it is natural that we need headroom for active OAM.
>
> The architecture document is intended to be high level. I think OAM is in
> there at the appropriate level.
>
> This level of detail wold belong to an OAM document.
>
> Thanks,
> Janos
>
> On 7/2/2018 4:23 PM, Black, David wrote:
>
> I agree with Greg’s comment – for the architecture draft, it would be good
> to add some text to point out that the ability to use active OAM requires
> some “headroom” in the reservations.
>
>
>
> How to obtain that headroom is a longer discussion, e.g., the network
> operator could enlarge application-originated DetNet reservations to
> include that “headroom,” but that discussion does not need to be fleshed
> out in the architecture draft.  Of course, if the DetNet application and
> network owners/operators are the same entity, this becomes simpler to deal
> with.
>
>
>
> Thanks, --David
>
>
>
> *From:* detnet [mailto:detnet-bounces@ietf.org <detnet-bounces@ietf.org>] *On
> Behalf Of *Greg Mirsky
> *Sent:* Sunday, July 1, 2018 2:41 PM
> *To:* detnet@ietf.org; detnet-chairs@ietf.org; draft-ietf-detnet-
> architecture@ietf.org
> *Subject:* [Detnet] WG LC comments to draft-ietf-detnet-architecture
>
>
>
> Dear Authors, WG Chairs, et. al,
>
> please consider my comments as part of WGLC of draft-ietf-detnet-
> architecture.
>
>    - in the document resource reservation for a detnet service is defined
>    as:
>
>            The set of resources allocated between a source and one or
>
>            more destinations through transit nodes and subnets
>
>            associated with a DetNet flow, to provide the expected DetNet
>
>            Service.
>
>    - traffic characteristics to be used as input to determine required
>    resources for a detnet service are listed in Section 4.2.1.
>    - I believe that in addition to service traffic characteristics
>    resource reservation must accommodate OAM, particularly active OAM methods
>    that inject specially constructed test packets in the detnet domain.
>    If the impact of active OAM is not accounted for in the resource
>    reservation, detnet may experience congestions and/or packet loss. Adding a
>    sentence in the paragraph before last in section 4.1.1 may be sufficient:
>
> Active OAM methods inject test packets into the network and the volume of
> these packets must be considered as one of the inputs for resource
> reservation.
>
>
>
>
>
> Regards,
>
> Greg
>
>
>