Re: [Ippm-ioam-ix-dt] IPPM IOAM Exporting Design Team Meeting Minutes - October 2nd 2019

Tianran Zhou <zhoutianran@huawei.com> Sun, 06 October 2019 13:33 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: ippm-ioam-ix-dt@ietfa.amsl.com
Delivered-To: ippm-ioam-ix-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33FE120058 for <ippm-ioam-ix-dt@ietfa.amsl.com>; Sun, 6 Oct 2019 06:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 79ilOhlqXsVz for <ippm-ioam-ix-dt@ietfa.amsl.com>; Sun, 6 Oct 2019 06:33:20 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8575B12003F for <ippm-ioam-ix-dt@ietf.org>; Sun, 6 Oct 2019 06:33:20 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C504CA8D85E27993B030; Sun, 6 Oct 2019 14:33:17 +0100 (IST)
Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 6 Oct 2019 14:33:17 +0100
Received: from lhreml730-chm.china.huawei.com (10.201.108.81) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sun, 6 Oct 2019 14:33:16 +0100
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Sun, 6 Oct 2019 14:33:16 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Sun, 6 Oct 2019 21:33:10 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>, "ippm-ioam-ix-dt@ietf.org" <ippm-ioam-ix-dt@ietf.org>
Thread-Topic: [Ippm-ioam-ix-dt] IPPM IOAM Exporting Design Team Meeting Minutes - October 2nd 2019
Thread-Index: AdV8SiUDrFrDdLLxTcOoXUDeGwRYPA==
Date: Sun, 06 Oct 2019 13:33:08 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BF00AFFA@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.215.219]
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BF00AFFANKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/QPg_9eQkD6_MOrsebpnmB_cjxUQ>
Subject: Re: [Ippm-ioam-ix-dt] IPPM IOAM Exporting Design Team Meeting Minutes - October 2nd 2019
X-BeenThere: ippm-ioam-ix-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPPM iOAM Immediate Export \(IX\) design team" <ippm-ioam-ix-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm-ioam-ix-dt>, <mailto:ippm-ioam-ix-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm-ioam-ix-dt/>
List-Post: <mailto:ippm-ioam-ix-dt@ietf.org>
List-Help: <mailto:ippm-ioam-ix-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm-ioam-ix-dt>, <mailto:ippm-ioam-ix-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Oct 2019 13:33:24 -0000

Hi Team,

I have just submitted a pull request the repo to document our discussion.
https://github.com/inband-oam/ietf/pull/136

Please review and commit.
I think it’s good enough to share with the community and ask for the wg adoption.

Cheers,
Tianran

发件人: Ippm-ioam-ix-dt [mailto:ippm-ioam-ix-dt-bounces@ietf.org] 代表 Tal Mizrahi
发送时间: 2019年10月2日 15:12
收件人: ippm-ioam-ix-dt@ietf.org
主题: [Ippm-ioam-ix-dt] IPPM IOAM Exporting Design Team Meeting Minutes - October 2nd 2019

IPPM IOAM Immediate Exporting Design Team
Virtual meeting
October 2nd, 2019, 06:00 UTC
Webex meeting


Attendees:
Shwetha Bhandari, Frank Brockners, Tal Mizrahi, Ramesh Sivakolundu, Haoyu Song, Tianran Zhou.

Minutes by Tal Mizrahi..


Summary:
========
- The Hop Count issue was discussed, with no clear decision at this point.
- Next steps:
  - Tianran will propose new text for the Hop Count description in the "Issues for Further Discussion" section.
  - Once this text is reviewed the draft will be post (draft 00), asking for feedback from the WG.


Introduction (Tal):
===================
- The main open issue in the direct exporting draft is the Hop Count issue.
- We have updated the preliminary draft on Github based on the discussion from the previous meeting.
- The latest commit was presented:
  https://github.com/inband-oam/ietf/commit/80a20d25bfcb1b0406a644005b12f9f2e85dd7ba#r35312342
- Tianran suggested on the mailing list to make the Hop Count field optional, by using a flag that indicates whether the Hop Count is present or not.


