Subject: Re: [sfc] I-D Action: draft-ietf-sfc-ioam-nsh-03.txt

From: Greg Mirsky <[email-masked]>
Date: Wed, 1 Apr 2020 15:45:28 -0700

Hi Frank, et al.,
thank you for the updates. I have a couple of questions and appreciate if
you and the WG consider them:

   - in the Introduction, the term "in-situ" is explained as follows:

   The term "in-situ" refers to the fact
   that the OAM data is added to the data packets rather than is being
   sent within packets specifically dedicated to OAM.

That is reasonable since the draft only references draft-ietf-ippm-ioam-data
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/>. As those,
following work on iOAM in IPPM WG, know several new iOAM behaviors,
e.g., Direct
Export
<https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/>,
Loopback <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/> and
Active, have been defined in new IPPM WG drafts. Are these behaviors
applicable to iOAM in SFC NSH?

   - the second question is related to the discussion of the iOAM
   encapsulation in NSH. I couldn't find explicitly stated requirements that
   are based on quantitative metrics. The text refers to "large networks",
   "can grow quite large" and alike. Do we have an example of a large SFC
   network? And if the size of MD Type 2 meta-data might be limiting in some
   scenarios, iOAM now has defined the Direct Export mode that supports the
   collection of any practical information from each iOAM node. I think that
   the use of the Direct Export or other methods that collect iOAM information
   in a dedicated packet can be recommended. As a result, the choice of the
   iOAM encapsulation in NSH can be re-considered.

Regards,
Greg

On Thu, Mar 19, 2020 at 6:49 AM Frank Brockners (fbrockne) <fbrockne=
[email-masked]> wrote:

> Quick update: I've just posted a new revision of draft-ietf-sfc-ioam-nsh.
>
> This update includes editorial fixes only - mainly an alignment to the
> nomenclature used in draft-ietf-ippm-ioam-data.
>
> Are there any further comments on this draft? Are we ready to move to WG
> LC?
>
> Thanks, Frank
>
> > -----Original Message-----
> > From: sfc <[email-masked]> On Behalf Of [email-masked]
> > Sent: Donnerstag, 19. März 2020 14:39
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: [sfc] I-D Action: draft-ietf-sfc-ioam-nsh-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Service Function Chaining WG of the
> IETF.
> >
> >         Title           : Network Service Header (NSH) Encapsulation for
> In-situ OAM
> > (IOAM) Data
> >         Authors         : Frank Brockners
> >                           Shwetha Bhandari
> >       Filename        : draft-ietf-sfc-ioam-nsh-03.txt
> >       Pages           : 9
> >       Date            : 2020-03-19
> >
> > Abstract:
> >    In-situ Operations, Administration, and Maintenance (IOAM) records
> >    operational and telemetry information in the packet while the packet
> >    traverses a path between two points in the network.  This document
> >    outlines how IOAM data fields are encapsulated in the Network Service
> >    Header (NSH).
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-sfc-ioam-nsh-03
> > https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-03
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-03
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > sfc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 6 Apr 2020 08:46:02 +0000

Hi Greg,

Please see inline ("...FB"):

From: Greg Mirsky <[email-masked]> 
Sent: Donnerstag, 2. April 2020 00:45
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-ioam-nsh-03.txt

Hi Frank, et al.,
thank you for the updates. I have a couple of questions and appreciate if you and the WG consider them:
• in the Introduction, the term "in-situ" is explained as follows:
   The term "in-situ" refers to the fact
   that the OAM data is added to the data packets rather than is being
   sent within packets specifically dedicated to OAM.
That is reasonable since the draft only references https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/. As those, following work on iOAM in IPPM WG, know several new iOAM behaviors, e.g., https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/, https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ and Active, have been defined in new IPPM WG drafts. Are these behaviors applicable to iOAM in SFC NSH?

...FB: Thanks to your review comments on draft-ietf-ippm-ioam-data, the latest draft draft-ietf-ippm-ioam-data-09 already touches on the fact that the term "In-situ OAM" has evolved and is no longer referring to the exclusive use of piggybacking OAM information onto live customer traffic as the packet traverses the network (see the introduction section of draft-ietf-ippm-ioam-data-09). It makes sense to harmonize the intro in draft-ietf-sfc-ioam-nsh with draft-ietf-ippm-ioam-data-09.
And to your question: I could see e.g. direct export useful to IOAM deployments which use NSH encapsulation.  

• the second question is related to the discussion of the iOAM encapsulation in NSH. I couldn't find explicitly stated requirements that are based on quantitative metrics. The text refers to "large networks", "can grow quite large" and alike. Do we have an example of a large SFC network? And if the size of MD Type 2 meta-data might be limiting in some scenarios, iOAM now has defined the Direct Export mode that supports the collection of any practical information from each iOAM node. I think that the use of the Direct Export or other methods that collect iOAM information in a dedicated packet can be recommended. As a result, the choice of the iOAM encapsulation in NSH can be re-considered.

