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

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

Hi Greg,

Please see inline (…FB2) and sorry for the delay.

From: Greg Mirsky <[e-mail]>
Sent: Dienstag, 7. April 2020 19:40
To: Frank Brockners (fbrockne) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: 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) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

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


From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: Donnerstag, 2. April 2020 00:45
To: Frank Brockners (fbrockne) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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.
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?

…FB2: This is a good question. We might even ask the question more broadly – i.e. in the context of SFC OAM.
SFC OAM could benefit from the active flag – in NSH, we have the O-bit to qualify traffic as OAM, but what about non-NSH deployments?
Similarly, loopback could play a role in defining a SFC traceroute solution (as defined in sfc-oam-framework, section 6.4.4) – though it would obviously be only one potential ingredient of a larger solution that could be defined as one of the SFC OAM solutions drafts.
Are you thinking of coming up with such a solution?


• 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.
…FB2: Per what I mentioned above: After a series of discussions we arrived at a solution and I don’t see need to revisit the discussion just because we have another IOAM-Option-Type to be considered. IMHO it is not helpful but rather confusing to have different encapsulations for different types of IOAM option types (i.e. use different encaps for IOAM-Trace-Option-Type and IOAM-Direct-Export-Option-Type).

Cheers, Frank


Cheers, Frank

Regards,
Greg

On Thu, Mar 19, 2020 at 6:49 AM Frank Brockners (fbrockne) <fbrockne=mailto:[e-mail]<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]<mailto:[e-mail]>> On Behalf Of mailto:[e-mail]<mailto:[e-mail]>
> Sent: Donnerstag, 19. März 2020 14:39
> To: mailto:[e-mail]<mailto:[e-mail]>
> Cc: mailto:[e-mail]<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]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sfc

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