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

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) <
fbrockne@cisco.com> wrote:

> Hi Greg,
>
> Please see inline ("...FB"):
>
>
> From: Greg Mirsky <gregimirsky@gmail.com>
> Sent: Donnerstag, 2. April 2020 00:45
> To: Frank Brockners (fbrockne) <fbrockne@cisco.com>
> Cc: sfc@ietf.org
> 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.
>
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
> 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:
>
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:40cisco.com@dmarc.ietf.org> 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 <mailto:sfc-bounces@ietf.org> On Behalf Of mailto:
> internet-drafts@ietf.org
> > Sent: Donnerstag, 19. März 2020 14:39
> > To: mailto:i-d-announce@ietf.org
> > Cc: mailto:sfc@ietf.org
> > 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
> http://tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > sfc mailing list
> > mailto:sfc@ietf.org
> > https://www.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> mailto:sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>