Subject: Re: [ippm] ippm Digest, Vol 178, Issue 28

From: Barak Gafni <[email-masked]>
Date: Thu, 7 Mar 2019 20:23:53 +0000

Frank, Tianran,
Please note that in the PR this topic is already discussed:
"As a mean to support easier traction of a particular immediate exported data sets of flows within a network, a deployment MAY attach an IOAM edge-to-edge option in addition to the trace option, that includes a sequence number. See Bit 1 in the IOAM-E2E-Types."

So I think the discussion should be whether adding E2E for this purpose is good enough, or should we add a different header. Or should we extend E2E.
BTW, there are implementations where there is no need for it at all, hence the MAY.

Thanks,
Barak

Date: Thu, 7 Mar 2019 19:36:22 +0000
From: "Frank Brockners (fbrockne)" <[email-masked]>
To: Haoyu song <[email-masked]>, Tianran Zhou
	<[email-masked]>,  Tianran Zhou <[email-masked]>,
	"Shwetha Bhandari (shwethab)" <[email-masked]>, Greg Mirsky
	<[email-masked]>, Barak Gafni <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [ippm] co-design the post card telemetry
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="utf-8"

Good point. I?ve added this consideration to the discussion on the related pull request https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fpull%2F96&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324060370&amp;sdata=8JGPYnL1rd9g4AUmgfzArf3gRFhQqL36nFHfFHYoFtI%3D&amp;reserved=0

Frank

From: ippm <[email-masked]> On Behalf Of Haoyu song
Sent: Donnerstag, 7. M?rz 2019 19:25
To: Tianran Zhou <[email-masked]>; Tianran Zhou <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [ippm] co-design the post card telemetry

In my opinion, PBT can work as an independent mode similar to the E2E and Trace modes in IOAM.

The current IOAM draft is updated to add a single bit to indicate sending a postcard, but it?s not sufficient to cover the case.
The collector would need  flowid and sequence number to correlate the postcards for the same packet. In IOAM, only E2E mode has an optional sequence number. But E2E mode is not supposed to send postcard along the path anyway. In Trace mode, there?s no sequence number. I have suggested in another email to add the sequence number in IOAM header.
But to make things clean, perhaps another mode is the right way to go.

Regards,
Haoyu

From: ippm [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Thursday, March 07, 2019 12:12 AM
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]>
Subject: [ippm] co-design the post card telemetry

A forked thread.
As many folks have interest about this.
Let?s discuss and co-design the post card telemetry. Here is our draft.
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-ippm-postcard-based-telemetry-01.txt&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324060370&amp;sdata=VS2edmMNCpXGPBDoQYwb5CFBnHivT9mvR0dTeEYZB9Y%3D&amp;reserved=0

Please review and comment.

Thanks,
Tianran

From: ippm [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Thursday, March 07, 2019 3:12 PM
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,

On your mentioned proposal, we specially deal with the post card telemetry.
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-ippm-postcard-based-telemetry-01.txt&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=M9nelR1FlzBigVBARPoAFpPNDTSYHqrCDcVyCEY4Tzc%3D&amp;reserved=0

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

  *   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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-ippm-postcard-based-telemetry-01.txt&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=M9nelR1FlzBigVBARPoAFpPNDTSYHqrCDcVyCEY4Tzc%3D&amp;reserved=0<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-song-ippm-postcard-based-telemetry-01.txt&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=M9nelR1FlzBigVBARPoAFpPNDTSYHqrCDcVyCEY4Tzc%3D&amp;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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2FI6d96i67zmgj9_kE0E4TewfwNrc&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=yzPO0Q9Z3v5SvNSL%2Bq0uoe%2FQBPPBi8EuWdiiid81Sx0%3D&amp;reserved=0 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

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 7, 2019 at 9:06 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,
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]<mailto:[email-masked]>> wrote:
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]<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,
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,

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2FIpKxrhvQCL9H7Jxl6q0rjx5VJRc&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=tw6t2O7lhr%2FFlsawkDySs5BzhqDHaP%2FLUni1Jp3UpW0%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F99&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=%2B1XlJ4KlkB5wNl1VuF9LubkmDrO4CfI0SFvuD8sxd3k%3D&amp;reserved=0

2

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

Drop reference to Segment routing examples in the introduction <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=eGc%2BfMjldxUJqYnKR4HlOIzEP2lrsK4Kq8uOd04SxmM%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F100&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=HRfXfhy4vD0gM6PB7JaAPnvfo2WmLa3Bn9sXiNh9SNk%3D&amp;reserved=0

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F101&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=Fr%2FxtdA8EcaQkORQHwrTibT9q2s5K2UM9jF8pkPO%2Ft0%3D&amp;reserved=0

4

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

RFC2119  language<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=eGc%2BfMjldxUJqYnKR4HlOIzEP2lrsK4Kq8uOd04SxmM%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F102&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=eJaf3bO95V%2BAzAUr8JLyBorS2eB0F%2FC%2B4H8k3kVEVXE%3D&amp;reserved=0

5

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

