Re: [ippm] Review on draft-ietf-ippm-ioam-data-06

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 21 August 2019 11:34 UTC

Return-Path: <cpignata@cisco.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 5C3361200C4; Wed, 21 Aug 2019 04:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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 header.b=KNtuJS3Y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mc0YWe6M
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 xy4eVnDXo2m7; Wed, 21 Aug 2019 04:34:30 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644FB120041; Wed, 21 Aug 2019 04:34:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18245; q=dns/txt; s=iport; t=1566387270; x=1567596870; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Exw9fdFlYVNGDQqs2PbzE4L9QekKC1HDUei3OkO3Lg4=; b=KNtuJS3YMIHT8B11C8awNsd7Huw03wTdQJYfUUppN04phcPMqFJmB3eH Rs+DLiWHv4nx3gY/nK5f3LHFLYpGFK4uIx3TCpopjWz2f5faIfY8YFP4n 3Jq0RimKhZvJulB1R7bm7lYfxjn2D3MnbEMYlK9/AR/x5CjfmMPQ2AMmB s=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALG0Y5x94dVXKbP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcWdCEL9JeLjRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAABxK11d/5xdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBgRUvUANtVSAECyoKhBWDRwOKfU2VGoR?= =?us-ascii?q?agUKBEANUCQEBAQwBASMKAgEBhD8CF4JFIzcGDgIFAQEEAQEDAQYEbYUnDIV?= =?us-ascii?q?LAgQSER0BASUSAQ8CAQYCPwMCAgIwFBECBA4FGweDAAGBHU0DHQECDI5gkGE?= =?us-ascii?q?CgTiIYXOBMoJ7AQEFgUZBgxUYghYDBoE0AYRzhnUYgUA/gREnH4JMPoJhAQE?= =?us-ascii?q?CAQGBKgESAQcvFoJeMoImjB0SDoIpMYUPI4hfjjEJAoIdhmiNURuCMYcwhBi?= =?us-ascii?q?EYIVtlT6QKwIEAgQFAg4BAQWBZiJncXAVOyoBgkGCQoNyhRSFP3IBgSiJO4E?= =?us-ascii?q?iAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.64,412,1559520000"; d="scan'208,217";a="618978222"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 11:34:28 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7LBYSOh023522 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 11:34:29 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 06:34:28 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 06:34:27 -0500
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Aug 2019 06:34:27 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YiRtKgHXRZd391uJdcpNjht+jXXMpTscKPmT50SoEkxnajzfPTqyrvm9VGkTGMCYeFPVSN2MLJANef3P6C0QzruyZiwtubY8EZfCiyidtg5jK1JZMsyY/pW+saEqb8FffJIHrdNcpuVaJzqX+psONTXl/n8S6wqrEIHdiivcAE18QYjpb125Mig9Ebxk+2k4x6qQBnxRFDi/AN3jnjAK6kAle45PDbbCAPprFxaKTsyp2mvfi8VceIZXEDIXz7WDEccPVHfn/TBc+JOzUgXTzLGZ+ZZyqSPg/Sk1o7p2tRG6wlXmIKoXHL/B/7TCX0pSTsPLfQiRC5bc0VqlKABFfQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Exw9fdFlYVNGDQqs2PbzE4L9QekKC1HDUei3OkO3Lg4=; b=bAsE0PrFZH3+3LbG7Ehlgu1IFN9r5+teyIO0B+K9KZbHwTvG7UaAnUTe3hzOLf/n8oHo+epCJ7kOjW7WEyWLb6eiuPQgjPk0k0GqkQQa0JRD90HnKjZfcMmLFvVTnCior96keFTE1YwBZL4Qu9EyUv50ZzTfQaFmwJdIqSrD7s9vibyX13ZZyJrxRLDyf8JS5fFejR+xo8K31FiiZS1E8UukPvL1QNw5qe3sM9slC7uvgiXiDIPOyeP4EcELik+BFVKKnK0YHQoLPwVc6wMrqeOke4tgrMSQg/m5SPbqDBfuOOC+QUhplx97Zu7z8b5H1VuowSPGeuM5jPO0CiOPZQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Exw9fdFlYVNGDQqs2PbzE4L9QekKC1HDUei3OkO3Lg4=; b=mc0YWe6McrHCDevUVYTSLlf08tr315NV8JLJ6u27MuQGSLVk2SF2pL35EMWEFzUO41GPfVGErOPL4fFA9bEmDZZUBUbXF0nYFYfFXKdw9P8QI9cPpHUsXrxpMLNJaqvr8Vta3MRwHttMfp9l4zbTYakEFjF6caoC/6OEaOgWnS4=
Received: from BL0PR11MB3028.namprd11.prod.outlook.com (20.177.204.138) by BL0PR11MB2964.namprd11.prod.outlook.com (20.177.205.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.18; Wed, 21 Aug 2019 11:34:26 +0000
Received: from BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::1129:b8ad:27b9:151f]) by BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::1129:b8ad:27b9:151f%6]) with mapi id 15.20.2178.020; Wed, 21 Aug 2019 11:34:26 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Vijay Rangarajan <vijayr@arista.com>
CC: Jai Kumar <jai.kumar@broadcom.com>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>, IETF IPPM WG <ippm@ietf.org>, "Frank Brockners (fbrockne)" <fbrockne@cisco.com>, Hugh Holbrook <holbrook@arista.com>, Anoop Ghanwani <Anoop.Ghanwani@dell.com>, "OU, Heidi" <heidi.ou@alibaba-inc.com>, Surendra Anubolu <surendra.anubolu@broadcom.com>, John Lemon <john.lemon@broadcom.com>
Thread-Topic: [ippm] Review on draft-ietf-ippm-ioam-data-06
Thread-Index: AQHVV8dSUIHq/ij1ckKKv5AbPc40G6cFZ5UAgAARomA=
Date: Wed, 21 Aug 2019 11:34:26 +0000
Message-ID: <BD32CF3D-C6F3-4CF6-A618-C41ED0C4D1CB@cisco.com>
References: <B5A76AB5-AE39-4771-9472-38454CF52152@broadcom.com>, <CAGn858RE4p8gez+b0=9PSsZQ=Y1uZANno5V7tqSo=cuqY7AJLA@mail.gmail.com>
In-Reply-To: <CAGn858RE4p8gez+b0=9PSsZQ=Y1uZANno5V7tqSo=cuqY7AJLA@mail.gmail.com>
Accept-Language: en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com;
x-originating-ip: [108.203.7.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 35640803-0f46-4a9f-29e0-08d7262b85a9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BL0PR11MB2964;
x-ms-traffictypediagnostic: BL0PR11MB2964:
x-ms-exchange-purlcount: 3
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BL0PR11MB2964720E0C9204BAFFB76680C7AA0@BL0PR11MB2964.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0136C1DDA4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(366004)(376002)(39860400002)(53754006)(189003)(199004)(478600001)(81156014)(8676002)(81166006)(3846002)(6116002)(36756003)(6486002)(229853002)(8936002)(2906002)(71190400001)(71200400001)(6916009)(66066001)(66476007)(66556008)(64756008)(66446008)(66946007)(561944003)(54906003)(316002)(33656002)(7736002)(102836004)(6506007)(53546011)(26005)(5660300002)(256004)(14444005)(2616005)(476003)(446003)(11346002)(76116006)(486006)(4326008)(5070765005)(6246003)(25786009)(6436002)(86362001)(14454004)(76176011)(236005)(54896002)(6512007)(966005)(6306002)(606006)(186003)(53936002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB2964; H:BL0PR11MB3028.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: KwsJrNFoZlPstwzco5Neph2snVFunEgHHZRoHgKaJKF1v/IGum1YcR8h4HJIsiDLiFi90Vaj5P7j63CZWIuWJqD3Tnf0jISYaAYjmScie5tJARFF2GZdQtl7QzwFJlJ6s8t5adQZa97M3mr+mRkLPXLbaPNPGyfW883eNYtP3zJRDaEGrkQ4Qf4kzEzJ188EfHIITGiz2E7Og8N4ATa2PHL5Lnrlo00bw9zed4L2AYpgbKhS5LCsxrPgI+qw7oR+tMniMErOHtX9abzGsG1jcy0IgsaB53p4z74V+m4oVlmfkQvotNVwKm+2x/lmrcZp11u3k2O7Fhhoi3QJCnA7O7xy64prvOWtwM6pRDPrHz/Npisy+c2GDdy+HgO8evzKG7NBd6rgNgPhwqNRfXXTxpCKnD2/LILCj5IMLI6/nmo=
Content-Type: multipart/alternative; boundary="_000_BD32CF3DC6F34CF6A618C41ED0C4D1CBciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 35640803-0f46-4a9f-29e0-08d7262b85a9
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 11:34:26.2030 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LYr8L3GvAnY+1isq/trB9T4EISgbt2GsIhEusdnTnV4v9wJEv8wtiWgBWO/LDCjQnCtNu8m4iSbEIVB8i96gaQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2964
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/4g88YkQ9QyucTcMR6iAfXxrgfQw>
X-Mailman-Approved-At: Wed, 21 Aug 2019 08:58:14 -0700
Subject: Re: [ippm] Review on draft-ietf-ippm-ioam-data-06
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: Wed, 21 Aug 2019 11:34:33 -0000

Hello, Vijay,

Please see https://datatracker.ietf.org/doc/draft-weis-ippm-ioam-eth/, and the document this replaces.

Thanks!

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

2019/08/21 6:35、Vijay Rangarajan <vijayr@arista.com<mailto:vijayr@arista.com>>のメール:

Hello all:
Apologise if this has been previously discussed.
In reading "draft-ietf-ippm-ioam-data-06", I don't see mention of GRE encap. The draft, in fact in Sec 3, says the following - "The in-situ OAM data field can be transported by a variety of transport protocols, including NSH, Segment Routing, Geneve, IPv6, or IPv4.  Specification details for these different transport protocols are outside the scope of this document."

Is there another document, or a description somewhere, that talks about how IOAM is proposed to be carried in GRE? what would be the GRE payload, the GRE protocol type etc?

Thanks,
Vijay


On Wed, Aug 21, 2019 at 7:52 AM Jai Kumar <jai.kumar@broadcom.com<mailto:jai.kumar@broadcom.com>> wrote:
Hello Frank,

This is in context of our conversation at IETF105. My goal is to provide input and improve current IOAM data draft with the learnings we had with IFA deployment.
This feedback is based on various customer interactions and concerns raised by them wrt IOAM. Each feedback is a longer topic and I am starting this thread as a summary email. This is just highlighting the issues and not yet proposing any solution.


Feedback 1:
Section 4.2.1 Pre-allocated and Incremental Trace Options
Pre-allocated and incremental trace option is 8Bytes long. This can be easily reduced to 4Bytes.
There is a feedback that pre-allocated option is really not needed and either be removed or made optional.
Given that deployments are sensitive to the IOAM overhead (specially in 5G deployments), it’s a 50% fixed overhead savings on a per packet basis.


Feedback 2:
Section 4.1 IOAM Namespaces
Namespaces should be treated as templates (similar to IPFIX template record formats). This is more flexible way of enumerating data. 64K namespace id is a very large namespace and can be reduced to 64 IANA specified name spaces. Separate private name space can be allowed instead of interleaving of opaque data in the IANA allocated name space as suggested in the current draft “opaque state snapshot”.
https://tools.ietf.org/html/rfc7011#section-3.4

Feedback 3:
Section 4.2.1 Pre-allocated and Incremental Trace Options
IOAM-Trace-Type:  A 24-bit identifier which specifies which data
      types are used in this node data list.
This is the most contentious of all. In the current proposal, as new data fields are added, there is a corresponding trace type bit need in the header. This essentially means that all possible data fields need to be enumerated. Given that we there are 64K names spaces allowed, I don’t see how we can fit all possible data fields in this 24bit vector. I know there was a suggestion of keeping last bit as an extension bit but it is still scalable and/or easy to implement in hardware. Besides this the data fields are not annotated/encoded with the data type, something like in IPFIX https://tools.ietf.org/html/rfc7011#section-6.1

Feedback 4:
There is no version field in the data header and this will make interoperability challenging. Standard will evolve and headers bit definition and/or trace type will change and without version field HW will not be able to correctly handle the IOAM data headers.

Feedback 5:
Handling of TCP/UDP traffic using GRE encap is not acceptable. Here are some of the issues I can think of

  *   GRE encaped IOAM packets will traverse a different network path then the original packet
  *   Not all packets can be GRE encaped to avoid the previous problem, due to wastage of network bandwidth (typically sampled traffic is used for IOAM). What about native GRE traffic, will it get further encaped in another GRE tunnel and so forth.
  *   IP header protocol will point to GRE IP proto and IOAM ethertype (pending allocation by IEEE) need to be read from the GRE header to detect an IOAM packet. This means parsing performance penalty for all regular GRE (non IOAM) traffic.

Thanks,
-Jai