Re: [ippm] Andrew Alston's Discuss on draft-ietf-ippm-ioam-ipv6-options-09: (with DISCUSS)

[Martin Duke <[e-mail]>]

Andrew,

There's a new version of this draft:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-ipv6-options/

Does it adequately address your DISCUSS?

On Fri, Dec 30, 2022 at 6:11 AM Frank Brockners (fbrockne) <fbrockne=
[e-mail]> wrote:

> Hi Andrew,
>
>
>
> Thanks a lot for your review and comments. Please see inline.
>
>
>
> >
>
> > ----------------------------------------------------------------------
>
> > DISCUSS:
>
> > ----------------------------------------------------------------------
>
> >
>
> > Hi There,
>
> >
>
> > Firstly thanks for the document.  I have two issues I'd like to discuss
> and see
>
> > if we can find some clarity on.
>
> >
>
> > The first stems from RFC8200 Section 4.8 Third Paragraph, which reads:
>
> >
>
> > New hop-by-hop options are not recommended because nodes may be
>
> >    configured to ignore the Hop-by-Hop Options header, drop packets
>
> >    containing a Hop-by-Hop Options header, or assign packets containing
>
> >    a Hop-by-Hop Options header to a slow processing path.  Designers
>
> >    considering defining new hop-by-hop options need to be aware of this
>
> >    likely behavior.  There has to be a very clear justification why any
>
> >    new hop-by-hop option is needed before it is standardized.
>
> >
>
> > I believe that the document potentially needs to spell out a clearer
>
> > justification to meet the requirements laid out in the above text.
>
>
>
> ...FB: The best justification are probably implementations. There are
> several vendor implementations (e.g., from Cisco
> <https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_nman/configuration/15-mt/ip6n-15-mt-book/ioam-ipv6.html>
> and Huawei
> <https://info.support.huawei.com/info-finder/encyclopedia/en/IOAM.html>),
> and probably more interesting here, there are also two open source
> implementations – one in FD.io/VPP
> <https://docs.fd.io/vpp/17.01/ioam_plugin_doc.html> and one in the Linux
> Kernel. IOAM for IPv6 is available from kernel version 5.15 onwards,
> support for in-transit traffic (with v6 in v6) is available since kernel
> version 5.16. Details are found here:
> https://github.com/Advanced-Observability/ioam-linux-kernel. It was the
> Linux kernel implementation that also drove the early allocation for code
> points for v6 options.
>
>
>
> We’d be happy to add a paragraph with those details to the document, but
> are wondering whether such a paragraph would really be appropriate for a
> standards document, given that the information about is really a current
> snapshot and as such pretty temporary. Just let us know whether you feel
> like we should add such a paragraph – and will fit it in.
>
>
>
> >
>
> > The second question relates to dealing with IOAM in the context of
> SRv6.  With
>
> > the HbH option - this is processed on a hop-by-hop basis and, as per
> RFC8200,
>
> > is placed directly after the IPv6 header.  This I don't see as a
> problem.  My
>
> > question comes in the case of the destination option.  In SRv6, where a
> SID is,
>
> > for all intents and purposes, acting like an address - I'd like to see
> some
>
> > text dealing with what happens when the DO is applied in the context of
> the
>
> > SRv6 where the destination address is not a normal address - but rather
> an IPv6
>
> > SID.   Does the router drop the entire packet?  Does the router
> "de-encap" as
>
> > if it were a tunneled packet? Basically - I see a situation where that
> could
>
> > lead to undefined behavior that always makes me nervous.
>
> >
>
> > Could the authors, therefore, expand slightly on how the destination
> option is
>
> > handled in the context of SRv6 and its various flavors?
>
>
>
> …FB: IOAM and its use of a destination option isn’t alone when it comes to
> answering the question of “what is the destination” if deployed along side
> with SRv6. PDM (RFC8250) or Alt-Marking (RFC9343) face similar challenges.
> If IOAM and SRv6 are considered ships in the night, then the original DA
> would be the IOAM decapsulating node and intermediate SR hops should leave
> the IOAM DO untouched. But even then, you could argue that SR policy might
> decide to handle the packet completely differently and the packet might
> never reach the original destination. The only proper way to resolve things
> is to integrate “the two ships”: Combine IOAM and SRv6. Alt-Marking went
> that way (draft-fz-spring-srv6-alt-mark) and IOAM did the same, see
> draft-ali-spring-ioam-srv6. draft-ali-spring-ioam-srv6 integrates IOAM data
> fields into the SRH, rather than carries the IOAM data in another option
> header, and that way avoids the complications with the destination option.
>
>
>
> To address your concern, would it be ok to simply add a reference to the
> document that states:
>
> “Deployments which require both, IOAM and SRv6, SHOULD follow
> draft-ali-spring-ioam-srv6.”?
>
>
>
> Thanks again, Frank
>
>
>
> >
>
> >
>
> >
>
> >
>
>
>