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

["Adrian Farrel" <[e-mail]>]

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) <[e-mail]> 
Sent: 01 March 2019 13:27
To: Tianran Zhou <[e-mail]>
Cc: Shwetha Bhandari (shwethab) <[e-mail]>; Adrian Farrel <[e-mail]>; IETF IPPM WG <[e-mail]>; [e-mail]
Subject: Re: [IPPM] Status and plans for draft-ietf-ippm-ioam-data

 

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, [e-mail] <mailto:[e-mail]> 

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

“Look up, we're all looking at the same sky."
-Kim NamJoon

 





On Mar 1, 2019, at 9:54 AM, Tianran Zhou <[e-mail] <mailto:[e-mail]> > 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:[e-mail]] On Behalf Of Shwetha Bhandari (shwethab)
Sent: Thursday, February 28, 2019 8:20 PM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> 
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< <mailto:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

"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> https://github.com/inband-oam/ietf/issues/101


4

Robin < <mailto:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

 <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:[e-mail]> [e-mail]>

Packets that are looped back do not have an indicator

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


14

Tal Mizrahi < <mailto:[e-mail]> [e-mail]>

Clarify Encapsulating vs. Decapsulating node description

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


15

Haoyu song < <mailto:[e-mail]> [e-mail]>

Use a Data Template ID to replace the IOAM Trace Type

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


16

Haoyu song < <mailto:[e-mail]> [e-mail]>

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

 <https://github.com/inband-oam/ietf/issues/112> 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> 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> 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" < <mailto:[e-mail]> [e-mail]> 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