Re: [ippm] Draft agenda for IETF 104

Jai Kumar <jai.kumar@broadcom.com> Thu, 21 March 2019 16:04 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 EC378131363 for <ippm@ietfa.amsl.com>; Thu, 21 Mar 2019 09:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FGFCGLyvjD1L for <ippm@ietfa.amsl.com>; Thu, 21 Mar 2019 09:04:03 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 6231713136A for <ippm@ietf.org>; Thu, 21 Mar 2019 09:03:48 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id c207so4583412pfc.7 for <ippm@ietf.org>; Thu, 21 Mar 2019 09:03:48 -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=u6HnZxFzVdy4697Bl/lESCaxFAKXxc4qjSm6w/20hT4=; b=UgU5Vp30pUfgv5RylHNyYklbbAKhomJ6tvuTTp1VSO3pLJqV+rbx53aEbVu0PUytGk 0+iKcg8UItpGWSKOR0A8NQzNOB5QoQm2N1a+s0Wm6aG6Is8Lw/kRIABqY5W5ltQA3MjT Cw6anWMdEu04U3UQtdLI5JQ6rCDG2Vla9PecE=
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=u6HnZxFzVdy4697Bl/lESCaxFAKXxc4qjSm6w/20hT4=; b=T2i+oeVOLOtSp7d/C5hRucbi6UGKZKWnBroBqk5DwRcoQQw6jXdki9R1R6Q5G1v9jF 7kZFNXfys9GkqPJP6w4bhEOgQWSCnb6CzpX0QRzR9n91Xb2a4z4kUnjZRuPNs3l0/C8X gDQ9ZuDX2Ey92VD3014esQS5ODHD0eo2ea+hdtZUifD9k/jNq0QKGkGWLlqoFTN3yvSA an+Dfh4PDcQ5CZzuvuFbaDl9XSVgAPhkJYTKw6b73N/4eOAy9gVZcEbUJLKyi3E/0Hv7 R9IW2Ry5o4Tb+I8vOlKxEjVNv8wsc4xmw5C7D14oskW5ZyzHSEoRD8dG/QRlBx/Y4hhq k+hg==
X-Gm-Message-State: APjAAAWKV8J22CYKrtyvsBhvzcswVIpKroIBX4JiOx2xBHc0ybdm6Im6 HTZ8vjxHXo5TiXc1jofIG2E6sA==
X-Google-Smtp-Source: APXvYqzTE4ohWP/8mVWe19HFEOVPZKp/GLeJnV4+HvmSx4HXOH3T+F9p9ghRZOD/TDCTpo4lZc66Kw==
X-Received: by 2002:a63:4815:: with SMTP id v21mr4066960pga.412.1553184227704; Thu, 21 Mar 2019 09:03:47 -0700 (PDT)
Received: from [10.0.0.131] ([2601:641:c080:5dc3:bdac:11db:cb6a:ffa3]) by smtp.gmail.com with ESMTPSA id k22sm7152506pfi.90.2019.03.21.09.03.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Mar 2019 09:03:45 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.15.0.190117
Date: Thu, 21 Mar 2019 09:03:45 -0700
From: Jai Kumar <jai.kumar@broadcom.com>
To: "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>
CC: IETF IPPM WG <ippm@ietf.org>
Message-ID: <9C6682D8-BE24-4EE9-8DEE-C307B6BFC41A@broadcom.com>
Thread-Topic: [ippm] Draft agenda for IETF 104
References: <F2ABDB31-380C-43B1-9B3D-BB5C5E309DD8@apple.com> <CA+RyBmWS58i3qNgit1P9YZSZn5Op+J4+caWGe8kORJpwXJb-fA@mail.gmail.com> <B6815E8D-48F3-45E8-B71C-C6F3EEBBF7EF@apple.com> <CY4PR11MB13356537CD317FF3AA5925C0DA470@CY4PR11MB1335.namprd11.prod.outlook.com> <BBA82579FD347748BEADC4C445EA0F21B582E9CD@NKGEML515-MBX.china.huawei.com> <CY4PR11MB133513B0A5CD4C96885C7636DA470@CY4PR11MB1335.namprd11.prod.outlook.com> <78A2745BE9B57D4F9D27F86655EB87F93766DC45@sjceml521-mbs.china.huawei.com> <CY4PR11MB13359C67202D1090A2CF264BDA400@CY4PR11MB1335.namprd11.prod.outlook.com> <78A2745BE9B57D4F9D27F86655EB87F93766E9B7@sjceml521-mbs.china.huawei.com> <AM6PR05MB41185E55A62D7A2ECF8427ACB9410@AM6PR05MB4118.eurprd05.prod.outlook.com> <78A2745BE9B57D4F9D27F86655EB87F93766FE9F@sjceml521-mbs.china.huawei.com> <AM6PR05MB41182057A6FF44DE48595535B9410@AM6PR05MB4118.eurprd05.prod.outlook.com> <5A004EB7-517F-4822-B3C8-B73824B748AD@broadcom.com> <AM6PR05MB411832101B597B53598D9983B9420@AM6PR05MB4118.eurprd05.prod.outlook.com> <D09E99B3-7EDD-4AEF-98F1-F4AA961B3524@broadcom.com> <384AF083-6EE8-47BE-9E9B-1B9D9939B15D@cisco.com>
In-Reply-To: <384AF083-6EE8-47BE-9E9B-1B9D9939B15D@cisco.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3636003825_1547592932"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ViQuFaSkIMYwYDYos64RP_VrVBE>
Subject: Re: [ippm] Draft agenda for IETF 104
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, 21 Mar 2019 16:04:09 -0000

