Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 1 Mar 2019 13:26:45 +0000

Hi, Tianran,

Thank you for sharing your perspective. I am a bit surprised to read your two paragraphs and somewhat taken aback by their implications of non-openness; consequently, I wanted to take 2 minutes to comment on and discuss them on the mailing list.

On paragraph #1:

While you tracking these issues is a good starting point to be open, I still think you should not just work in the back group with a small group.

Ever since ioam-data was an individual submission (and before), authors and contributors have tracked in GitHub, to then *share* and *discuss* on meetings and the mailing list, and *compiled a list of changes from these tracked issues* on every change and iteration.

This is neither “a good starting point” (it’s better than average, captures issues raised on the list on an organized canonical tracker), nor "work in the back with a small group."

I’d like to point you to:

  *   IETF97, Nov 2016, https://datatracker.ietf.org/meeting/97/materials/slides-97-opsawg-in-situ-oam-00
     *   See Slide 3, text “Updates included in -02 version of the drafts. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed<https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed>"
  *   IETF98, March 2017, https://datatracker.ietf.org/meeting/98/materials/slides-98-ippm-5-draft-brockners-inband-oam-data-00
     *   See Slide 5, text “Incorporated IETF discussion feedback: Key updates since -00 version. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed<https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed>"
  *   IETF99, July 2017, https://datatracker.ietf.org/meeting/99/materials/slides-99-ippm-in-situ-oam-ioam-draft-brockners-inband-oam-data-00
     *   See Slide 2, text: "Key updates between -03 (reviewed in Chicago) and -07 version. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed<https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed>”
  *   IETF100, November 2017, https://datatracker.ietf.org/meeting/100/materials/slides-100-ippm-03-in-situ-oam-ioam-draft-ietf-ippm-ioam-data-01
     *   See Slide 2, text "Updates between -00 and -01 version. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed<https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed>”
     *   See Slide 3 and Slide 6, Discussion Topics, […]
  *   And so on…

I think you can identify the pattern, not “work in the back with a small group."

On paragraph #2:

The IETF wishes to see more discussions in the mailing list to make open standard. Solution proposal should be agreed in the community.

Since you seem to be speaking (writing) on behalf of “The IETF”, I’d also like to point you to the GIT General Area Chartered WG.

https://datatracker.ietf.org/group/git/about/
“Many IETF working groups use external code repository services, primarily GitHub, in managing their work. […]"

In this light, I’d call the clarity of tracking seen here as pioneering. And the cross-community progressing of IOAM well within the standard process.

