Subject: Re: [ippm] Side Meeting: IOAM Immediate Export Draft

From: Tal Mizrahi <[email-masked]>
Date: Tue, 6 Aug 2019 08:50:03 +0300

Dear Chairs,

Following up on the request below, we are looking forward to have an
infrastructure (mailing list, Webex, Github folder) that will allow us to
make progress.
I am hoping to have a preliminary draft of the immediate exporting ready
for the design team's review by the end of August.

Thanks,
Tal.

On Fri, Jul 26, 2019 at 6:50 PM Barak Gafni <[email-masked]> wrote:

> Hi,
>
>
>
> Please find below side meeting notes: Friday 26th July 8:30 am Notredam
>
>
>
> Summary:
>
>    - Group suggestion: for 00 draft we should define the new IOAM option
>    and keep single flag which tells “immediate export”. Additional
>    capabilities will be discussed towards 01 and beyond
>    - The group is asking the chairs to approve the need for a public IETF
>    mailing list for a “design” team and a public webex to allow the group to
>    progress on a weekly or bi-weekly cadence
>
>
>
> More details:
>
>    - The option is added / removed by the encap/decap nodes, read by the
>    intermediate nodes
>
>
>    - Tianran presented option defined a modified form from
>    draft-song-ippm-postcard-based-telemetry-04:
>
>
>
>        0             0 0             1 1             2 2             3
>
>        0             7 8             5 6             3 4             1
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |        Namespace ID           | Flags | action|  Hop Count    |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |         IOAM-Trace-Type                       |  Reserved     |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                         Flow ID (optional)                    |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |                     Sequence Number  (Optional)               |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
> Below comments came from discussion of the above and the content of
> immediate export to answer:
>
>    1. What to export
>    2. Where to export
>    3. When to export
>
>
>
>    - Discussed potential fields in the option header, beyond 00 draft:
>       - Discussed the option to add “actions”, although may change the
>       name
>       - The original flags from the flags draft may be reconsidered
>          - Overflow may become redundant
>          - Active is still relevant
>          - Loopback should be considered
>          - Immediate export – whether it is implicit or should be explicit
>       - IOAM trace type should stay as is to help collector and trace
>       implementation to maintain consistent node data parsing.
>       - Consider whether to have the sequence number and flow id. The
>       interpretation is through the higher layer length. Will be included as
>       optional at the 00 draft
>          - Sequence number – suggestion is to use the e2e sequence number
>          - Anyway, agreement is that the sequence number and the flow id
>          go as a pair.
>       - Flags should reside in a similar place as at the ioam tracing
>       options
>    - Suggest to use the raw export draft to export the data
>       - Need to follow up on the raw export
>       - Need to clarify the behavior, so the node 0 will follow the
>       captured immediate export option
>    - Suggest not to add hop count at this stage, as it adds more
>    complexity to the processing, in addition for example to reducing TTL
>    - As for the suggestion on the “actions” presented in the meeting
>       - Two types – actions need to get executed by the node vs
>       conditions for any execution
>          - Conditions – there are too many, discussion inclined towards
>          not using specific condition. Going forward the group intend to consider
>          export on exception/alarm without defining what exception/alarm are
>          - Log – needs further discussion. We believe we shouldn’t define
>          what is the protocol and where should the logging reside. The indication to
>          export is what we are using. Need further discussion on export to some
>          preconfigured collector, export to the source of the packet or record the
>          data locally.
>       - Side note regarding rawexport – consider export reason – how and
>    if is it related to the IOAM protocol. Should consider remove it from
>    rawexport?
>    - Tal Mizrahi volunteered to write and publish the 00 draft in
>    collaboration with people who join the design team.
>
>
>
> Thanks,
>
> Barak
>
>
>
> *From:* ippm <[email-masked]> *On Behalf Of * Tal Mizrahi
> *Sent:* Wednesday, July 24, 2019 4:24 PM
> *To:* IETF IPPM WG <[email-masked]>
> *Cc:* IPPM Chairs <[email-masked]>
> *Subject:* [ippm] Side Meeting: IOAM Immediate Export Draft
>
>
>
> Hi,
>
>
>
> Time: Friday, 8:30-9:45.
>
> Room: Coller
>
> https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings
> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fietf%2Fmeeting%2Fwiki%2F105sidemeetings&data=02%7C01%7Cgbarak%40mellanox.com%7C7b0e46c15e5f4cd01d5e08d71074e672%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636995966577906606&sdata=7Qgkw9dlo2wEANwsxk%2B4ndyu%2BYag3OUKRZa0yHm5shQ%3D&reserved=0>
>
>
>
> Details:
>
> We are going to hold a side meeting on Friday morning to discuss the
> outline of the new draft that will describe the immediate export IOAM
> option.
>
>
>
> The meeting is open to all, and specifically intended for authors and
> contributors of the related IOAM drafts.
>
>
>
> Minutes will be sent to the list after the meeting.
>
>
>
> Cheers,
>
> Tal.
>
>
>
>
>
>
>
>
>

