Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-options and RFC4302

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

Cc'ing IPPM as well. 

Frank

> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Shwetha Bhandari (shwethab)
> Sent: Montag, 8. April 2019 14:33
> To: Brian E Carpenter <[e-mail]>; Mark Smith
> <[e-mail]>
> Cc: 6man WG <[e-mail]>
> Subject: Re: draft-ioametal-ippm-6man-ioam-ipv6-options and RFC4302
> 
> Just to clarify on the incremental tracing, draft-ietf-ippm-ioam-data
> [https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05] defines tracing that
> can be achieved in 3 modes:
> 1. Pre-allocated Trace [Section 4.2.1]: that does not change the size of the trace
> option in transit.
> 2. Incremental Trace [Section 4.2.2]: which was designed based on hardware
> prototyping and optimization to insert trace data at fixed offset from the header
> and grow the option in transit.
> 3. We also have another mode of tracing being discussed called Immediate
> export or Post card mode* that has minimal tracing data added to the option.
> 
> Not all encapsulation of IOAM data are expected to recommend/implement all
> the modes of tracing.
> We could not get to the discussion in 6man about incremental trace option,
> please refer to Slide 16 in
> [https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-in-
> situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in-situ-oam-with-
> ipv6-options-00]. Based on feedback we can decide if this option makes sense in
> v6 representation of IOAM trace data at all.
> We will expand the discussion of incremental tracing and the caveats in the next
> revision of draft-ioametal-ippm-6man-ioam-ipv6-deployment.
> 
> Thanks,
> Shwetha
> 
> * Immediate export/Post card mode tracing : does not require the tracing data
> to be carried within the option in the packet, but has instructions on what to
> collect and export with minimal context for correlation.
> draft-ietf-ippm-ioam-data-05 – Immediate export flag draft-song-ippm-
> postcard-based-telemetry
> 
> On 4/8/19, 7:23 AM, "ipv6 on behalf of Brian E Carpenter" <ipv6-
> [e-mail] on behalf of [e-mail]> wrote:
> 
>     Top-posting for one point:
>     As far as I am aware, RFC8200 does *not* state that the
>     option data length must not be changed in a mutable
>     hop-by-hop option.
> 
>     Regards
>        Brian
> 
>     On 08-Apr-19 12:12, Mark Smith wrote:
>     >
>     >
>     > On Mon., 8 Apr. 2019, 09:38 Brian E Carpenter,
> <[e-mail] <mailto:[e-mail]>> wrote:
>     >
>     >     Hi,
>     >
>     >     As far as I understand the IOAM "Incremental Trace Option" and the
>     >     proposed mapping to IPv6 options, the draft seems to imply that an
>     >     IAOM option might get bigger as the packet flows through multiple
>     >     IAOM-aware routers.
>     >
>     >     (In fact I see that this is confirmed explicitly in
>     >     draft-ioametal-ippm-6man-ioam-ipv6-deployment.)
>     >
>     >     That is in direct conflict with RFC4302 (page 26), since the option
>     >     data length is included in the ICV calculation, even if the option
>     >     data is excluded.
>     >
>     >     I don't know if that is a show stopper, but at the very least the draft
>     >     should state that it will break the IPsec Authentication Header mechanism.
>     >
>     >     It will also potentially break PMTUD. Again, I don't know if that really
>     >     matters, but I think it needs to be stated.
>     >
>     >     I also note that this proposal is another good example for
>     >     draft-carpenter-limited-domains. We're getting to the point where
>     >     most proposals for IPv6 extensions are limited-domain protocols.
>     >
>     >
>     >
>     > And even in a limited domain, if the processing behaviour doesn't comply
> with RFC8200, then it isn't IPv6 anymore.
>     >
>     > Protocol specs aren't just packet formats (of course it would be much easier
> for everybody if they were, but then they aren't a protocol - an agreement on
> behaviour.)
>     >
>     >
>     >
>     >     Regards
>     >        Brian Carpenter
>     >
>     >     --------------------------------------------------------------------
>     >     IETF IPv6 working group mailing list
>     >     [e-mail] <mailto:[e-mail]>
>     >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     >     --------------------------------------------------------------------
>     >
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail]
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------