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

[Martin Duke <[e-mail]>]

ping!

On Wed, Mar 8, 2023 at 9:33 AM Martin Duke <[e-mail]> wrote:

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