Shwetha,

 

I propose to move IOAM metadata to something like https://datatracker.ietf.org/doc/html/draft-ietf-ippm-metric-registry-18

 

As the IOAM metadata is now evolved to use “global name spaces” or template IDs, I feel the name space itself should be standardized.

This will give silicon vendors to pick and choose what name spaces to support and to operators what name spaces makes most sense in the deployment.

 

If this separation is clean enough then this name space can be carried in IOAM protocol extensions, PBT post cards or IFA protocol header based on the operators requirements.

This also gives us as IPPM community to let each evolve in their own domain.

 

I would like to solicit opinion of IPPM WG on this. 

 

Regards,

-Jai

 

 

From: "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>
Date: Wednesday, March 20, 2019 at 10:16 PM
To: Jai Kumar <jai.kumar@broadcom.com>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

Jai,

> My apologies but right the whole slew of IOAM drafts looks like a PhD thesis.

If you are finding navigating through the IOAM drafts challenging, we can help with that. 

Many of us will be in Prague please feel free to reach out and we can meet.

 

The idea of breaking this into data, encapsulations, export and everything else is to help operators focus only on what interests the specific deployments.

As we have discussed in person at IETF103 too, IFA could use the IOAM data and decide to carry it else where in the packet. 

No one is expected to implement and deploy all encapsulations.

 

Thanks,

Shwetha

 

From: ippm <ippm-bounces@ietf.org> on behalf of Jai Kumar <jai.kumar=40broadcom.com@dmarc.ietf.org>
Date: Thursday, March 21, 2019 at 8:13 AM
To: Barak Gafni <gbarak@mellanox.com>
Cc: IETF IPPM WG <ippm@ietf.org>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

Thanks Barak,

 

But this is what is my issue or customers complain is with IOAM. Each case is handled on a case by case basis. What happens to IPSec or other packets where inserting options is not an option. How would it work in IPv6 or SR and so on.

 

My apologies but right the whole slew of IOAM drafts looks like a PhD thesis.

 

Regards,

-Jai

 

 


On Mar 20, 2019, at 5:21 PM, Barak Gafni <gbarak@mellanox.com> wrote:

Jai,

Thanks for the comments.

Please take a look at the new IPv4 options draft, where we did started the discussion about fragmentation, see https://tools.ietf.org/html/draft-gafni-ippm-ioam-ipv4-options-00#section-3.1.5. As a side note, this discussion for the same use case started in RFC 791 chapter 3.1, which we refer to as well. We should continue this discussion and enhance it, appreciate your comments.

For the flow tracking: There are implementations that don’t need this identifier, for them this marking should be enough. For the ones who need it, as part of the discussion on Immediate Export at 05 we suggested to use e2e which can include these indicators, and plan to extend this discussion in the next draft. 

 

Thanks,

Barak

 

From: Jai Kumar <jai.kumar@broadcom.com> 
Sent: Wednesday, March 20, 2019 5:08 PM
To: Barak Gafni <gbarak@mellanox.com>; Haoyu song <haoyu.song@huawei.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

Barak,

 

Please take a look at the IFA draft ver 01.

https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/

 

 

You do not need to add a separate flag. Currently IOAM doesn’t take care of fragmentation (don’t know how it will work with large number of nodes in path or with constrained PMTU).

If you add fragmentation then post card mode becomes a degenerate case of fragmentation where each node generates the report aka post card.

 

