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

[Greg Mirsky <[e-mail]>]

Hi Frank,
my apologies for the terribly late response. Please find my notes in-line,
now under GIM2>> tag.

Stay well. Stay safe.

Regards,
Greg

On Tue, May 5, 2020 at 12:25 AM Frank Brockners (fbrockne) <
[e-mail]> wrote:

> 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]> wrote:
>
> 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.
>
> 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?*
>
GIM>> I think I have a somewhat different view on O-bit in NSH in
particular and on the identification of active OAM in overlay networks in
general. iOAM, in my view, is a useful and powerful on-path OAM mechanism
but I'd not stretch it into the area of active OAM protocols. Besides, I'm
the co-author of the WG draft that proposes SFC NSH-based echo
request/reply and several individual drafts that are enhancing SFC NSH OAM
using that mechanism.

>
>
> • 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).*
>
GIM2>> Of course, this is my personal opinion and WG and WG chairs will
decide. I consider using NSH's variable-length context header as more
secure and more service-friendly. Let's consider a scenario when an
NSH-encapsulated packet arrives at the final SFF that does not support iOAM
in NSH. The packet will be dropped if it uses the currently selected
option. But if iOAM is placed in the variable-length context header, the
SFF will merely remove NSH and process the payload accordingly. True, to
collect on-path information over longer SFPs may require using DEX. And to
make things simpler the recommendation might be to use the variable-length
header only for proof-of-transit and DEX for all other cases.

>
>
> *Cheers, Frank*
>
>
>
>
> 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
>
>