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

From: Lizhenbin <[email-masked]>
Date: Thu, 12 Sep 2019 01:14:40 +0000

Agree very much. We also proposed the challenges and the optimization considering when IOAM and SRH are used together in the following draft.

https://datatracker.ietf.org/doc/draft-li-6man-ipv6-sfc-ifit/

That is the reason why we do not think the solution proposed by draft-ioametal-ippm-6man-ioam-ipv6-options is reasonable.

In order for better understanding and discussion, 6MAN WG is copied.

Best Regards,
Zhenbin (Robin)

From: ippm [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Thursday, September 12, 2019 8:31 AM
To: Tommy Pauly <tpauly=[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options

How would the headers look when IOAM is used in conjunction with IPv6 segment routing?  Does the IOAM header and metadata precede or follow the segment routing header?

Thanks,
Anoop

On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> 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://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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Sep 2019 22:14:56 -0400

No, please.
That draft proposes recoding the information from SFC's NSH into some 
other format.  This removes the entire interoperability premise of teh 
NSH work.

Yours,
Joel

On 9/11/2019 9:14 PM, Lizhenbin wrote:
> Agree very much. We also proposed the challenges and the optimization 
> considering when IOAM and SRH are used together in the following draft.
> 
> That is the reason why we do not think the solution proposed by 
> draft-ioametal-ippm-6man-ioam-ipv6-options is reasonable.
> 
> *From:*ippm [mailto:[email-masked]] *On Behalf Of *Anoop Ghanwani
> *Sent:* Thursday, September 12, 2019 8:31 AM
> *To:* Tommy Pauly <tpauly=[email-masked]>
> *Cc:* [email-masked]; IETF IPPM WG 
> <[email-masked]>
> *Subject:* Re: [ippm] Adoption call for 
> draft-ioametal-ippm-6man-ioam-ipv6-options
> 
> How would the headers look when IOAM is used in conjunction with IPv6 
> segment routing?  Does the IOAM header and metadata precede or 
> follow the segment routing header?
> 
> Thanks,
> 
> Anoop
> 
> On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly 
> <tpauly=[email-masked] <mailto:[email-masked]>> 
> 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.
> 
>     https://datatracker.ietf..org/doc/draft-ioametal-ippm-6man-ioam-ipv6-options/
>     <https://datatracker.ietf.org/doc/draft-ioametal-ippm-6man-ioam-ipv6-options/>
>     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)
>     [email-masked] <mailto:[email-masked]>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Sep 2019 11:55:47 -0700

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.
   - 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 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?
   - 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?
   - Further, the question of choosing a padding option - Pad1 or PadN?
   Which these two to be used for iOAM data in IPv6 EHs?

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.

Regards,
Greg

On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> 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.
>
> https://datatracker.ietf.org/doc/draft-ioametal-ippm-6man-ioam-ipv6-options/
> 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)
> [email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Tue, 24 Sep 2019 08:55:06 -0700

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 <[email-masked]> 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=[email-masked]> wrote:
>>
>> Hello IPPM,
>>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 25 Sep 2019 09:19:28 -0700

> On Sep 19, 2019, at 11:55 AM, Greg Mirsky <[email-masked]> wrote:
> 
> Dear Authors, et al.,

We did ask 6man to host this work, but the advise from the group and the 6man chairs was that they wanted the work done in IPPM, with review by 6man.

I do think these review points you bring up are good to clarify and address in the document, and we will make sure that such clarification is made as a working group doc.

Thanks,
Tommy
> 
> Regards,
> Greg
> 
> On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> Hello IPPM,
> 
> https://datatracker.ietf..org/doc/draft-ioametal-ippm-6man-ioam-ipv6-options/ <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 <https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options-02>
> 
> https://www.ietf.org/mailman/listinfo/ippm <https://www.ietf.org/mailman/listinfo/ippm>