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

From: Tommy Pauly <[email-masked]>
Date: Wed, 11 Sep 2019 09:10:41 -0700

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)

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 11 Sep 2019 16:35:44 +0000

I support adoption of the two documents as WG documents (as co-author).

Frank

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Mittwoch, 11. September 2019 18:11
> To: IETF IPPM WG <[email-masked]>
> Cc: [email-masked]
> Subject: Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options
> 
> 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.
> 
> 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)

---

From: "Ramesh Sivakolundu (sramesh)" <[email-masked]>
Date: Wed, 11 Sep 2019 18:14:22 +0000

I support the adoption of the two documents listed as WG documents.

-Ramesh

On 9/11/19, 9:11 AM, "ippm on behalf of Tommy Pauly" <[email-masked] on behalf of tpauly=[email-masked]> wrote:

    Hello IPPM,

    

    Best,
    Tommy (as IPPM co-chair)
    _______________________________________________
    ippm mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ippm

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 11 Sep 2019 18:24:14 +0000

Support. 

Cheers,
Rajiv  

> On Sep 11, 2019, at 12:11 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hello IPPM,
>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Wed, 11 Sep 2019 18:36:33 +0000

Support.

Regards,
Nagendra

On 9/11/19, 12:11 PM, "ippm on behalf of Tommy Pauly" <[email-masked] on behalf of tpauly=[email-masked]> wrote:

    Hello IPPM,

    

    Best,
    Tommy (as IPPM co-chair)

---

From: Mickey Spiegel <[email-masked]>
Date: Wed, 11 Sep 2019 15:57:27 -0700

Support (as co-author).

Mickey

On Wed, Sep 11, 2019 at 9:11 AM Tommy Pauly <[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.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 12 Sep 2019 00:03:53 +0000

This is an important encapsulation for IOAM data fields in IPv6, and as such support adoption of this document. IOAM Data is adopted, and this makes it real for IPv6 deployments.

(As co-author)

Best,

Carlos.

> On Sep 11, 2019, at 12:10 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hello IPPM,
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 11 Sep 2019 17:30:53 -0700

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

---

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,

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

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
> 
> 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,
> 
>     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: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Thu, 12 Sep 2019 03:43:22 +0000

Support progressing the two documents as WG drafts.

Thanks
Prasad

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

---

From: Aviv Kfir <[email-masked]>
Date: Thu, 12 Sep 2019 07:28:59 +0000

Support

-----Original Message-----
From: Vengada Prasad Govindan (venggovi) <[email-masked]> 
Sent: Thursday, September 12, 2019 6:43 AM
To: Frank Brockners (fbrockne) <[email-masked]>; [email-masked]; IETF IPPM WG <[email-masked]>
Cc: [email-masked]
Subject: RE: Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options

Thanks
Prasad

> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ioametal-ippm-6man-ioam-ipv6-op&amp;dat
> a=02%7C01%7Cavivk%40mellanox.com%7C4c481365d2a0470adc9708d737337a4a%7C
> a652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C637038566545244045&amp;sdat
> a=2xeqiwJvbf0e%2BSx4Bo8wVjYJkkJZijWvTr7Y03Zojls%3D&amp;reserved=0
> tions/
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-ioametal-ippm-6man-ioam-ipv6-options&amp;dat
> a=02%7C01%7Cavivk%40mellanox.com%7C4c481365d2a0470adc9708d737337a4a%7C
> a652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C637038566545244045&amp;sdat
> a=IBkxiv%2Fs7wLjnH1lOpkzIjUxM2lu4fuLMi2EV7k37S0%3D&amp;reserved=0
> -02
> 

_______________________________________________
ippm mailing list
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=02%7C01%7Cavivk%40mellanox.com%7C4c481365d2a0470adc9708d737337a4a%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C1%7C637038566545244045&amp;sdata=e4sCKuukQWmGe0SoVDOOBYNNT2iZosaO85exNMUdSH8%3D&amp;reserved=0

---

From: Justin Iurman <[email-masked]>
Date: Thu, 12 Sep 2019 14:23:47 +0200 (CEST)

Support.

Justin

----- Mail original -----
> De: "Tommy Pauly" <tpauly=[email-masked]>
> À: "IETF IPPM WG" <[email-masked]>
> Envoyé: Mercredi 11 Septembre 2019 18:10:41
> Objet: [ippm] Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options

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

---

From: <[email-masked]>
Date: Mon, 16 Sep 2019 14:52:42 +0800 (CST)

Hi all,

According to draft-ali-spring-ioam-srv6-01, IOAM Data Field would be carried in SRH TLV with SRv6.

But my further question is, why do we need to define different IOAM Data encapsulation for IPv6 and SRv6? In other words, what's the problem if the IOAM encapsulation specified in draft-ioametal-ippm-6man-ioam-ipv6-options-02 is used for SRv6 too?

Best Regards,

Xiao Min

原始邮件

发件人：AnoopGhanwani <[email-masked]>
收件人：Tommy Pauly <tpauly=[email-masked]>;
抄送人：[email-masked] <[email-masked]>;IETF IPPM WG <[email-masked]>;
日 期 ：2019年09月12日 08:32
主 题 ：Re: [ippm] Adoption call fordraft-ioametal-ippm-6man-ioam-ipv6-options

Thanks,
Anoop

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

Hello IPPM,

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

Best,
Tommy (as IPPM co-chair)

---

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

---

From: S.V.R.Anand <[email-masked]>
Date: Sun, 22 Sep 2019 06:14:24 +0000

Support.

Regards
Anand
________________________________
From: ippm <[email-masked]> on behalf of Nagendra Kumar Nainar (naikumar) <[email-masked]>
Sent: Thursday, September 12, 2019 12:06 AM
To: Tommy Pauly <tpauly=[email-masked]>; IETF IPPM WG <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [ippm] Adoption call for draft-ioametal-ippm-6man-ioam-ipv6-options

Support.

Regards,
Nagendra

    Hello IPPM,

    Best,
    Tommy (as IPPM co-chair)

---

From: Akshaya Nadahalli <[email-masked]>
Date: Tue, 24 Sep 2019 18:01:34 +0530

Support

Regards,
Akshaya N

On 9/11/19, 9:41 PM, "[email-masked] on behalf of Tommy Pauly" <
> [email-masked]> wrote:

---

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

---

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>

---

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

Hello IPPM,

Thanks for all of the feedback. It seems that the rough consensus of the group is that we should adopt this document.

As we progress with this document, we should expect to share it with 6man and get input and review feedback from that group.

Authors, please submit a "draft-ietf-ippm-6man-ioam-ipv6-options-00" when ready. It would be good to incorporate some of the review feedback received on this thread.

Thanks,
Tommy

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