Hop Count Discussion
====================
Tianran: the optional approach can be a good solution. On one hand it addresses the use case we talked about, and on the other hand does not require transit switches to update the option if not supported.
Ramesh: how is this different than using the Hop_Lim/Node_ID data field in the exported packet?
Tianran: in Layer 2 encapsulations the Hop_Lim/Node_ID data field cannot be used, since the TTL is not available. Another example is hierarchical VPNs, where the TTL is not available.
Haoyu: I have summarized a few differences between the Hop Count field and the Hop_Lim/Node_ID data field. This is beyond the two examples Tianran just mentioned. Using a flag to indicate an optional Hop Count field enables to control the tradeoff. Furthermore, there is no cost in terms of the header length, since we are reusing some of the existing bits.
Shwetha: do you recommend to use the Hop Count field only in encapsulations that do not have the TTL (such as L2 encapsulations)?
Haoyu: it is possible, but the argument for the Hop Count is not only encapsulations that do not have a TTL. The flag allows you to use the Hop Count in other encapsulations as well.
Tianran: yes, it is possible in other encapsulations, such as IPv6.
Tal: I suggest that Tianran creates a pull request updating the Hop Count text. Hopefully we can send this as an open issue to the working group.
Tianran: a question to implementers in this meeting: is there a technical problem to enable this option?
Ramesh: even if we define it as optional, it will end up being implemented. So having an option is not necessarily helpful. What were the arguments in the previous meetings?
Haoyu: the main argument against the Hop Count field was that transit nodes have to update the direct export option.
Ramesh: doesn't the Hop_Lim/Node_ID data field provide the same functionality?
Haoyu: not exactly. As we explained, the Hop_Lim/Node_ID data field does not indicate when an IOAM-capable node fails to export data to the collector.
Ramesh: how do you make it optional?
Tianran: we use a flag to indicate that the Hop Count is there. Four bits for a Hop Count may be enough, but we may consider Eight bits. We can also think of intermediate numbers.
Ramesh: we are running out of flag bits, so we need to be careful.
Tianran: right now there are more flags than we need.
Ramesh: so the main argument against Hop Count was that every transit node had to do a read-modify-write?
Tianran: yes.. But using the optional approach you can just disable it.
Tal: can you update the section that describes the Hop Count issue?
Tianran: yes.
Tal: any other issues we want to discuss?
Tianran: what is the next step?
Tal: once we phrase the Hop Count issue as a question to the working group, in my opinion we can post the draft in the next week or two.
Tianan: any other comments about the optional approach?
Shwetha: I am not sure there is a real use case for an encapsulation that does not include a TTL..
Tianran: one example is the Layer 2 encapsulation.
Shwetha: but right now there is no encapsulation that has been defined directly over Layer 2.
Haoyu: there is the Ethertype-based encapsulation.
Tianran: the encapsulation is actually another topic that we want to discuss later. We want this draft to be general enough to apply to future encapsulations as well.. IFA also proposed to encapsulate OAM over UDP. Our approach is universal / generic.
Shwetha: so the device that looks at IOAM does not update the L3 TTL?
Tianran: right.
Shwetha: a device that looks beyond L3 will also update the L3 TTL.
Tianran: in some implementations UDP encapsulation is used without updating the TTL. In Layer 2 forwarding the device may look deeper into the packet and do some processing.
Frank: from a standard perspective, a bridge is L2, and a router is L3. Having a bridge that looks deeper than L2 into the packet is not applicable from a standard perspective, even if in practice it exists. From an IETF perspective it does not exist.
Tianran: some encapsulations are not standardized.
Frank: right, so you can implement some proprietary features, but not all can be standardized in the IETF.
Tianran: we are just suggesting an optional approach for Hop Count. The L2 encapsulation is just an example.
Frank: I do not see a device that would do that.
Haoyu: that is because such devices do not exist yet.
Frank: if you want to define the behavior of a bridge you need to go to the IEEE.
Haoyu: the purpose is to make the current proposal flexible. The Hop Count is optional.
Frank: the whole discussion can be in a separate section / document. The Hop Count is not related to direct exporting. The point of direct exporting is just to signal to transit nodes when they need to export, without changing data packets.
Haoyu: we do not change the header in-transit, but only update the Hop Count.
Frank: you are changing the packet in-flight.
Haoyu: one of the benefits of direct exporting is that transit nodes do not increase the length of the packet. The Hop Count just helps the collector to correlate the packet.
Frank: you are still updating the packet on per-hop basis.
Haoyu: but there is a need to correlate the packet, and we need to find a way to do that. This is our current proposal. We should ask the community to decide.
Tal: I suggest to update the description in the "Issues for further discussion" in a way that summarizes all the arguments on both sides. Then we can post the draft and ask for feedback from the working group.
Tianran: I am fine with that.
Frank: documenting the discussion is the best we can do.