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

Jai Kumar <jai.kumar@broadcom.com> Thu, 01 August 2019 00:02 UTC

Return-Path: <jai.kumar@broadcom.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C95120110 for <ippm@ietfa.amsl.com>; Wed, 31 Jul 2019 17:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3lWu1dizkEm for <ippm@ietfa.amsl.com>; Wed, 31 Jul 2019 17:02:12 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABDD120108 for <ippm@ietf.org>; Wed, 31 Jul 2019 17:02:12 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id i18so32876875pgl.11 for <ippm@ietf.org>; Wed, 31 Jul 2019 17:02:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=eUXwWAYbAs3RdMCcIGxWg9RKp13fCuYz7nWf6cyL0xo=; b=hGwgecfVmMtCSFxIqhu4bMIQURqivAuJb1xfrbrXBzjqFzlu0yDdbSlE9j0bJqHHlN ICs7EbpwuZPEmll3VsFQldKafPgs0kmCrrZMVeDGNZEYuDW42P5TsmKSltqxmkU+8UeA M0Dg6ujGD1MAM0HHpyEjqyknA3V93wus/qPeM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=eUXwWAYbAs3RdMCcIGxWg9RKp13fCuYz7nWf6cyL0xo=; b=cu7d68NQQH9QrZ/KeaAqPDOCS8dN8Ecy9MhG/Unbv03LITu/FSf583SeJal7eUidII e9NjaCSuDCAIsssQKZtPqwwFgxhcu0PYJTMzn+V/S64hR/6bqzGITvf0GwQRomdoqwDC d6USmXestVDmJEVso7UJc822aGAM04kvg/jrbKK0o2YWI77ZBpN66iYgILhTTXkZSX5h dI63Dw8aqyZ7Z125sIVyZiINieF6PcASIJ8I26bdedpfzptJ0qomPO53j8m8D34FbSVQ U2Q9qsjupWKFwVdzExGTYiviCgtP/G11ORnLnP8C5GjXNl7LdZDIYRLe73zansSrdac4 ogQg==
X-Gm-Message-State: APjAAAVD8/aonGtdiLrvieiUbWzT3QfDYvFzOwcZCybCsO5s9sF76AhZ urVSL5wyvUawsTN0mJd9WxZzTA==
X-Google-Smtp-Source: APXvYqx+rzzKDLfOL8rSk881qN5RmIVfAcOeoZ2lYwTxoJ+3Cd2PQpj/5QIToSaUtYqZC92sMtmyBA==
X-Received: by 2002:a62:1ac9:: with SMTP id a192mr10031387pfa.260.1564617731931; Wed, 31 Jul 2019 17:02:11 -0700 (PDT)
Received: from [10.58.68.119] ([192.19.222.250]) by smtp.gmail.com with ESMTPSA id a1sm20161005pgh.61.2019.07.31.17.02.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 17:02:11 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.1b.0.190715
Date: Wed, 31 Jul 2019 17:02:06 -0700
From: Jai Kumar <jai.kumar@broadcom.com>
To: Barak Gafni <gbarak@mellanox.com>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, IETF IPPM WG <ippm@ietf.org>
CC: IPPM Chairs <ippm-chairs@ietf.org>, Surendra Anubolu <surendra.anubolu@broadcom.com>, John Lemon <john.lemon@broadcom.com>
Message-ID: <73D7831F-AEB6-4D29-84A6-52FCAB627209@broadcom.com>
Thread-Topic: [ippm] Side Meeting: IOAM Immediate Export Draft
References: <CABUE3XnsPgdZB1_hF1KXqhw77-0h=xhJNZ+EB97b-=8C9GAAzg@mail.gmail.com> <AM6PR05MB411860A61F807A0BCA6196C4B9C00@AM6PR05MB4118.eurprd05.prod.outlook.com>
In-Reply-To: <AM6PR05MB411860A61F807A0BCA6196C4B9C00@AM6PR05MB4118.eurprd05.prod.outlook.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3647437330_1247312240"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/oazXr948yn3gV33keRQFB414qWY>
Subject: Re: [ippm] Side Meeting: IOAM Immediate Export Draft
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Aug 2019 00:02:15 -0000

Barak,

 

Please include John, Surendra and myself from Broadcom in the design team.

 

We will shortly get back to you with some thoughts on 00 draft.

If the alias is active, we can send it there. Let us know.

 

-Jai

 

From: ippm <ippm-bounces@ietf.org> on behalf of Barak Gafni <gbarak@mellanox.com>
Date: Friday, July 26, 2019 at 8:50 AM
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>, IETF IPPM WG <ippm@ietf.org>
Cc: IPPM Chairs <ippm-chairs@ietf.org>
Subject: Re: [ippm] Side Meeting: IOAM Immediate Export Draft

 

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:
What to export
Where to export
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 <ippm-bounces@ietf.org> On Behalf Of Tal Mizrahi
Sent: Wednesday, July 24, 2019 4:24 PM
To: IETF IPPM WG <ippm@ietf.org>
Cc: IPPM Chairs <ippm-chairs@ietf.org>
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

 

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.

 

 

 

 

_______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm