Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporting Design Team Meeting Minutes - September 18th 2019
Tal Mizrahi <tal.mizrahi.phd@gmail.com> Sun, 29 September 2019 09:19 UTC
Return-Path: <tal.mizrahi.phd@gmail.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 37442120045 for <ippm-ioam-ix-dt@ietfa.amsl.com>; Sun, 29 Sep 2019 02:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8C-UjVTyWD0t for <ippm-ioam-ix-dt@ietfa.amsl.com>; Sun, 29 Sep 2019 02:19:38 -0700 (PDT)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 27AA0120071 for <ippm-ioam-ix-dt@ietf.org>; Sun, 29 Sep 2019 02:19:38 -0700 (PDT)
Received: by mail-wm1-x331.google.com with SMTP id 5so10120906wmg.0 for <ippm-ioam-ix-dt@ietf.org>; Sun, 29 Sep 2019 02:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=yVUjRjnRzPGsiL6F4zJcVBfTVnKtQ52zEleQ28nGF+U=; b=s7zjOJBrHqyFV/otjFB2JWW8la5jFL6NhimvrCLDrSosjaVqXqoBhFWGxbUjYFRd3h eaRBz8xhgrzZaAaXxjpjBgOf5Mnk8U7o+IEcGPeUk16NbA3BKXRuLvlAqM75UHJ7jo5R AiveftWkByJirsGZKuI76MLxM2JThQ4Csv0jhS0kacNYqLTxdaa00uMW0buTsE3hzFmu bZxlCyY0+XEzJaVonDyaPzZbtQ9rPB/lC8QkNGXVxivY7bn9IMOFXfJBhKa/0NPFquTy qDdD5o30w3OfJPU3+eftbBc1U539Vw9wFAehfXaFVUfzUstC04PFRwduOCusOujjE463 NnOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=yVUjRjnRzPGsiL6F4zJcVBfTVnKtQ52zEleQ28nGF+U=; b=ivyNZQwxluZeO5zxl/Y2ba6qxE/BDIpl6Il3f7jO3yG12Al1ACkTpYT1/osIpNH0ZO LC2A2SSUQ/kDadxYUqbB0OsxJfPg4k2WoVYz7A2qUWVkgsP7JgouUmMksKoqvJKAjFpQ VRQFLuRATwxOH4im+n+tyYaZzq5/mzFIo/TFV2h/ChDL6wP/FM3HQMVGFyKTXrRdPiRm m5Wlt8QlA6qLoZCXQOAbY924MMisZQ1llbToZA9Yut1IvwyLi7+WgHI+28r3dWbf313X D6dR1CsR21m+IN3cfa2m3rxi6cbBOrG2Dra3Wj2ZsGd0TXzqQePh15o8NUrM6r4r43d/ 4jKg==
X-Gm-Message-State: APjAAAVS9XO5pUyCFFmF4/vYTu29xSDCQ91RnsKxY7iW0yfy8F/p8Oua zPjgXGHka0JerWTEZRN2AVsbMt2CME6aIFCcw0rhnA==
X-Google-Smtp-Source: APXvYqykwzUIS6qyVz/HJOsygY09Q4UgLv3+M0Ob12nG3qFa6PcneWaH/hoSaeIanaQRnG8V6QQFZLVAo0MIApM+nfY=
X-Received: by 2002:a05:600c:1103:: with SMTP id b3mr13702638wma.3.1569748776165; Sun, 29 Sep 2019 02:19:36 -0700 (PDT)
MIME-Version: 1.0
References: <CABUE3XmBDzqyHX9hNCn5vB32BqAdS0k_AgQz8g4qFAs1bd-7mQ@mail.gmail.com> <CABUE3Xmau8YXfFXU7JjafvZ_882bND7KjAy0gspXRacLoUSQKw@mail.gmail.com>
In-Reply-To: <CABUE3Xmau8YXfFXU7JjafvZ_882bND7KjAy0gspXRacLoUSQKw@mail.gmail.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Sun, 29 Sep 2019 12:19:22 +0300
Message-ID: <CABUE3XnvCpnKLYm+bsMgJW8R2nGE8Mws30MoE5rHrLOwz7TUZw@mail.gmail.com>
To: ippm-ioam-ix-dt@ietf.org
Content-Type: multipart/alternative; boundary="00000000000030a3e30593ad9ecc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/Z65j9IlEFSZ2mf2AiFXqe-xSWlw>
Subject: Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporting Design Team Meeting Minutes - September 18th 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, 29 Sep 2019 09:19:41 -0000
The next virtual meeting is this week on Wednesday, October 2nd, at 06:00 UTC. Thanks, Tal. On Sun, Sep 22, 2019 at 12:18 PM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote: > Hi, > > The Hop Count issue was updated based on the discussion in the last > virtual meeting, and based on the comments sent to the mailing list from > Haoyu. Hopefully the current text captures the discussion. > > Here is a link to the Github commit: > > https://github.com/inband-oam/ietf/commit/80a20d25bfcb1b0406a644005b12f9f2e85dd7ba > > > Summary of the last virtual meeting: > > https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/rHBfFHftx1JaTVA2gQoOWOq1hfk > > Haoyu's comments: > > https://mailarchive.ietf.org/arch/msg/ippm-ioam-ix-dt/TcYgy-uKNFjV5sJc0Vy5rEAnKRA > > Cheers, > Tal. > > On Wed, Sep 18, 2019 at 12:35 PM Tal Mizrahi <tal.mizrahi.phd@gmail.com> > wrote: > >> IPPM IOAM Immediate Exporting Design Team >> Virtual meeting >> September 18th, 2019, 06:00 UTC >> Webex meeting >> >> Attendees: >> Shwetha Bhandari, Frank Brockners, Tal Mizrahi, Haoyu Song, Mickey >> Spiegel. >> >> Minutes by Tal Mizrahi. >> >> >> Summary: >> ======== >> - Clarifying text will be added to the IOAM data draft regarding how to >> handle unknown options or uknown flags. >> - Haoyu will create a pull request with new text regarding the Hop Count >> field. >> - The flag draft will be revised, excluding the immediate export flag. >> - Details about the next virtual meeting will be announced next week. >> >> >> Introduction (Tal): >> =================== >> - The draft has been updated on Github: >> >> https://github.com/inband-oam/ietf/blob/master/drafts/versions/00/draft-ioamteam-ippm-ioam-direct-export-00.txt >> - The main changes since the previous version are based on the discussion >> in the last meeting. Two main changes: >> - Updated the "SHOULD" to a "MUST" in "A decapsulating node that does >> not support the DEX option SHOULD remove it". >> - Updated the text about the Hop Limit based on the discussion on the >> meeting. The text now presents the pros and cons of each of the >> alternatives, and proposes to use the Hop_Lim/Node_ID data field when >> necessary. >> >> >> Decapsulating Node Discussion: >> ============================== >> Mickey: regarding the "SHOULD" that was changed to a "MUST", if a node >> does not support direct exporting then it will not necessarily comply to >> this requirement. >> Tal: are you suggesting to add this requirement to the IOAM Data draft? >> Frank: it is hard to specify this requirement differently. It is >> important to avoid IOAM data leaking, and it is important for the readers >> of this draft to be aware of this. >> Mickey: the fact that the decapsulating node must remove all options >> should go into the main data draft. >> Tal: if it is mentioned in the data draft, then we should just mention it >> in the current draft and add a reference to the data draft. >> Mickey: it seems that this is related to the Namespace ID. It is a >> question of whether the decapsulating node should only remove options in a >> Namespace ID it recognizes, or should remove all options. >> Frank: we do not have this statement in the data draft at this point. >> Mickey: we need to add it. >> Tal: in general we need to define in the data draft what we do about >> unknown options, and what we do about unknown flags. >> Mickey: it would be best to ignore them by transit nodes, and remove them >> in decapsulating nodes. >> Frank: just opened an issue about this on Github. >> >> >> Hop Limit Discussion: >> ===================== >> Haoyu: regarding the hop limit discussion, it looks like the current text >> does not include the Hop Limit field in the DEX option. I am not sure we >> are ready to decide to remove it yet. >> Tal: there are two alternatives that are described, either to include an >> explicit Hop Limit field, or to rely on the Hop_Lim/Node_ID data field. The >> pros and cons of each option are desribed. Based on the discussion of the >> previous meeting, the current text relies on the Hop_Lim/Node_ID data field. >> Haoyu: as the text suggests, the two alternatives are not identical. The >> Hop Limit field allows you to detect when there is an IOAM-capable node >> that fails to send the exported packets to the collector. >> Mickey: I agree that the two alternatives are not identical, but avoiding >> an update by transit nodes is an advantage. >> Haoyu: I suggest to ask the working group. >> Tal: this is still not a working group document, so it is early to ask >> the working group. The people who are interested from the working group are >> already involved in this discussion. It is up to us to decide. The current >> text tries to reflect all the pros and cons of each alternative. >> Haoyu: I suggest to change the "Hop Limit" to "Hop Count". >> Mickey: it seems there are three alternatives here. >> Haoyu: no, just two alternatives: either having a "Hop Count" field in >> the IOAM DEX option header, or relying on the Hop_Lim/Node_ID data field. >> The two fields are not identical. >> Shwetha: one of the advantages of the Hop_Lim/Node_ID data field is that >> the option is not modified by transit nodes. The exported data already has >> enough information to know about packet loss, or failure to transport, >> versus failure to export. >> Haoyu: if you can find another way to see if there is a missing exported >> packet from a transit IOAM node, that would be fine. >> Shwetha: there may be another way to reach this requirement, not >> necessarily by adding this field to the DEX option header. >> Mickey: there are two cases: either there is a node that does not support >> IOAM, or there is an IOAM-capable node that does not export data. >> Haoyu: right, if you use a TTL field with the Hop_Lim/Node_ID data field, >> you cannot distinguish between these two cases. You do not know whether >> there is an IOAM-capable node that simply did not export. >> Shwetha: we are assuming there is an operational layer that knows which >> nodes are there, and detects when we are missing exported data from one of >> the nodes, so this does not necessarily need to be done using this field. >> Mickey: would the collector be doing something different in the two cases? >> Haoyu: yes. Only in one of the cases there is a problem - if the >> IOAM-capable node is not exporting correctly. The other case is okay. >> Mickey: we already have a sequence number. >> Haoyu: the sequence number serves a different purpose. it is used for >> matching different exported packets from different nodes. >> Mickey: there is an IPFIX sequence number. >> Haoyu: the Flow ID and Sequence Number are used to match packets from the >> same flow and from different nodes, but does not help in detecting a >> missing packet from an IOAM-capable node. >> Mickey: we have an implementation that allows you to correlate exported >> packets without the Flow ID and Sequence Number. >> Haoyu: but the Hop Count field is not related. >> Frank: the Hop Count addresses a corner case. It does not solve a generic >> problem. So it is not worth a lot of effort unless you get it for free. >> Haoyu: if you use a TTL field you may be misled by IP routers that >> decrement the TTL, but are not IOAM capable. >> Frank: that is a very specific issue. It is a niche, and we do not >> necessarily want to change the solution based on a niche. We discussed this >> in the last meeting and it seems that you are the only one who supports >> this field. >> Haoyu: I am not sure we are ready to decide. I suggest to revise the >> paragraph to clarify it. >> Frank: would you create a pull request? >> Haoyu: yes. >> >> >> Other Issues: >> ============= >> Tal: in the current draft we have removed open issues from the last >> section. I will add the Hop Count back into the list of open issues. >> Tal: are there any other open issues? >> Frank: on a related note, the flags draft has been adopted. We need to >> revise it. Based on the discussion here, we can probably remove the >> immediate export flag. >> Tal: yes, I will remove the immediate export flag, and revise the text >> about the loopback flag based on the discussion on the mailing list. >> Frank: you might want to send the Github draft to the mailing list before >> posting an internet draft. >> >>
- [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporting D… Tal Mizrahi
- Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporti… Tal Mizrahi
- Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporti… Tal Mizrahi
- Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporti… Frank Brockners (fbrockne)
- Re: [Ippm-ioam-ix-dt] IPPM IOAM Immediate Exporti… Tal Mizrahi