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

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 28 Feb 2019 12:20:14 +0000

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>

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

2

Robin <[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]>

"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]>

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

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

5

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>

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

6

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>

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

7

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>

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

8

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>

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

9

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

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

10

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>

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

11

Robin <[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]>

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

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

Clarify Encapsulating vs. Decapsulating node description

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

15

Haoyu song <[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]>

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]> 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: Tianran Zhou <[email-masked]>
Date: Fri, 1 Mar 2019 01:41:32 +0000

Dear Authors,

It’s great that you are now starting to track issues raised in the community.

I am happy that you also discussed the issue “- Immediate export of the IOAM data at any node”.
Actually, we had a draft on the solution to solve this issue. Moreover, we provided a flexible way to specify any number of hops to export the data.
https://www.ietf.org/archive/id/draft-song-ippm-segment-ioam-01.txt
I hope this extension can help.

In addition, we provided some other extensions to the ioam-data. Those include:
a) How to extend the data types for further use:
https://www.ietf.org/archive/id/draft-song-ippm-ioam-data-extension-01.txt
b) How to indicate a node is only able to report partial requested data
https://www.ietf.org/archive/id/draft-song-ippm-ioam-data-validation-option-02.txt
c) How to deal with the IOAM operation and encapsulation when the flow transvers a tunnel
https://www.ietf.org/archive/id/draft-song-ippm-ioam-tunnel-mode-00.txt

I believe all of them are useful. I hope you can also track those issues and solution, and incorporate.

Cheers,
Tianran

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

Hi Adrian, All,

Reviewer

1

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

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

13

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

14

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

15

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

16

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

Thanks,

Shwetha

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

Hi,

plans for this draft.

Thanks,

Adrian

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 1 Mar 2019 01:54:52 +0000

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

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