And by the way, the 747 Messages found in the mailing list say there’s been discussion (418 Messages found in the mailing list for https://mailarchive.ietf.org/arch/search/?q=draft-ietf-ippm-ioam-data and additional 329 Messages found in the mailing list for https://mailarchive.ietf.org/arch/search/?q=draft-brockners-inband-oam-data).

Let us please discuss technology, and make data-backed forward-moving statements...

My 2 cents.

My change on your 2 cents.

Best,

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

"올려다 봐 이렇게 마주한 같은 하늘”
“Look up, we're all looking at the same sky."
-Kim NamJoon

On Mar 1, 2019, at 9:54 AM, Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:

Hi Authors,

While you tracking these issues is a good starting point to be open, I still think you should not just work in the back group with a small group.

The IETF wishes to see more discussions in the mailing list to make open standard. Solution proposal should be agreed in the community.

My 2 cents.
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, February 28, 2019 8:20 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Adrian, All,

Here is a summary of comments received for draft-ietf-ippm-ioam-data-04 and corresponding github issues the authors are maintaining to address them in -05:

Reviewer

Brief description of the comment

Link to github tickets and discussion

1

Tianran Zhou<[email-masked]<mailto:[email-masked]>>

queue depth and buffer occupancy<https://mailarchive.ietf.org/arch/msg/ippm/IpKxrhvQCL9H7Jxl6q0rjx5VJRc>

https://github.com/inband-oam/ietf/issues/99

2

Robin <[email-masked]<mailto:[email-masked]>>

Drop reference to Segment routing examples in the introduction<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/100

3

Robin <[email-masked]<mailto:[email-masked]>>

"While, for example, the IOAM node identifier (Node-ID) does not have to be unique in a deployment , the combination of Node-ID and Namespace-ID will always be unique.  " Why assume that the node id will not be unique? It is only to increase complexity.

https://github.com/inband-oam/ietf/issues/101

4

Robin <[email-masked]<mailto:[email-masked]>>

RFC2119  language<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/102

5

Robin <[email-masked]<mailto:[email-masked]>>

IOAM-Trace-Type is still being referred to as 16 bit identifier instead of 24bit<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/103

6

Robin <[email-masked]<mailto:[email-masked]>>

  IOAM-Trace-Type Bit 12-22 must be zero - why not simply ignore it<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/104

7

Robin <[email-masked]<mailto:[email-masked]>>

The first element of the node data list (node data list [0]) contains the last node of the path while the last node data of the node data list (node data list[n]) contains the first node data of the path traced.<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/105

8

Robin <[email-masked]<mailto:[email-masked]>>

Since some customized data maybe encapsulated in the IOAM header, maybe it is not always aligned with 4-octet or 8-octet. Is it necessary to introduce some padding mechanisms? <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/106

9

Robin <[email-masked]<mailto:[email-masked]>>

Though it is necessary to save space it is a little strange for 3-octet node-id comparing popular 4-octet and 16-octet node id in other protocols. The 3-octet node id remove the possibility of reuse and consistency. It may introduce the unnecessary confu<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>sion

https://github.com/inband-oam/ietf/issues/107

10

Robin <[email-masked]<mailto:[email-masked]>>

The queue length is not enough since there may be multiple queues for a specific outgoing interface.  If there is H-QoS, it will be more complex.<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/108

11

Robin <[email-masked]<mailto:[email-masked]>>

units of the buffer occupancy bytes or percentage<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/109

12

Robin <[email-masked]<mailto:[email-masked]>>

Fix IOAM-Trace-type length in the examples<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

https://github.com/inband-oam/ietf/issues/110

13

John Lemon <[email-masked]<mailto:[email-masked]>>

Packets that are looped back do not have an indicator

https://github.com/inband-oam/ietf/pull/95/commits/320841ee187139a1bfe9cf4b42de05fcc1629cd9

14

Tal Mizrahi <[email-masked]<mailto:[email-masked]>>

Clarify Encapsulating vs. Decapsulating node description

https://github.com/inband-oam/ietf/pull/90/commits/69e6eb496abb6ad3702710f24377a729315336b4

15

Haoyu song <[email-masked]<mailto:[email-masked]>>

Use a Data Template ID to replace the IOAM Trace Type

https://github.com/inband-oam/ietf/issues/111

16

Haoyu song <[email-masked]<mailto:[email-masked]>>

Carry a Sequence Number (SN) field in the IOAM trace option header

https://github.com/inband-oam/ietf/issues/112

In addition to this, based on some of the face to face and side meetings at IETF we are introducing the following:
- Immediate export of the IOAM data at any node by setting an IOAM flag in the trace option to indicate this:
Adding immediate export flag: tell the network node to immediately export IOAM requested data to the collector. By that, it can help solve problems such as insufficient allocated space in the packets' headers or large IOAM header leading to inefficient lookup of data e.g. L4 header that follows.
Proposed update: https://github.com/inband-oam/ietf/pull/96

- A flag bit in trace option to indicate "active OAM", for example
probes and cloned packets.
When "active OAM" is indicated, at the IOAM decapsulating node the packet
is discarded rather than forwarded, after retrieval of the IOAM metadata.
Proposed update: https://github.com/inband-oam/ietf/pull/97

The authors have discussed and added notes/comments in github for each issue listed above and welcome the workgroup to comment there, or we can continue discussing it here.

Thanks,
Shwetha

"Adrian Farrel" <[email-masked]<mailto:[email-masked]>> Sat, 23 February 2019 10:27 UTC
Hi,

I wonder whether the authors can supply some information on the status and
plans for this draft.

It seems to me that there was a deal of discussion after the last version
(2018-10-20) in Bangkok and on the mailing list. Some of the mailing list
threads resulted in agreement, some had discussions that started but don't
appear to have reached a conclusion, and some never even got an answer.

I know we are all very busy, and I don't expect immediate responses, but
with 12 front-page authors it should be possible to find someone to respond
to the questions and propose resolution to the points raised. Or should we
add a thirteenth author who has a little more time?

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 Mar 2019 15:06:16 -0000

Hey!

Let me pile in because I think I started this thread.

My concern was that I could see a number of emails on the list that raised points and concerns about the draft, but I could not see any discussion or response to these points.

Now, please, this is not a witch hunt. I don’t mind why or how things are how they are.

But, moving forward, I would like to be able to get a better handle on what the progress is, and I would like to be able to participate in a discussion of the work.

This draft is foundational for a lot of OAM work across several areas, and it is therefore important to get it polished.

I think Carlos has flagged up some important ways in which we can watch and learn about progress with the draft. 

*	The reports to the working group at each IETF meeting are important check-points on the progress and plans. Those of us who are unable to make it to the meetings because of conflicts (in Prague, that will be those working on SRv6 and on lower layer transport technologies) can catch up by watching the video recording, reading the minutes, and looking at the slides. But discussion time at the meetings is, of course, limited even if you can attend, and the IETF does its primary work on the mailing lists.
*	The issue tracking in GitHub is as good a place as any to track issues and record the resolutions. But, given that the IETF reaches and records consensus on its mailing lists, it would be really nice if emails about the draft were answered on the list, at least to let everyone know that they are being heard, but preferably to also discuss how the issues will be addressed.

The reason that some may feel that the work is going on in the background is that emails have gone unresponded, the draft has not been updated, and there have been no indications of the plans to address issues that have been raised.

I am sure that the author team are tracking everything and plan to handle all of the questions and concerns in good faith. That really is not the issue.

The issue is that it is hard to see this. And that is not a problem of “outsiders” not being able to see what is going on, it is a problem for regular IETF participants.

So, thanks to the authors for posting an update to the draft a magical two days after I asked what the status was. Coincidence is a wonderful thing.

Special thanks to Shwetha for producing an email that captures a list of the issues and concerns raised on the list.

Thanks, also, to Carlos for pointing us at the GitHub location

But can we please have a little more communication? When there is a new revision, please don’t leave us to run a diff to find out what has changed, and then try to work back through the issue tracker to find out why. Please drop a short note to the list to tell us what changed and why.

And please can we have responses to emails?

Many thanks to everyone for the work they are doing,

Adrian

PS. Carlos, your counts of messages in the list archive may be a little misleading. If we look at the emails specifically about this draft we find that, before my request for a status update (2019-02-23) the only emails directly to this list specifically for this draft in the last cycle were:

*	Tianran, Greg, and Ramesh discussion (2018-12-04)
*	Robin unanswered comments (2019-11-04)

But this is not a competition to prove who is right and who has evidence of what. It is largely about how involved people do or do not feel, and that is best handled through communication, which is what is happening now.

From: Carlos Pignataro (cpignata) <[email-masked]> 
Sent: 01 March 2019 13:27
To: Tianran Zhou <[email-masked]>
Cc: Shwetha Bhandari (shwethab) <[email-masked]>; Adrian Farrel <[email-masked]>; IETF IPPM WG <[email-masked]>; [email-masked]
Subject: Re: [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi, Tianran,

On paragraph #1:

*	See Slide 3, text “Updates included in -02 version of the drafts. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed <https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed> "

*	See Slide 5, text “Incorporated IETF discussion feedback: Key updates since -00 version. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed <https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed> "

*	See Slide 2, text: "Key updates between -03 (reviewed in Chicago) and -07 version. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed <https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed> ”

*	See Slide 2, text "Updates between -00 and -01 version. See also: https://github.com/inband-oam/ietf/issues?q=is%3Aissue+is%3Aclosed <https://github.com/inband-oam/ietf/issues?q=is:issue+is:closed> ”
*	See Slide 3 and Slide 6, Discussion Topics, […]

*	And so on… 

On paragraph #2:

My 2 cents.

Best,

—
Carlos Pignataro, [email-masked] <mailto:[email-masked]> 

"올려다 봐 이렇게 마주한 같은 하늘”

On Mar 1, 2019, at 9:54 AM, Tianran Zhou <[email-masked] <mailto:[email-masked]> > wrote:

Hi Authors,

My 2 cents.

Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, February 28, 2019 8:20 PM
To: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Adrian, All,

 

Reviewer

1

Tianran Zhou< <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/IpKxrhvQCL9H7Jxl6q0rjx5VJRc> queue depth and buffer occupancy

 <https://github.com/inband-oam/ietf/issues/99> https://github.com/inband-oam/ietf/issues/99

2

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> Drop reference to Segment routing examples in the introduction

 <https://github.com/inband-oam/ietf/issues/100> https://github.com/inband-oam/ietf/issues/100

3

Robin < <mailto:[email-masked]> [email-masked]>

 <https://github.com/inband-oam/ietf/issues/101> https://github.com/inband-oam/ietf/issues/101

4

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> RFC2119  language

 <https://github.com/inband-oam/ietf/issues/102> https://github.com/inband-oam/ietf/issues/102

5

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> IOAM-Trace-Type is still being referred to as 16 bit identifier instead of 24bit

 <https://github.com/inband-oam/ietf/issues/103> https://github.com/inband-oam/ietf/issues/103

6

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>   IOAM-Trace-Type Bit 12-22 must be zero - why not simply ignore it

 <https://github.com/inband-oam/ietf/issues/104> https://github.com/inband-oam/ietf/issues/104

7

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> The first element of the node data list (node data list [0]) contains the last node of the path while the last node data of the node data list (node data list[n]) contains the first node data of the path traced.

 <https://github.com/inband-oam/ietf/issues/105> https://github.com/inband-oam/ietf/issues/105

8

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> Since some customized data maybe encapsulated in the IOAM header, maybe it is not always aligned with 4-octet or 8-octet. Is it necessary to introduce some padding mechanisms? 

 <https://github.com/inband-oam/ietf/issues/106> https://github.com/inband-oam/ietf/issues/106

9

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> Though it is necessary to save space it is a little strange for 3-octet node-id comparing popular 4-octet and 16-octet node id in other protocols. The 3-octet node id remove the possibility of reuse and consistency. It may introduce the unnecessary confusion

 <https://github.com/inband-oam/ietf/issues/107> https://github.com/inband-oam/ietf/issues/107

10

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> The queue length is not enough since there may be multiple queues for a specific outgoing interface.  If there is H-QoS, it will be more complex.

 <https://github.com/inband-oam/ietf/issues/108> https://github.com/inband-oam/ietf/issues/108

11

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> units of the buffer occupancy bytes or percentage

 <https://github.com/inband-oam/ietf/issues/109> https://github.com/inband-oam/ietf/issues/109

12

Robin < <mailto:[email-masked]> [email-masked]>

 <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs> Fix IOAM-Trace-type length in the examples

 <https://github.com/inband-oam/ietf/issues/110> https://github.com/inband-oam/ietf/issues/110

13

John Lemon < <mailto:[email-masked]> [email-masked]>

 <https://github.com/inband-oam/ietf/pull/95/commits/320841ee187139a1bfe9cf4b42de05fcc1629cd9> https://github.com/inband-oam/ietf/pull/95/commits/320841ee187139a1bfe9cf4b42de05fcc1629cd9

14

Tal Mizrahi < <mailto:[email-masked]> [email-masked]>

 <https://github.com/inband-oam/ietf/pull/90/commits/69e6eb496abb6ad3702710f24377a729315336b4> https://github.com/inband-oam/ietf/pull/90/commits/69e6eb496abb6ad3702710f24377a729315336b4

15

Haoyu song < <mailto:[email-masked]> [email-masked]>

 <https://github.com/inband-oam/ietf/issues/111> https://github.com/inband-oam/ietf/issues/111

16

Haoyu song < <mailto:[email-masked]> [email-masked]>

 <https://github.com/inband-oam/ietf/issues/112> https://github.com/inband-oam/ietf/issues/112

Proposed update:  <https://github.com/inband-oam/ietf/pull/96> https://github.com/inband-oam/ietf/pull/96

Proposed update:  <https://github.com/inband-oam/ietf/pull/97> https://github.com/inband-oam/ietf/pull/97

Thanks,

Shwetha

"Adrian Farrel" < <mailto:[email-masked]> [email-masked]> Sat, 23 February 2019 10:27 UTC 

Hi,

plans for this draft.

Thanks,

Adrian

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 3 Mar 2019 14:28:45 +0000

Hi, Adrian,

Sounds good — in progressing WG work it’s healthier to err on the side of over-communicating and over-engaging. Even though we did include a pointer to the GitHub issue tracker in every update, the suggestion to channel more discussion and close-loop issue resolution on the list is a good one and well taken. Current preparation for IETF104 and post-meeting discussion is a good opportunity to reset. Thanks also for appreciating the comprehensiveness of Shwetha’s response.

As engagement is a two-way (or multi-way) street, textual and technical proposals (by all participants) about the open issues raised on the list are always welcomed.

You did mention:
 Some of the mailing list

And indeed I can see that at this point, this post from Robin was unanswered on the list: https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs. Issues 100-110 track Robin’s comments on that posting, and will close loop explicitly on the list.

To make sure others are not missed (since you said “some”) — are you aware of or can you point to others?

Thanks,

— Carlos Pignataro

PS:

I chose to share data as a reaction to a two-liner posting that I read as FUD and "anecdata". Sharing specifics help since authors can then make the feedback actionable and address concrete gaps and opportunities. We’ll certainly continue communication on the list — not as “I heard you” but discussion of resolution.

On Mar 1, 2019, at 10:06 PM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

Hey!

From: Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>
Sent: 01 March 2019 13:27
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>>; Adrian Farrel <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi, Tianran,

On paragraph #1:

  *   And so on…

On paragraph #2:

My 2 cents.

Best,

—

"올려다 봐 이렇게 마주한 같은 하늘”

Hi Authors,

My 2 cents.
Tianran

Hi Adrian, All,

Reviewer

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Thanks,
Shwetha

Thanks,
Adrian

---

From: Mickey Spiegel <[email-masked]>
Date: Wed, 6 Mar 2019 13:55:44 -0800

On Thu, Feb 28, 2019 at 4:20 AM Shwetha Bhandari (shwethab) <
[email-masked]> wrote:

...

> In addition to this, based on some of the face to face and side meetings
> at IETF we are introducing the following:
>
...

> Proposed update: https://github.com/inband-oam/ietf/pull/97
A bit more context on this one.
In draft-ietf-ippm-ioam-data-04
<https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-04>, in Section 3
"Scope, Applicability, and Assumptions":

   Combination with active OAM mechanisms: IOAM should be usable for
   active network probing, enabling for example a customized version of
   traceroute.  Decapsulating IOAM nodes may have an ability to send the
   IOAM information retrieved from the packet back to the source address
   of the packet or to the encapsulating node.

However, there were no corresponding procedures for handling a packet for
active network probing.

The proposal is to assign a flag bit in the trace option for indication of
"active OAM", where "active"
is used in the sense defined in RFC 7799. This allows for active probes to
be sent with destination
addresses that reside beyond the edge of the domain, for example to probe
the path that a packet
to a certain destination would take. The bit indicates to the IOAM
decapsulating node that, in
addition to processing and/or exporting the metadata, the packet must be
discarded rather than
forwarded.

This same bit also handles the case of cloned / sampled packet flows, for
example as proposed in
draft-kumar-ippm-ifa-01.

Any comments or questions would be appreciated.

Mickey

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Mar 2019 14:26:38 -0800

Hi Shwetha,
you've said, "In addition to this, based on some of the face to face and
side meetings at IETF we are introducing the following ..."
I encourage the editors to present for discussion by WG before adding
definitions of new functions to the WG document. From the brief description
you've shared, I don't see how these new behaviors fit in the scope of this
document.

Regards,
Greg

On Thu, Feb 28, 2019 at 4:20 AM Shwetha Bhandari (shwethab) <
[email-masked]> wrote:

> Hi Adrian, All,
>
>
>
> Here is a summary of comments received for draft-ietf-ippm-ioam-data-04
> and corresponding github issues the authors are maintaining to address them
> in -05:
>
>
>
>
>
> *Reviewer*
>
> *Brief description of the comment*
>
> *Link to github tickets and discussion*
>
> 1
>
> Tianran Zhou<[email-masked]>
>
> *queue depth and buffer occupancy
> <https://mailarchive.ietf.org/arch/msg/ippm/IpKxrhvQCL9H7Jxl6q0rjx5VJRc>*
>
> Robin <[email-masked]>
>
> *Drop reference to Segment routing examples in the introduction
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *"While, for example, the IOAM node identifier (Node-ID) does not have to
> be unique in a deployment , the combination of Node-ID and Namespace-ID
> will always be unique.  " Why assume that the node id will not be unique?
> It is only to increase complexity.*
>
> Robin <[email-masked]>
>
> *RFC2119  language
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *IOAM-Trace-Type is still being referred to as 16 bit identifier instead
> of 24bit
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *  IOAM-Trace-Type Bit 12-22 must be zero - why not simply ignore it
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *The first element of the node data list (node data list [0]) contains the
> last node of the path while the last node data of the node data list (node
> data list[n]) contains the first node data of the path traced.
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *Since some customized data maybe encapsulated in the IOAM header, maybe
> it is not always aligned with 4-octet or 8-octet. Is it necessary to
> introduce some padding mechanisms?
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *Though it is necessary to save space it is a little strange for 3-octet
> node-id comparing popular 4-octet and 16-octet node id in other protocols.
> The 3-octet node id remove the possibility of reuse and consistency. It may
> introduce the unnecessary confu
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>sion*
>
> Robin <[email-masked]>
>
> *The queue length is not enough since there may be multiple queues for a
> specific outgoing interface.  If there is H-QoS, it will be more complex.
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *units of the buffer occupancy bytes or percentage
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> Robin <[email-masked]>
>
> *Fix IOAM-Trace-type length in the examples
> <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*
>
> John Lemon <[email-masked]>
>
> Tal Mizrahi <[email-masked]>
>
> Haoyu song <[email-masked]>
>
> Haoyu song <[email-masked]>
>
> Adding immediate export flag: tell the network node to immediately export
> IOAM requested data to the collector. By that, it can help solve problems
> such as insufficient allocated space in the packets' headers or large IOAM
> header leading to inefficient lookup of data e.g. L4 header that follows.
>
> The authors have discussed and added notes/comments in github for each
> issue listed above and welcome the workgroup to comment there, or we can
> continue discussing it here.
>
>
>
> Thanks,
>
> Shwetha
>
>
>
>
>
> "Adrian Farrel" <[email-masked]> Sat, 23 February 2019 10:27 UTC
>
> Hi,
>
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Mickey Spiegel <[email-masked]>
Date: Wed, 6 Mar 2019 14:27:17 -0800

> https://github.com/inband-oam/ietf/issues/104
Copying my reply in GitHub here:

This is due to issue #63 <https://github.com/inband-oam/ietf/issues/63>.
Say we release version IOAM data version 1, then later on we release
IOAM data version 1.1 that assigns a meaning to one of the previously
unused trace type bits. If the encapsulating node and the collector
that ultimately receives all the collected IOAM metadata support
version 1.1, and the new trace type is set, then they will expect each
hop to add the corresponding field. If there is a transit node that only
supports version 1.0 and does not understand the new trace type bit,
and it ignores the bit and adds less than NodeLen words to the packet,
then the collector will not be able to parse the packet correctly. As the
packet traverses the network, the metadata is being prepended one
field at a time as a stack, with no explicit identifier which field is
which.
The collector can figure out which field is which only if it knows how
much metadata each node added.

Mickey

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 7 Mar 2019 01:08:41 +0000

Hi Greg,

> I encourage the editors to present for discussion by WG before adding definitions of new functions to the WG document.
We are proposing these changes as part of addressing comments and hence this discussion, we have not published the -05 version yet.

> I don't see how these new behaviors fit in the scope of this document.
Can you be specific..Which of the change(s) are not in the scope?
Thanks,
Shwetha

From: Greg Mirsky <[email-masked]>
Date: Thursday, March 7, 2019 at 3:56 AM
To: Shwetha bhandari <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,
you've said, "In addition to this, based on some of the face to face and side meetings at IETF we are introducing the following ..."
I encourage the editors to present for discussion by WG before adding definitions of new functions to the WG document. From the brief description you've shared, I don't see how these new behaviors fit in the scope of this document.

Regards,
Greg

On Thu, Feb 28, 2019 at 4:20 AM Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian, All,

Reviewer

1

2

Drop reference to Segment routing examples in the introduction <https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Thanks,

Shwetha

Hi,

plans for this draft.

Thanks,

Adrian

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Mar 2019 19:36:25 -0800

Hi Shwetha,
thank you for your prompt response. I think that the proposed addition of:

   - Immediate export of the IOAM data at any node ...
   -  A flag bit in trace option to indicate "active OAM"  ...

is outside the scope of the document as was adopted by the WG.

Regards,
Greg

On Wed, Mar 6, 2019 at 5:08 PM Shwetha Bhandari (shwethab) <
[email-masked]> wrote:

> definitions of new functions to the WG document.
>
> We are proposing these changes as part of addressing comments and hence
> this discussion, we have not published the -05 version yet.
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Thursday, March 7, 2019 at 3:56 AM
> *To: *Shwetha bhandari <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [ippm] [IPPM] Status and plans for
> draft-ietf-ippm-ioam-data
>
>
>
> Hi Shwetha,
>

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 7 Mar 2019 04:10:00 +0000

Hi Greg,

How is it out of scope?

  *   Immediate export of the IOAM data at any node

This has come up in multiple discussions when IOAM was presented in earlier meetings.
This solves a problem in some of the protocols and deployments where IOAM is encapsulated and there is not enough space to carry entire trace or issues such as ECMP hashing due to L4 header located deeper in the packet when IOAM trace is large.
Do look at this proposal too:
https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-01.txt<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-ippm-postcard-based-telemetry-01.txt&data=02%7C01%7Cgbarak%40mellanox.com%7C8971a1455508481ee4f608d6a26080f5%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636874932692388048&sdata=10a8fra97ltja4KK%2FDni5nVNbwu9hp7yrHQUrlIGW54%3D&reserved=0>
Given IOAM data draft is not finalized this addition helps in improving the data draft that becomes the basis for IOAM encapsulation work. It also helps in deployment of IOAM with multiple encapsulation and in diverse networks.
If you see a technical issue with the proposed flag and its use please do share.

  *    A flag bit in trace option to indicate "active OAM"  ...
Please refer to - https://mailarchive.ietf.org/arch/msg/ippm/I6d96i67zmgj9_kE0E4TewfwNrc on how this solves the problem of now being able to detect if the IOAM data is collected for a crafted probe or a packet returned due to Loopback flag

Thanks,
Shwetha

Date: Thursday, March 7, 2019 at 9:06 AM

Hi Shwetha,

  *   Immediate export of the IOAM data at any node ...
  *    A flag bit in trace option to indicate "active OAM"  ...
is outside the scope of the document as was adopted by the WG.

Regards,
Greg

On Wed, Mar 6, 2019 at 5:08 PM Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 7, 2019 at 3:56 AM
To: Shwetha bhandari <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,

Regards,
Greg

Hi Adrian, All,

Reviewer

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Thanks,

Shwetha

Hi,

plans for this draft.

Thanks,

Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Mar 2019 20:20:23 -0800

Hi Shwetha,
the scope of the draft is defined as:

This document discusses the data fields and associated data types for
in-situ OAM.

Methods of collecting and transporting data are outside the scope of this
draft. The fact that these topics were discussed demonstrates that people
are interested, not that they all belong in this document that is adopted
by the WG.

Regards,
Greg

On Wed, Mar 6, 2019 at 8:10 PM Shwetha Bhandari (shwethab) <
[email-masked]> wrote:

> Hi Greg,
>
>
>
> How is it out of scope?
>
>
>
>    - Immediate export of the IOAM data at any node
>
>
>
> This solves a problem in some of the protocols and deployments where IOAM
> is encapsulated and there is not enough space to carry entire trace or
> issues such as ECMP hashing due to L4 header located deeper in the packet
> when IOAM trace is large.
>
> https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-01.txt
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-ippm-postcard-based-telemetry-01.txt&data=02%7C01%7Cgbarak%40mellanox.com%7C8971a1455508481ee4f608d6a26080f5%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636874932692388048&sdata=10a8fra97ltja4KK%2FDni5nVNbwu9hp7yrHQUrlIGW54%3D&reserved=0>
>
> Given IOAM data draft is not finalized this addition helps in improving
> the data draft that becomes the basis for IOAM encapsulation work. It also
> helps in deployment of IOAM with multiple encapsulation and in diverse
> networks.
>
> Please refer to -
> https://mailarchive.ietf.org/arch/msg/ippm/I6d96i67zmgj9_kE0E4TewfwNrc on
> how this solves the problem of now being able to detect if the IOAM data is
> collected for a crafted probe or a packet returned due to Loopback flag
>
>
>
> Thanks,
>
> Shwetha
>
>
>
> *Date: *Thursday, March 7, 2019 at 9:06 AM

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 7 Mar 2019 05:27:46 +0000

Hi Greg,

> This document discusses the data fields and associated data types for in-situ OAM.
That's perfect, please see the changes suggested for this, it is still dealing with data fields part of the draft-ietf-ippm-ioam-data:
https://github.com/inband-oam/ietf/pull/96
https://github.com/inband-oam/ietf/pull/97

Thanks,
Shwetha

From: Greg Mirsky <[email-masked]>
Date: Thursday, March 7, 2019 at 9:50 AM
To: Shwetha bhandari <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,
the scope of the draft is defined as:
This document discusses the data fields and associated data types for in-situ OAM.
Methods of collecting and transporting data are outside the scope of this draft. The fact that these topics were discussed demonstrates that people are interested, not that they all belong in this document that is adopted by the WG.

Regards,
Greg

On Wed, Mar 6, 2019 at 8:10 PM Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

How is it out of scope?

Thanks,
Shwetha

Hi Shwetha,

Regards,
Greg

Hi Shwetha,

Regards,
Greg

Hi Adrian, All,

Reviewer

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Thanks,

Shwetha

Hi,

plans for this draft.

Thanks,

Adrian

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 7 Mar 2019 07:11:39 +0000

Hi Shwetha,

On your mentioned proposal, we specially deal with the post card telemetry.
https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-01.txt

We want to work as a separate document. Can we find a way to complement the existing ioam-data draft, while not put everything within one document?

Best,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, March 07, 2019 12:10 PM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Greg,

How is it out of scope?

Thanks,
Shwetha

Hi Shwetha,

Regards,
Greg

Hi Shwetha,

Regards,
Greg

Hi Adrian, All,

Reviewer

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Thanks,

Shwetha

Hi,

plans for this draft.

Thanks,

Adrian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 7 Mar 2019 10:20:55 +0000

Hi Tianran,

Fully agreed. Looking at the proposed patch (https://github.com/inband-oam/ietf/pull/96), it introduces another flag for “immediate export” with very little additional context. My reading of the patch is that it tries to fix the case where someone does want to use the data collection capabilities for IOAM, but there is no space left in the packet to carry the IOAM data fields within the packet. Per Greg’s note, the draft-ietf-ippm-ioam-data wouldn’t be the right place to specify all the methods and operations that would make use of this flag – so a dedicated document makes a lot of sense. It would be nice if draft-song-ippm-postcard-based-telemetry could also consider the “immediate export” option in IOAM – along-side the proposed telemetry instruction header.

Thanks, Frank

From: Tianran Zhou <[email-masked]>
Sent: Donnerstag, 7. März 2019 08:12
To: Shwetha Bhandari (shwethab) <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,

Best,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, March 07, 2019 12:10 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Greg,

How is it out of scope?

Thanks,
Shwetha

Hi Shwetha,

Regards,
Greg

Hi Shwetha,

Regards,
Greg

Hi Adrian, All,

Reviewer

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Thanks,

Shwetha

Hi,

plans for this draft.

Thanks,

Adrian

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Mar 2019 09:48:30 +0100

Dear All,
Frank Brockners have said:
" Per Greg’s note, the draft-ietf-ippm-ioam-data wouldn’t be the right
place to specify all the methods and operations that would make use of this
flag – so a dedicated document makes a lot of sense. "
If it is not the agreement that the new flags should not be introduced in
ioam-data, then how else to interpret Frank's response?

Regards,
Greg

---------- Forwarded message ---------
From: Frank Brockners (fbrockne) <[email-masked]>
Date: Thu, Mar 7, 2019 at 11:21 AM
Subject: RE: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data
To: Tianran Zhou <[email-masked]>, Shwetha Bhandari (shwethab) <
[email-masked]>, Greg Mirsky <[email-masked]>
Cc: [email-masked] <[email-masked]>,
[email-masked] <[email-masked]>

Hi Tianran,

Fully agreed. Looking at the proposed patch (
https://github.com/inband-oam/ietf/pull/96), it introduces another flag for
“immediate export” with very little additional context. My reading of the
patch is that it tries to fix the case where someone does want to use the
data collection capabilities for IOAM, but there is no space left in the
packet to carry the IOAM data fields within the packet. Per Greg’s note,
the draft-ietf-ippm-ioam-data wouldn’t be the right place to specify all
the methods and operations that would make use of this flag – so a
dedicated document makes a lot of sense. It would be nice if
draft-song-ippm-postcard-based-telemetry could also consider the “immediate
export” option in IOAM – along-side the proposed telemetry instruction
header.

Thanks, Frank

*From:* Tianran Zhou <[email-masked]>
*Sent:* Donnerstag, 7. März 2019 08:12
*To:* Shwetha Bhandari (shwethab) <[email-masked]>; Greg Mirsky <
[email-masked]>
*Cc:* [email-masked]; [email-masked]
*Subject:* RE: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,

We want to work as a separate document. Can we find a way to complement the
existing ioam-data draft, while not put everything within one document?

Best,

Tianran

*From:* ippm [mailto:[email-masked] <[email-masked]>] *On
Behalf Of *Shwetha Bhandari (shwethab)
*Sent:* Thursday, March 07, 2019 12:10 PM
*To:* Greg Mirsky <[email-masked]>
*Cc:* [email-masked]; [email-masked]
*Subject:* Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Greg,

How is it out of scope?

This has come up in multiple discussions when IOAM was presented in earlier
meetings.

Given IOAM data draft is not finalized this addition helps in improving the
data draft that becomes the basis for IOAM encapsulation work. It also
helps in deployment of IOAM with multiple encapsulation and in diverse
networks.

If you see a technical issue with the proposed flag and its use please do
share.

Please refer to -

Thanks,

Shwetha

*Subject: *Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,

Regards,

Greg

Hi Greg,

Thanks,

Shwetha

*Subject: *Re: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,

Regards,

Greg

Hi Adrian, All,

Here is a summary of comments received for draft-ietf-ippm-ioam-data-04 and
corresponding github issues the authors are maintaining to address them in
-05:

*Reviewer*

1

2

3

4

*RFC2119  language

5

*IOAM-Trace-Type is still being referred to as 16 bit identifier instead of
24bit
<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*

6

7

8

*Since some customized data maybe encapsulated in the IOAM header, maybe it
is not always aligned with 4-octet or 8-octet. Is it necessary to introduce
some padding mechanisms?
<https://mailarchive.ietf.org/arch/msg/ippm/v4a75IXTi8GKfDl_Ddm_5WN6gxs>*

9

10

11

12

13

14

15

16

In addition to this, based on some of the face to face and side meetings at
IETF we are introducing the following:

- Immediate export of the IOAM data at any node by setting an IOAM flag in
the trace option to indicate this:

Thanks,

Shwetha

Hi,

plans for this draft.

Thanks,

Adrian

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 25 Mar 2019 09:53:58 +0000

Greg,

Just to repeat what I said at the mike in IPPM and also below: draft-ietf-ippm-ioam-data is to define the data-fields – it is not to specify how you use the data (i.e. methods and operations how you’d use the data-fields). And this is what the draft currently does.

Per the notes of the chairs at the end of the meeting: Moving forward, the I-D is to separate IOAM data-fields which drive active behavior (i.e. the flags) from data-fields which only carry information in the document. In addition, we should consider writing another I-D which defines how the data-fields which drive active behavior should be used, i.e. the methods and operations for the flags.

HTH.

Frank

From: Greg Mirsky <[email-masked]>
Sent: Montag, 25. März 2019 09:49
To: IETF IPPM WG <[email-masked]>; Frank Brockners (fbrockne) <[email-masked]>
Subject: Fwd: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Dear All,
Frank Brockners have said:
" Per Greg’s note, the draft-ietf-ippm-ioam-data wouldn’t be the right place to specify all the methods and operations that would make use of this flag – so a dedicated document makes a lot of sense. "
If it is not the agreement that the new flags should not be introduced in ioam-data, then how else to interpret Frank's response?

Regards,
Greg
---------- Forwarded message ---------
From: Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>
Date: Thu, Mar 7, 2019 at 11:21 AM
Subject: RE: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>, Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>>, Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hi Tianran,

Thanks, Frank

From: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Sent: Donnerstag, 7. März 2019 08:12
To: Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>>; Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [ippm] [IPPM] Status and plans for draft-ietf-ippm-ioam-data

Hi Shwetha,

Best,
Tianran

Hi Greg,

How is it out of scope?

Thanks,
Shwetha

Hi Shwetha,

Regards,
Greg

Hi Shwetha,

Regards,
Greg

Hi Adrian, All,

Reviewer

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Thanks,

Shwetha

Hi,

plans for this draft.

Thanks,

Adrian