Subject: [Detnet] WG LC comments to draft-ietf-detnet-architecture

From: Greg Mirsky <[email-masked]>
Date: Sun, 1 Jul 2018 11:40:42 -0700

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

---

From: "Black, David" <[email-masked]>
Date: Mon, 2 Jul 2018 14:23:54 +0000

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:[email-masked]] On Behalf Of Greg Mirsky
Sent: Sunday, July 1, 2018 2:41 PM
To: [email-masked]; [email-masked]; [email-masked]
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

---

From: János Farkas <[email-masked]>
Date: Wed, 4 Jul 2018 20:15:34 +0200

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:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Sunday, July 1, 2018 2:41 PM
> *To:* [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* [Detnet] WG LC comments to draft-ietf-detnet-architecture
>
>   * traffic characteristics to be used as input to determine required
>   * I believe that in addition to service traffic characteristics
>     resource reservation must accommodate OAM, particularly active OAM
>     methods that inject specially constructedtest 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
>

---

From: "Black, David" <[email-masked]>
Date: Fri, 6 Jul 2018 21:28:35 +0000

> 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:[email-masked]]
Sent: Wednesday, July 4, 2018 2:16 PM
To: Black, David; Greg Mirsky
Cc: [email-masked]
Subject: Re: [Detnet] WG LC comments to draft-ietf-detnet-architecture

The architecture document is intended to be high level. I think OAM is in there at the appropriate level.

Thanks,
Janos

Thanks, --David

From: detnet [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Sunday, July 1, 2018 2:41 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] WG LC comments to draft-ietf-detnet-architecture

Regards,
Greg

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Jul 2018 13:39:40 +0000

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 <[email-masked]> On Behalf Of Black, David
Sent: vendredi 6 juillet 2018 14:29
To: János Farkas <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [Detnet] WG LC comments to draft-ietf-detnet-architecture

Thanks, --David

Cc: [email-masked]<mailto:[email-masked]>

Thanks,
Janos

Thanks, --David

Regards,
Greg

---

From: "Black, David" <[email-masked]>
Date: Mon, 9 Jul 2018 14:57:16 +0000

That text change is fine with me.

Thanks, --David

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Monday, July 9, 2018 9:40 AM
To: Black, David; János Farkas; Greg Mirsky
Cc: [email-masked]
Subject: RE: [Detnet] WG LC comments to draft-ietf-detnet-architecture

Hi David :

Makes sense?

Pascal

From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Black, David
Sent: vendredi 6 juillet 2018 14:29
To: János Farkas <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] WG LC comments to draft-ietf-detnet-architecture

Thanks, --David

Thanks,
Janos

Thanks, --David

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 9 Jul 2018 08:12:32 -0700

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) <
[email-masked]> wrote:

> as if the OAM was necessarily a different frame generated end to end and
> traversing the DetNet Circuit that it probes.
>
> 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 <[email-masked]> *On Behalf Of *Black, David
> *Sent:* vendredi 6 juillet 2018 14:29
> *To:* János Farkas <[email-masked]>; Greg Mirsky <
> [email-masked]>
>
> *Cc:* [email-masked]
> *Subject:* Re: [Detnet] WG LC comments to draft-ietf-detnet-architecture
>
>
>
> 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:
>
>
>
> 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:
>
>
>
> *From:* János Farkas [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, July 4, 2018 2:16 PM
> *To:* Black, David; Greg Mirsky
> *Cc:* [email-masked]
> *Subject:* Re: [Detnet] WG LC comments to draft-ietf-detnet-architecture
>
>
>
> 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.
>
>
>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *Greg Mirsky
> *To:* [email-masked]; [email-masked]; draft-ietf-detnet-
> [email-masked]
>    - 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:
>