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

[Martin Duke <[e-mail]>]

Ping!

On Thu, Mar 2, 2023 at 9:41 AM Martin Duke <[e-mail]> wrote:

> 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
>>
>>
>>
>> >
>>
>> >
>>
>> >
>>
>> >
>>
>>
>>
>