Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Thu, 19 April 2018 16:54 UTC
Return-Path: <fbrockne@cisco.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEE5124319; Thu, 19 Apr 2018 09:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RcszXUzrhsPW; Thu, 19 Apr 2018 09:54:29 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881E91200C5; Thu, 19 Apr 2018 09:54:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20968; q=dns/txt; s=iport; t=1524156869; x=1525366469; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=a493VFuvdNvvQFNIkqGOuioxGgYwOqBj0vMllBP93BA=; b=FjX5kv9tBvvjQWQsvMayhKOLjSD37d1BezMNfyFDIqnKty/Sevp8GYom 76Ha+v4JslAJQYwQmqC6NeNcFtZ/QRAQS6O2c4xCz2Uo6E+aZTBsax+Rl RAlZgD7ZGr2OsaylZqBA3hRaWwN9aZV1YasbssFVQ/nEXisJWQgJVB5/i Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlAgCOydha/4ENJK1bGQEBAQEBAQEBAQEBAQcBAQEBAYJNdWEXYygKg16IAox3gXSBD4Zqhx2EbIF4CxgBCoRGAhqCJyE0GAECAQEBAQEBAmwcDIUiAQEBAQMBASEKQQsQAgEIEQQBASQEAwICAh8GCxQJCAEBBA4FCBeECkwDFQ+mMIIchwsNgSuCIAWIBoFUP4EPgwuCT0IBAYE9WYJKglQCl0EsCAKLAzuCdYxViXOGDQIREwGBJAEcOIFScBU7gkOCHRoRiEiFPm+PK4EYAQE
X-IronPort-AV: E=Sophos;i="5.48,469,1517875200"; d="scan'208,217";a="386652477"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2018 16:54:27 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w3JGsREg026349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Apr 2018 16:54:27 GMT
Received: from xch-rcd-008.cisco.com (173.37.102.18) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 19 Apr 2018 11:54:26 -0500
Received: from xch-rcd-008.cisco.com ([173.37.102.18]) by XCH-RCD-008.cisco.com ([173.37.102.18]) with mapi id 15.00.1320.000; Thu, 19 Apr 2018 11:54:26 -0500
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: IETF IPPM WG <ippm@ietf.org>, NVO3 <nvo3@ietf.org>, Service Function Chaining IETF list <sfc@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
Thread-Index: AdPRe/DslDwu34XkSmq8g6ttV3Kt0QGp44SAAAmXEdA=
Date: Thu, 19 Apr 2018 16:54:26 +0000
Message-ID: <81b2598c54944ba887248cbce2f66575@XCH-RCD-008.cisco.com>
References: <ff0c9182d1f14ec48b352e41fedaf58e@XCH-RCD-008.cisco.com> <CA+RyBmWKyv+iDsQdAum0xP5FbEb5hvc7AQm+SOvt5b7myjBtHg@mail.gmail.com>
In-Reply-To: <CA+RyBmWKyv+iDsQdAum0xP5FbEb5hvc7AQm+SOvt5b7myjBtHg@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.117.3]
Content-Type: multipart/alternative; boundary="_000_81b2598c54944ba887248cbce2f66575XCHRCD008ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/Z0BLjgjwbM2f1Mq55-hHpM3k1gA>
Subject: Re: [nvo3] [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Apr 2018 16:54:32 -0000
Hi Greg, good catch – there is a bit of loose language in some of the drafts. We’ll make things crisper in the next rev. Note that there is no generic “IOAM header” but that definition is always within the context of a particular encapsulation protocol. draft-weis-ippm-ioam-gre-00 already has a definition of the IOAM header (for GRE) – see section 3. For the other drafts, we use language like “The IOAM related fields in VXLAN-GPE are defined as follows” or “The fields related to the encapsulation of IOAM data fields in Geneve are defined as follows”, i.e. the information that is required to perform the encapsulation into the parent protocol, along with the actual IOAM data fields. Moving forward, we can be crisper and split things into an “encapsulation dependent part” and a “data part”. Frank From: Greg Mirsky <gregimirsky@gmail.com> Sent: Donnerstag, 19. April 2018 18:15 To: Frank Brockners (fbrockne) <fbrockne@cisco.com> Cc: IETF IPPM WG <ippm@ietf.org>; NVO3 <nvo3@ietf.org>; Service Function Chaining IETF list <sfc@ietf.org>; int-area@ietf.org Subject: Re: [ippm] encapsulation of IOAM data in various protocols - follow up from WG discussion in London Hi Frank, et. al, we have a very good discussion, thank you. I have a question and appreciate your consideration: * encapsulation documents refer to IOAM HDR, its length is reflected in the field labeled either Length or IOAM HDR len. But I cannot find the definition of IOAM HDR. What is the IOAM HDR? Regards, Greg On Wed, Apr 11, 2018 at 3:02 AM, Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com>> wrote: Back at the IPPM meeting in London, we discussed several drafts dealing with the encapsulation of IOAM data in various protocols (draft-brockners-ippm-ioam-vxlan-gpe-00, draft-brockners-ippm-ioam-geneve-00, draft-weis-ippm-ioam-gre-00). One discussion topic that we decided to take to the list was the question on whether draft-ooamdt-rtgwg-ooam-header could be leveraged. After carefully considering draft-ooamdt-rtgwg-ooam-header, I came to the conclusion that the “OOAM header” does not meet the needs of IOAM: * Efficiency: IOAM adds data to live user traffic. As such, an encapsulation needs to be as efficient as possible. The “OOAM header” is 8 bytes long. The approach for IOAM data encapsulation in the above mentioned drafts only requires 4 bytes. Using the OOAM header approach would add an unnecessary overhead of 4 bytes – which is significant. * Maturity: IOAM has several implementations, which were also shown at recent IETF hackathons – and we’re expecting additional implementations to be publicized soon. Interoperable implementations need timely specifications. Despite the question being asked, the recent thread on OOAM in the NVO3 list hasn’t revealed any implementation of the OOAM header. In addition, the thread revealed that several fundamental questions about the OOAM header are still open, such as whether or how active OAM mechanisms within protocols such as Geneve would apply to the OOAM header. This ultimately means that we won’t get to a timely specification. * Scope: It isn’t entirely clear to which protocols the OOAM header would ultimately apply to. The way the OOAM header is defined, OOAM uses a 8-bit field for “Next Prot”, the next protocol. Some protocols that IOAM data needs to be encapsulated into use 16-bits for their next protocol code points. See e.g. the GRE encapsulation – as specified in draft-weis-ippm-ioam-gre-00. With the above in mind, I’d suggest that the WG moves forward with specific definitions for encapsulating IOAM data into protocols – per the above mentioned drafts. Regards, Frank _______________________________________________ ippm mailing list ippm@ietf.org<mailto:ippm@ietf.org> https://www.ietf.org/mailman/listinfo/ippm
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Frank Brockners (fbrockne)
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Greg Mirsky
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Greg Mirsky
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Mickey Spiegel
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Carlos Pignataro (cpignata)
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Carlos Pignataro (cpignata)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… 徐小虎(义先)
- Re: [nvo3] [Int-area] [ippm] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Mickey Spiegel
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Uma Chunduri
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Shwetha Bhandari (shwethab)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tianran Zhou
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] [Int-area] encapsulation of IOA… Tom Herbert
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… John Lemon
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Frank Brockners (fbrockne)
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Greg Mirsky
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… John Lemon
- Re: [nvo3] [ippm] encapsulation of IOAM data in v… Frank Brockners (fbrockne)
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Carlos Pignataro (cpignata)
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Tom Herbert
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Carlos Pignataro (cpignata)
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Tom Herbert
- Re: [nvo3] [sfc] [ippm] [Int-area] encapsulation … Carlos Pignataro (cpignata)