---

From: Haoyu Song <[email-masked]>
Date: Fri, 9 Aug 2019 17:24:42 +0000

Sorry I couldn’t attend this meeting personally. For some reason, this thread of emails went to my spam folder and I just found them. It seems we are heading the right direction and making some progress. However, I have the following comments:

  1.  Since the scheme is directly spawned from our existing PBT draft and we have already had detailed discussion in person and through emails on the option, the existing draft which should be used as the basis for further discussion (we have discussed in the email list to show our intention to split the PBT draft and make one dedicate to the new IOAM option). Of course the option header format is subject to change but we already have put a lot of thoughts and efforts on it and it’s unnecessary and counterproductive to start from scratch.
  2.  I don’t understand the reason for the “immediate export” flag. If this means to be another IOAM option for per hop export,  then it’s redundant to have the so-called “immediate export” flag. This principle applies to all other options. The option type should be indicated by the layer which uses it. Did I miss anything here? Please clarify.
  3.  In my opinion, the export packet format/protocol should be maintained in another doc, which should be commonly used by all the IOAM options that need to export data. The rawexp draft is such an example.

Thanks!
Haoyu

From: ippm <[email-masked]> On Behalf Of Barak Gafni
Sent: Friday, July 26, 2019 8:50 AM
To: Tal Mizrahi <[email-masked]>; IETF IPPM WG <[email-masked]>
Cc: IPPM Chairs <[email-masked]>
Subject: Re: [ippm] Side Meeting: IOAM Immediate Export Draft

Hi,

Summary:

  *   Group suggestion: for 00 draft we should define the new IOAM option and keep single flag which tells “immediate export”. Additional capabilities will be discussed towards 01 and beyond
  *   The group is asking the chairs to approve the need for a public IETF mailing list for a “design” team and a public webex to allow the group to progress on a weekly or bi-weekly cadence

More details:

  *   The option is added / removed by the encap/decap nodes, read by the intermediate nodes

  *   Tianran presented option defined a modified form from draft-song-ippm-postcard-based-telemetry-04:

       0             0 0             1 1             2 2             3
       0             7 8             5 6             3 4             1

Below comments came from discussion of the above and the content of immediate export to answer:

  1.  What to export
  2.  Where to export
  3.  When to export

  *   Discussed potential fields in the option header, beyond 00 draft:
     *   Discussed the option to add “actions”, although may change the name
     *   The original flags from the flags draft may be reconsidered
        *   Overflow may become redundant
        *   Active is still relevant
        *   Loopback should be considered
        *   Immediate export – whether it is implicit or should be explicit
     *   IOAM trace type should stay as is to help collector and trace implementation to maintain consistent node data parsing.
     *   Consider whether to have the sequence number and flow id. The interpretation is through the higher layer length. Will be included as optional at the 00 draft
        *   Sequence number – suggestion is to use the e2e sequence number
        *   Anyway, agreement is that the sequence number and the flow id go as a pair.
     *   Flags should reside in a similar place as at the ioam tracing options
  *   Suggest to use the raw export draft to export the data
     *   Need to follow up on the raw export
     *   Need to clarify the behavior, so the node 0 will follow the captured immediate export option
  *   Suggest not to add hop count at this stage, as it adds more complexity to the processing, in addition for example to reducing TTL
  *   As for the suggestion on the “actions” presented in the meeting
     *   Two types – actions need to get executed by the node vs conditions for any execution
        *   Conditions – there are too many, discussion inclined towards not using specific condition. Going forward the group intend to consider export on exception/alarm without defining what exception/alarm are
        *   Log – needs further discussion. We believe we shouldn’t define what is the protocol and where should the logging reside. The indication to export is what we are using. Need further discussion on export to some preconfigured collector, export to the source of the packet or record the data locally.
  *   Side note regarding rawexport – consider export reason – how and if is it related to the IOAM protocol. Should consider remove it from rawexport?
  *   Tal Mizrahi volunteered to write and publish the 00 draft in collaboration with people who join the design team.

Thanks,
Barak

From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tal Mizrahi
Sent: Wednesday, July 24, 2019 4:24 PM
To: IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] Side Meeting: IOAM Immediate Export Draft

Hi,

Time: Friday, 8:30-9:45.
Room: Coller
https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fietf%2Fmeeting%2Fwiki%2F105sidemeetings&data=02%7C01%7Chaoyu.song%40futurewei.com%7C8bc116ea52ec442d6c7008d711e11d65%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636997530875364547&sdata=kZjHPdzWxYag2uuRP3Xu3igBH5sl8eRZIRDk3ked2BI%3D&reserved=0>

Details:
We are going to hold a side meeting on Friday morning to discuss the outline of the new draft that will describe the immediate export IOAM option.

The meeting is open to all, and specifically intended for authors and contributors of the related IOAM drafts.

Cheers,
Tal.