...FB: We can include some sample quantitative calculations to point out the limitations - which might be better than calling out an explicit example network deployment, which could be inappropriate for a spec. To illustrate the problem why approach #1 in section 4.1 is challenging, we can include some quantitative figures, like the following case: 
IOAM tracing with node-id in wide format (8), egress/ingress interface in wide format (8), timestamp second (4) and subsecond (4), buffer occupancy (4), transit delay (4). This would require a total of 4 + n*32 octets. If you're space-limited to 256 bytes, you can record at most 7 hops.
In case you'd add namespace-specific-data in wide format (8) to the above example, then you'd be down to 6 hops if you need to fit things into 256 bytes. 
I don't think there is a need to reconsider the choice of the IOAM encapsulation for NSH. The WG discussed the topic in several meetings and the current text is what we arrived at. I don't think that anything has changed that would require us to re-open the discussion.

Cheers, Frank

Regards,
Greg

On Thu, Mar 19, 2020 at 6:49 AM Frank Brockners (fbrockne) <fbrockne=mailto:[email-masked]> wrote:
Quick update: I've just posted a new revision of draft-ietf-sfc-ioam-nsh.

This update includes editorial fixes only - mainly an alignment to the nomenclature used in draft-ietf-ippm-ioam-data.

Are there any further comments on this draft? Are we ready to move to WG LC?

Thanks, Frank

> From: sfc <mailto:[email-masked]> On Behalf Of mailto:[email-masked]
> To: mailto:[email-masked]
> Cc: mailto:[email-masked]
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Service Function Chaining WG of the IETF.
> 
>         Title           : Network Service Header (NSH) Encapsulation for In-situ OAM
> (IOAM) Data
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at http://tools.ietf.org.
> 
> mailto:[email-masked]

mailto:[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 7 Apr 2020 10:40:02 -0700

Hi Frank,
thank you for your consideration of my comments and for sharing your views.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Mon, Apr 6, 2020 at 1:46 AM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> That is reasonable since the draft only references
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/. As those,
> following work on iOAM in IPPM WG, know several new iOAM behaviors, e.g.,
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/,
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-flags/ and Active,
> have been defined in new IPPM WG drafts. Are these behaviors applicable to
> iOAM in SFC NSH?
>
> ...FB: Thanks to your review comments on draft-ietf-ippm-ioam-data, the
> latest draft draft-ietf-ippm-ioam-data-09 already touches on the fact that
> the term "In-situ OAM" has evolved and is no longer referring to the
> exclusive use of piggybacking OAM information onto live customer traffic as
> the packet traverses the network (see the introduction section of
> draft-ietf-ippm-ioam-data-09). It makes sense to harmonize the intro in
> draft-ietf-sfc-ioam-nsh with draft-ietf-ippm-ioam-data-09.
GIM>> Thank you.  I appreciate that the updated draft-ietf-ippm-ioam-data
now explicitly refers to the DEX mode. Probably a similar reference is
suitable for the NSH iOAM draft. Do you think it should be in the normative
references list? Also, draft-ietf-ippm-ioam-flags defines new behaviors,
e.g., Loopback and Active. Are these applicable to iOAM in SFC NSH?

>
>
> • the second question is related to the discussion of the iOAM
> ...FB: We can include some sample quantitative calculations to point out
> the limitations - which might be better than calling out an explicit
> example network deployment, which could be inappropriate for a spec. To
> illustrate the problem why approach #1 in section 4.1 is challenging, we
> can include some quantitative figures, like the following case:
>
GIM>> Thank you. Looking forward to the update. Will be much obliged if you
can share the text before it is published.

> IOAM tracing with node-id in wide format (8), egress/ingress interface in
> wide format (8), timestamp second (4) and subsecond (4), buffer occupancy
> (4), transit delay (4). This would require a total of 4 + n*32 octets. If
> you're space-limited to 256 bytes, you can record at most 7 hops.
> In case you'd add namespace-specific-data in wide format (8) to the above
> example, then you'd be down to 6 hops if you need to fit things into 256
> bytes.
>
GIM>> Indeed, 256 bytes is a limit that an operator should consider. And
the operator can choose the proper mode to collect iOAM data, in-the-packet
or DEX, based on that consideration.

> I don't think there is a need to reconsider the choice of the IOAM
> encapsulation for NSH. The WG discussed the topic in several meetings and
> the current text is what we arrived at. I don't think that anything has
> changed that would require us to re-open the discussion.
>
GIM>> I think that the work on the DEX mode is an important development
that requires a new discussion and reconsideration of how
iOAM encapsulated in SFC NSH by the working group.

>
> Cheers, Frank
>
> Regards,
> Greg
>
> On Thu, Mar 19, 2020 at 6:49 AM Frank Brockners (fbrockne)
> <fbrockne=mailto:[email-masked]> wrote: