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

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Greg,

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


From: Greg Mirsky <[e-mail]> 
Sent: Donnerstag, 2. April 2020 00:45
To: Frank Brockners (fbrockne) <[e-mail]>
Cc: [e-mail]
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:[e-mail]> 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:[e-mail]> On Behalf Of mailto:[e-mail]
> Sent: Donnerstag, 19. März 2020 14:39
> To: mailto:[e-mail]
> Cc: mailto:[e-mail]
> 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:[e-mail]
> https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
mailto:[e-mail]
https://www.ietf.org/mailman/listinfo/sfc