IOAM-Trace-Type is still being referred to as 16 bit identifier instead of 24bit<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=eGc%2BfMjldxUJqYnKR4HlOIzEP2lrsK4Kq8uOd04SxmM%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F103&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=OY4I5pjOrmP03y793217fAuqYQgminZNYl0g5JyFI98%3D&amp;reserved=0

6

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

  IOAM-Trace-Type Bit 12-22 must be zero - why not simply ignore it<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324070379&amp;sdata=eGc%2BfMjldxUJqYnKR4HlOIzEP2lrsK4Kq8uOd04SxmM%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F104&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=Dr1AyQXZlywFtWdTC3M%2FRm8fG18iVJ%2FSmQxHK3o4keA%3D&amp;reserved=0

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=Oc0YBxPV%2FUWSr7Omj4HTO1tsImL7gVR53kDrfJi4T94%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F105&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=%2FWNYR9uAlyRwMEEIpRb8qW63SwxfftZ1qkywI4tJQEQ%3D&amp;reserved=0

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=Oc0YBxPV%2FUWSr7Omj4HTO1tsImL7gVR53kDrfJi4T94%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F106&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=x8OXRxiUCER46CA65tGbESHkNuIn7%2FhqjKvbe4QwswI%3D&amp;reserved=0

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=Oc0YBxPV%2FUWSr7Omj4HTO1tsImL7gVR53kDrfJi4T94%3D&amp;reserved=0>sion

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F107&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=V687cO285USRo%2FF9KMTj6qpdF%2FPDktDpB0SqZvah19Y%3D&amp;reserved=0

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=Oc0YBxPV%2FUWSr7Omj4HTO1tsImL7gVR53kDrfJi4T94%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F108&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=ig2u0kC65uSIAYJyymcN%2Fm4PqV%2F6Jd2Y9XO9%2Bq%2B9oO4%3D&amp;reserved=0

11

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

units of the buffer occupancy bytes or percentage<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=Oc0YBxPV%2FUWSr7Omj4HTO1tsImL7gVR53kDrfJi4T94%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F109&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=3JgmlWFD89%2FvSj%2BaJdAbq7WZv%2BXIs6gLKQfQTpCy3vg%3D&amp;reserved=0

12

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

Fix IOAM-Trace-type length in the examples<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fippm%2Fv4a75IXTi8GKfDl_Ddm_5WN6gxs&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=Oc0YBxPV%2FUWSr7Omj4HTO1tsImL7gVR53kDrfJi4T94%3D&amp;reserved=0>

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F110&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=wlDNH2RZUm%2B18vMl%2BiAc8RsVAbf4h53RHu%2FDEz0RshQ%3D&amp;reserved=0

13

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

Packets that are looped back do not have an indicator

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fpull%2F95%2Fcommits%2F320841ee187139a1bfe9cf4b42de05fcc1629cd9&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=YpEIunmj%2B8OJdtLF1N2kIwH5QMOopC%2BzfpEk%2FgHIE7U%3D&amp;reserved=0

14

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

Clarify Encapsulating vs. Decapsulating node description

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fpull%2F90%2Fcommits%2F69e6eb496abb6ad3702710f24377a729315336b4&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=OWR1vo2UXZOXuAtkrDrfNVUIQCCiQ%2BM2g1xvUPIOBak%3D&amp;reserved=0

15

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

Use a Data Template ID to replace the IOAM Trace Type

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F111&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324080384&amp;sdata=0s2wXtk0hJv7tJKGmu1MjMtfb7AlWjJS0IAbllUl%2Byo%3D&amp;reserved=0

16

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

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

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fissues%2F112&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324090389&amp;sdata=Cj1mgcFcTJPKHZGgqfe%2FNWTtvLz6OdA6F9b%2FsdBDTrg%3D&amp;reserved=0

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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fpull%2F96&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324090389&amp;sdata=WYErTXee%2FqV%2FI0THaDwRyvjHQx2ckE3cUx3JjDK3LdY%3D&amp;reserved=0

- 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Finband-oam%2Fietf%2Fpull%2F97&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324090389&amp;sdata=dzvclspZf5zc7e8%2FyhSc5NxR4myR2JyujZ5kNjfeVtE%3D&amp;reserved=0

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

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324090389&amp;sdata=cG75%2Fbjb3vt76lPXVCLawhaxIrJSCNtSsEoanZhcbC8%3D&amp;reserved=0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fippm%2Fattachments%2F20190307%2F486becef%2Fattachment.html&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324090389&amp;sdata=tOZdsPvUbWr13iTRaz6SSEs1Nis2X5phTRDc1FrRkLU%3D&amp;reserved=0>

------------------------------

Subject: Digest Footer

_______________________________________________
ippm mailing list
[email-masked]
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=02%7C01%7Cgbarak%40mellanox.com%7C12dd25412b8745391f4708d6a3344a4d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636875842324090389&amp;sdata=cG75%2Fbjb3vt76lPXVCLawhaxIrJSCNtSsEoanZhcbC8%3D&amp;reserved=0

------------------------------

End of ippm Digest, Vol 178, Issue 28
*************************************