Re: [ippm] Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options

I support this draft for WG adoption. We implemented the option at
hackathon #104 as reported to the WG.

Some replies to Greg points below.

On Thu, Sep 19, 2019 at 11:56 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Authors, et al.,
> I have a number of questions on this draft and hope you'll find time to clarify some aspects of iOAM encapsulation in IPv6 EHs:
>
> format of both Hop-by-Hop Options header and Destination Options header, as defined in RFC 8200, allow the length of Options field in the header to be no more than 2K - 2 octets. I consider that to be an important limitation of the proposed encapsulation method but I don't find that being discussed in the document.

What is the use case for having IOAM data consuming more than 2K bytes?

> Section 3 of your draft defines iOAM Option encapsulation format. How this encapsulation relates to the encapsulation of IPv6 options for the Hop-by-Hop Options header and Destination Options header?

Section 3 describes an option format for IOAM data using canonical
format HBH and DO options. The first two bytes of Option Type and
Option Data Len are straight out of RFC8200.

> Section 4.2 in RFC 8200 defines four types of actions to be associated with the option. Which of these and in what scenarios may be used to carry iOAM information in IPv6 packet?

Section 5 shows shows the act bits in requested IANA assignment to be
00, per RFC8200 "00 - skip over this option and continue processing
the header.". That is appropriate for IOAM.

> Also, in Section 4.2 defined on-bit long flag in the Option Type field to indicate whether option data may change en route. How this flag will be used when iOAM option data encapsulated in IPv6 EHs?

It's used the same way as in other options. If the chg bit is set in
the option then the Option data can change in flight, if it's not set
then the data can't change. I suspect most use cases for IOAM will use
the modifiable option.

> Further, the question of choosing a padding option - Pad1 or PadN? Which these two to be used for iOAM data in IPv6 EHs?
>
Either can be used. The type of option padding is orthogonal to any
particular option. RFC8504 describes limits on option padding that
might be applied, but these are generic and don't need to be mentioned
in this draft.

> With this number of technical issues being underspecified, I don't support the adoption of the draft by IPPM WG. And I feel that it would be more appropriate to ask 6man WG to host this work.

I don't believe it's necessary for this to be in 6man. Definition a
new IPv6 option that is compliant with RFC8200 is pretty
straightforward.

Tom

>
> Regards,
> Greg
>
> On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>>
>> Hello IPPM,
>>
>> This email starts a working group adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options. This document defines the IPv6 option encapsulation for IOAM data. This document was discussed with the 6man WG, which advised that the work be done in ippm, with review by 6man.
>>
>> The documents are available here:
>>
>> https://datatracker.ietf..org/doc/draft-ioametal-ippm-6man-ioam-ipv6-options/
>> https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options-02
>>
>> Please reply to this email by Wednesday, September 25, with your input on whether or not the WG should adopt this document.
>>
>> Best,
>> Tommy (as IPPM co-chair)
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------