Also as Haoyu pointed out earlier there is no method defined in IOAM for co-relation of post cards for a given flow. You will need packetID/FragID or something of that intent to reconstruct the flow path for the packet.

 

Regards,

-Jai

 

 

From: ippm <ippm-bounces@ietf.org> on behalf of Barak Gafni <gbarak@mellanox.com>
Date: Wednesday, March 20, 2019 at 4:39 PM
To: Haoyu song <haoyu.song@huawei.com>, "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, Tianran Zhou <zhoutianran@huawei.com>, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

Hi Haoyu,

Yes, you are right, I meant PBT-I. If you consider the description we added to the Immediate Export flag you may find more similarities in terms of use cases.

I think it can be a good topic to discuss f2f at Prague. Thanks for your comments!

 

Thanks,

Barak

 

From: Haoyu song <haoyu.song@huawei.com> 
Sent: Wednesday, March 20, 2019 11:29 AM
To: Barak Gafni <gbarak@mellanox.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: RE: [ippm] Draft agenda for IETF 104

 

Hi Barak,

 

Thank you for your comments!

I think you are mentioning the PBT-I (The variation which requires an instruction header)?  Although PBT-I and E2E shares similarities but they have different semantics and usage, therefore some difference may be inevitable. I agree we can try to align the header formats which may benefit the implementation, but it seems to me these are two independent modes with each having its specific purpose. Maybe you also mean the same thing.. If you have any specific suggestions, please don’t hesitate to propose. Thank you very much!

 

Best regards,

Haoyu 

 

From: Barak Gafni [mailto:gbarak@mellanox.com] 
Sent: Tuesday, March 19, 2019 10:56 PM
To: Haoyu song <haoyu.song@huawei.com>; Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: RE: [ippm] Draft agenda for IETF 104

 

Hi Haoyu,

I think that there are some relations and similarities between PBT-M and IOAM e2e, it may be good to prevent yet another header format for implementations if we can converge on the already existing e2e format, potentially adding on additional header. Please take a look share your thoughts.

 

Thanks,

Barak

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Haoyu song
Sent: Tuesday, March 19, 2019 3:09 PM
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

Hi Frank and Tommy,

 

Thanks for including our drafts! Please note we also request the IPPM WG adoption of this draft. This time we’d like to achieve rough consensus to make PBT-I a mode of IOAM (the name can be changed of course). This drafts also contains another option (PBT-M) which doesn’t need an instruction header. In this sense, we believe this draft can be developed in its own right. After it’s adopted, we’ll update it to make the alignment. Thanks!

 

Best regards,

Haoyu 

 

From: Frank Brockners (fbrockne) [mailto:fbrockne@cisco.com] 
Sent: Tuesday, March 19, 2019 7:41 AM
To: Haoyu song <haoyu.song@huawei.com>; Tianran Zhou <zhoutianran@huawei.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: RE: [ippm] Draft agenda for IETF 104

 

Haoyu,

 

Thanks – per my other email, I’ve added a new category “IOAM additional options” and also added draft-song-mpls-extension-header-02 to the set of encap options which are covered by a lightening talk.

 

See: https://docs.google.com/presentation/d/1P1Kp9mXA0eKkws78p1tldFn8zqx0YPQ5TK5fnq6Vyz4/

 

Frank

 

From: Haoyu song <haoyu.song@huawei.com> 
Sent: Montag, 18. März 2019 18:28
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tianran Zhou <zhoutianran@huawei.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: RE: [ippm] Draft agenda for IETF 104

 

We currently positioned a part of the draft (PBT-I) a mode of IOAM so it could fit in the IOAM data session.

 

We also have another draft https://tools.ietf.org/html/draft-song-mpls-extension-header-02 for IOAM encapsulation in MPLS networks. We can also use 1 min 1 slide to mention it.. 

Thanks!

 

Haoyu

 

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank Brockners (fbrockne)
Sent: Monday, March 18, 2019 3:11 AM
To: Tianran Zhou <zhoutianran@huawei.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

Hi Tianran,

 

in which category would the draft fit?

 

Thanks, Frank

 

From: Tianran Zhou <zhoutianran@huawei.com> 
Sent: Montag, 18. März 2019 10:42
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: RE: [ippm] Draft agenda for IETF 104

 

Hi Frank and Tommy,

 

I just want to know where the draft-song-ippm-postcard-based-telemetry-02 fit into the agenda?

https://datatracker.ietf.org/doc/draft-song-ippm-postcard-based-telemetry/

Personally, I want to be included in the IOAM slot.

 

Best,

Tianran

 

 

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Frank Brockners (fbrockne)
Sent: Monday, March 18, 2019 5:28 PM
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

Hi IPPM WG,

 

Tommy asked me to facilitate the IOAM discussion. Per Tommy’s note below, we want to discuss the entire set of IOAM related documents and decide on next steps. 

 

Given that we have a pretty large set of IOAM related individual drafts (currently 13 drafts, if I counted things correctly), I suggest that we do a very brief lightening talk (< 1 min – hard policed) on each document and then have a discussion on which categories and documents IPPM WG should consider for adoption.  In order to ease the “lightening talk” section – I’ve created a template https://docs.google.com/presentation/d/1P1Kp9mXA0eKkws78p1tldFn8zqx0YPQ5TK5fnq6Vyz4 - where each draft is listed with title and abstract. An author of each draft should present the key points of the drafts – as well as answer the question, whether IPPM should consider WG adoption.
If you’re an author, please feel free to update the particular slide of your draft according to what you think is required. 

 

Here’s a draft agenda for the 40min IOAM slot:

 

·         IOAM data draft  / WG document (10min)

·         draft-ietf-ippm-ioam-data-05 – 10min

·         Review of individual IOAM drafts by category  (13min, 1min each max)

·         IOAM encapsulation (9min)

·      Draft-weis-ippm-ioam-eth-01 (new)

·      Draft-ioametal-ippm-6man-ioam-ipv6-options-01 

·      Draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 (new)

·      Draft-brockners-ippm-ioam-geneve-02 (new)

·      Draft-gafni-ippm-ioam-ipv4-options-00 (new)

·      Draft-ali-6man-spring-srv6-oam-00 (new)

·      Draft-anand-ippm-po-ioam-02 (new)

·      Draft-gandhi-spring-ioam-sr-mpls-00

·      Draft-ali-spring-ioam-srv6-00 

·         IOAM data export (1min)

·      Draft-spiegel-ippm-ioam-rawexport-01

·         IOAM YANG models/operations (2 min)

·      Draft-zhou-ippm-ioam-yang-03 (new)

·      Draft-mizrahi-ippm-ioam-profile-00 (new)

·         IOAM tools (1min)

·      Draft-xiao-ippm-ioam-conf-state-03 (new)

·         Discussion and Hums (15min)

·         Which categories of IOAM documents make sense for IPPM to adopt?

·         WG adoption of certain drafts (for those categories and drafts which apply)?

 

Did I miss any document that should be added to the list above? If so, please let us know – and add another slide to the google slide deck. 
The deck should be editable by anyone.

 

Thanks, Frank

 

From: ippm <ippm-bounces@ietf.org> On Behalf Of Tommy Pauly
Sent: Mittwoch, 13. März 2019 01:24
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Draft agenda for IETF 104

 

To clarify, the time allocated for IOAM is not allocated just to discuss draft-ietf-ippm-ioam-data. That currently is the one IOAM document that is a WG document, but there is a list of many other documents that have been submitted as "-ippm" individual drafts. We want to use this time to figure out collectively as a group how we want to approach this work going forward, and where the documents best belong. The goal of this discussion is to come out with a clear picture of what work we think makes sense for IPPM. This will hopefully be more fruitful than having many individual lightning talks for these topics.

 

Best,

Tommy

 

On Mar 12, 2019, at 11:12 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

 

Hi Tommy,

given how dense is our agenda for Prague, allotting 40 minutes for one draft seems as overgenerous. If there are updates to IOAM individual drafts, then should these be explicitly listed among other individual drafts that have allocated 5 minutes each?

 

Kind regards,

Greg

 

On Tue, Mar 12, 2019 at 10:35 AM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:

Hello IPPM,

We've posted our draft agent for IETF 104 here:
https://datatracker.ietf.org/meeting/104/materials/agenda-104-ippm-00

We have a two-hour slot, and are pretty full! The chairs have discussed and would like to have two more extended discussions this time about:
- Finalizing the metrics and initial registries, so we can get those out the door
- How we should progress with IOAM and the large cluster of related documents. We'll ask that instead of having any lightning talks on related IOAM documents, we have a broader discussion about what we're doing for these.

After that, the agenda is made up of 5 minute lightning talks, with a group of related alt-mark documents at the start. Apologies that we can't have longer time for these!

Suggestions or bashing welcome!

Best,
Tommy

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

 

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