Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags
"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Fri, 02 August 2019 06:48 UTC
Return-Path: <fbrockne@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 A83A812008A; Thu, 1 Aug 2019 23:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=ODXC4kDa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Uw9LhnLJ
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 a861MbaW2oaH; Thu, 1 Aug 2019 23:48:02 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2550F120136; Thu, 1 Aug 2019 23:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16000; q=dns/txt; s=iport; t=1564728482; x=1565938082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dhwcdi5WrOW7tgcm4lQiUXLYu6Blb3DLSimFbyFvtNg=; b=ODXC4kDahhrzT8FCTvIa+fLWhGJnRKpAlQqYsOM349NfpX8t3TjkY+Z7 EiStI3WpWLkVXa5M57AyWL88XmZXr1Zoc3jdGJmhyk3lRTOj+67eQ5tDl HuolW3t/GChwrZyUo99TQDvfy7QDLGeF1NQWnVp2a4I7njhPsGU9+lHqD 4=;
IronPort-PHdr: 9a23:9kuBdRQPKpqgy8qqkgM8/4C6UNpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOiIwBsNJV1lo13q6KkNSXs35Yg6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AoAAD320Nd/4oNJK1cChoBAQEBAQIBAQEBBwIBAQEBgVYCAQEBAQsBgUQpJwNtVSAECyoKhBSDRwOLKIJbiVWOAoFCgRADVAkBAQEMAQEYCwoCAQGEQAIXgj4jNwYOAQMBAQQBAQIBBm2FHgyFSgEBAQECAQEBEAsGEQwBASwLAQsEAgEIEQQBAQECAh8HAgICHwYLFQgIAgQOBQgTB4MBgWoDDg8BAgyiQwKBOIhgcYEygnoBAQWBMgGDUw0LghMJgQwoAYYTgVmBKoJJF4FAP4ERRoJMPoIaRwEBgSkNBSiDCTKCJowgCBkegiiHMpQlQAkCghqGXIlKhBKCLocphBGKOYxiCYIMhiKBeItngjcCBAIEBQIOAQEFgWYigVhwFTuCbAmCOTdvAQGCSYJkgjCFP3KBKYohgTABgSABAQ
X-IronPort-AV: E=Sophos;i="5.64,337,1559520000"; d="scan'208";a="597478105"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Aug 2019 06:48:00 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x726lxFV030960 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Aug 2019 06:48:00 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 01:47:59 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 2 Aug 2019 02:47:58 -0400
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 2 Aug 2019 02:47:58 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z/U6q14NnwKFEsqypjfX2qa/ouqQEaR0JtM1LGFaOQic6W9AoZg3WASq1/bj/sa2copgi7ZGWjyO5/5D364eEWZvYiD1vx8TcH5cRbr2nTTEqmdT2QkEMQ2gg22UrKA+DmlBj8jR8GZWJauwJjdZvINSlNREBIPxJAkTaitf+uBZUKZc7S5dUEP1MhnKbQWItJg4OJHlidIhPWLLwwRptIB2ZBzWYT9ex7qNWIH2M9is9S5yvT/6G+OE9jB9Z+79FRpsXUdE/08Ckh80isLroOPim0/VnXN4IgZqSug3XSWo7yQ8iUOaADB15mL04k6LRLl/SdxvKBBM5SlvJ15VSA==
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=dhwcdi5WrOW7tgcm4lQiUXLYu6Blb3DLSimFbyFvtNg=; b=gu1V9pwCUpiZmny/HkP6tt0uO7LvJXNQd9LUosQxhgh4U/t/HE7hlsTFYGu1vaHn6vk7bJiPyMAOwzL+vM+3de7iYfQn0nLG4k+f7V20J8vTzi7alPblOkwNLa609czNu0ADmkXwGlnqn9ZXWhjbMHtlaZiShPWt2idMFti2w9mezgIftoBn4diS4lJNHuAaBZp3qz5D1G5VKEoCeLRR6dQh92mCJpcn37beh3hjIIYQMeg36ktWN1UbFdAMPUHpvnGIBbjKE8j7GdXq7oRZBrVpmn+vHxdYqnpkgHqKl7BWcWqkUq4/7XKKWfxoM3qERfuzAw4LJ65gcpK2w3M99w==
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=dhwcdi5WrOW7tgcm4lQiUXLYu6Blb3DLSimFbyFvtNg=; b=Uw9LhnLJWXBmHwPbC0cT5IaVE3mnZ0PR2gQIw6eW0/ZAfRFfrTVbpatsbsCKgF/ONnGsoAC/u9YzSkPXzeKK7GujjkMF+KJqZF5qeuiuu7TttS/tHmx2cmuympqkAyUL45q6j+lRgXLYdT/vMRrcUiLdILGts3+o9s4zStVtkF8=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.227.17) by BYAPR11MB2727.namprd11.prod.outlook.com (52.135.227.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Fri, 2 Aug 2019 06:47:57 +0000
Received: from BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d443:d196:b8f6:d858]) by BYAPR11MB2584.namprd11.prod.outlook.com ([fe80::d443:d196:b8f6:d858%7]) with mapi id 15.20.2094.017; Fri, 2 Aug 2019 06:47:57 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Tom Herbert <tom@quantonium.net>
CC: Greg Mirsky <gregimirsky@gmail.com>, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags
Thread-Index: AQHVQxPfcyCqkf67BUCt2X7oyo6/OKblHFwAgAA/ZQCAASInQIAAMOeAgAADY5CAADg8gIAAiZcA
Date: Fri, 02 Aug 2019 06:47:56 +0000
Message-ID: <BYAPR11MB2584978168353AC7C0D1493EDAD90@BYAPR11MB2584.namprd11.prod.outlook.com>
References: <CA+RyBmVnkMFEQv=Hr3y9OD09+_vocHRgnGQnLwEVO=yuTcptEQ@mail.gmail.com> <EAB5C70D-A160-423E-84FE-3CE7AC079168@trammell.ch> <CA+RyBmWxh+FRxnrFH9ZbQ_F0V42UTm8aE0yOpd2N7vXb-Eqaiw@mail.gmail.com> <CAPDqMeoS8ZatMF9SXNYi0bPDdRN7T0gj-snxrLNL+1arGv5RTw@mail.gmail.com> <BYAPR11MB258458D075E929C9C0CF4901DADE0@BYAPR11MB2584.namprd11.prod.outlook.com> <CA+RyBmXzZvi7GBC6OJ_+RcRFp_xQMmfnGAwhxUdh9YQ-4fBw3A@mail.gmail.com> <BYAPR11MB2584A68317656AB94D1EE2C1DADE0@BYAPR11MB2584.namprd11.prod.outlook.com> <CAPDqMeox8Q0Oqn-zqDVTLbAcyzpCKo+8FVXctCmNKUgsHXcg3w@mail.gmail.com>
In-Reply-To: <CAPDqMeox8Q0Oqn-zqDVTLbAcyzpCKo+8FVXctCmNKUgsHXcg3w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com;
x-originating-ip: [173.38.220.53]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d6a8b945-75f4-4f67-1eed-08d717155a3a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB2727;
x-ms-traffictypediagnostic: BYAPR11MB2727:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB2727831B4A0C4281060E9035DAD90@BYAPR11MB2727.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 011787B9DD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(376002)(346002)(199004)(189003)(51444003)(54094003)(13464003)(51914003)(81166006)(6246003)(8676002)(8936002)(81156014)(2906002)(14454004)(76116006)(66556008)(64756008)(66446008)(66946007)(74316002)(7736002)(30864003)(4326008)(68736007)(66476007)(305945005)(486006)(66066001)(476003)(5660300002)(446003)(11346002)(52536014)(25786009)(102836004)(6116002)(71200400001)(3846002)(478600001)(966005)(561944003)(71190400001)(33656002)(14444005)(99286004)(256004)(86362001)(26005)(6506007)(7696005)(76176011)(6436002)(53546011)(186003)(9686003)(6916009)(54906003)(316002)(6306002)(53936002)(229853002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2727; H:BYAPR11MB2584.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: ZormRAj9VVbbtca4GLIeY/svrwT/cX4olKSl48Jigq1DHFcwFwwQmokYOR3l5CdOwDTuqmT2uiMTtSKd/sMUCXiQPfIW0WhhPhNUBZI5qFt7P11WsVt9MPHIHyZVx5Wqat0OenJdnjTv625oY/zjVt0ZcOs8xCWgDUNJO1eKZ8bzlPQWCbiWWrkh5i2wip8aMIYaSGbw0/9D2NuViQdVTmxsoAnBfEc3YZqOzoPT1tWibwMjP+hEYaw7oUCZvtfnQ/hUoeH4JsZ+lgrBLIaxYKY0mXhvOAmVuUE7d6z/2yZcMPRTJFUN/TXEDF/feKokPyWMz/PfRLuPCJd8hGwOhqIiUf1ASUvByJbchR6C889k5UrLjbOqOWq0Tdh4G0hPhckGveHNi8ZpG/m5QPjTssHGF/a38Ja3Oqfm5mCe5lU=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d6a8b945-75f4-4f67-1eed-08d717155a3a
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2019 06:47:56.9676 (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: fbrockne@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2727
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/pqQC5JjiBuIK1nkMh9IAYBg27RQ>
Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags
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: Fri, 02 Aug 2019 06:48:06 -0000
> -----Original Message----- > From: Tom Herbert <tom@quantonium.net> > Sent: Freitag, 2. August 2019 00:27 > To: Frank Brockners (fbrockne) <fbrockne@cisco.com> > Cc: Greg Mirsky <gregimirsky@gmail.com>; IPPM Chairs <ippm- > chairs@ietf.org>; IETF IPPM WG <ippm@ietf.org> > Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: > Regarding draft-mizrahi-ippm-ioam-flags > > On Thu, Aug 1, 2019 at 12:12 PM Frank Brockners (fbrockne) > <fbrockne@cisco.com> wrote: > > > > Hi Greg, > > > > > > > > Please see inline… > > > > > > > > From: Greg Mirsky <gregimirsky@gmail.com> > > Sent: Donnerstag, 1. August 2019 20:54 > > To: Frank Brockners (fbrockne) <fbrockne@cisco.com> > > Cc: Tom Herbert <tom@quantonium.net>; IPPM Chairs > > <ippm-chairs@ietf.org>; IETF IPPM WG <ippm@ietf.org> > > Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags > > Re: Regarding draft-mizrahi-ippm-ioam-flags > > > > > > > > Hi Frank, > > > > thank you for your expedient response and the clarification, much > appreciated. I have some follow-up questions but your response, in my opinion, > supports my original evaluation of the draft that it is not ready for WG adoption. > I don't agree that the presumed benefits of the proposed Loopback flag > outweigh risks that were called out during the meeting and were pointed by Tom > and me. > > > > Also, thank you for informing everyone that a design team is forming to define > the use of the Immediate flag. I think that that flag should be introduced along > with the clear and firm specification of its utilization. > > > > And I'm still not clear about how the Active flag can be used. You suggest that > it is intended as complementary to "an operator who uses his own probing". > What such "own probing" could be? Why would the operator use well-known > standard-based active OAM for fault management and performance > monitoring? > > > > > > > > …FB: draft-lapukhov-dataplane-probe-01 is an example of an operator’s > approach to probing. I’ve also seen deployments where the probing is integrated > with the application – i.e. part of the application solution, which is another > example domain where specific health checks are used. > > > > > > > > And, going back to the scenario in DC. I wonder why the well-known > Traceroute is not sufficient? > > > > > > > > …FB: In the scenario discussed below, detection speed was the driving factor – > the IOAM loopback solution gives you an indication of the failed link in less than > 1 RTT. > > Frank, > > I'm doubtful it would be practical to set loopback on every packet given the > amplification characteristic, which means that either it's done as a periodic > probe or on demand when the application has reason to suspect a failing link. In > either case, it seems like the latency to detect and identify a failing link would be > greater than 1 RTT. Am I missing something? Tom, you would not set loopback on every packet. Let me re-explain the deployment scenario: * Operator runs a custom application UDP probe - which makes probe traffic follow all paths the application uses. * On detecting failure of a specific probe for a specific connection, IOAM tracing is turned on with loopback for *that* connection. * Once IOAM tracing is turned on, you can detect the node/link where traffic is stuck within one RTT. I.e. identification can be done in 1 RTT, once you detected the failure. So in other words, you only need the IOAM trace option with loopback added to a very small set of packets. In an ideal world even one packet would be sufficient. Frank > > Tom > > > > > > > > > Cheers, Frank > > > > > > > > Regards, > > > > Greg > > > > > > > > On Thu, Aug 1, 2019 at 12:32 PM Frank Brockners (fbrockne) > <fbrockne@cisco.com> wrote: > > > > > > Some additional notes on the different flags - restating and expanding the > discussion we had at the WG meeting in Montreal: > > > > Loopback flag: > > The loopback flag was inspired by a specific use case, which could be > summarized as "rapid identification of a failed link/node in a DC": In a DC (read: > controlled/specific domain), one runs UDP probes (draft-lapukhov-dataplane- > probe-01) over a v6 fabric. In case a UDP probe detects a failure, one adds the > IOAM trace option and enables loopback mode - i.e. every node sends a copy > back to the source in addition to forwarding the packet. Correlating the > information from both ends allows one to pinpoint the failed node/link rapidly > and gives one a view of the overall forwarding topology. This use-case was > implemented in FD.io/VPP roughly 2 years ago and was also showcased at IETF > bits-n-bites. There is a rough outline of the open source implementation > available here: https://jira.fd.io/browse/VPP-471 . > > In more generic words: Loopback mode is like all IOAM, a domain specific > feature. Loopback mode is to enrich an existing (here the dataplane-probe) > active OAM mechanism. > > Reading through the comments below, it proves that the current draft is > indeed a good basis for the discussion and it also clearly shows that we need to > add a section to the document that expands on how loopback mode is expected > to be used. > > > > Immediate export flag: > > Per the WG discussion in Montreal - and the follow up breakout meeting > (https://mailarchive.ietf.org/arch/msg/ippm/Do9kJ9ED_grmTqwcZHSdpy3CmRk > ): > > The plan is to consolidate the IOAM-related content for a new "immediate > export option" from draft-song-ippm-postcard-based-telemetry-04 and the > description of the immediate export flag in draft-mizrahi-ippm-ioam-flags into a > new draft. > > > > Active flag: > > The active flag is not to replace any existing active OAM mechanisms - but > rather allow an operator who uses his own probing along with IOAM to flag a > packet as a probe packet. > > > > Security considerations for flags in the context of PNF vs. VNF: > > Thanks for raising the point. It would be great to see specifics/details > discussed here on the list, so that those could be incorporated into the security > section. > > > > Thanks, Frank > > > > > -----Original Message----- > > > From: ippm <ippm-bounces@ietf.org> On Behalf Of Tom Herbert > > > Sent: Donnerstag, 1. August 2019 00:41 > > > To: Greg Mirsky <gregimirsky@gmail.com> > > > Cc: IPPM Chairs <ippm-chairs@ietf.org>; IETF IPPM WG <ippm@ietf.org> > > > Subject: Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: > > > Regarding draft-mizrahi-ippm-ioam-flags > > > > > > On Wed, Jul 31, 2019 at 11:53 AM Greg Mirsky <gregimirsky@gmail.com> > > > wrote: > > > > > > > > Dear Authors, > > > > thank you for bringing this proposal for the discussion. When > > > > considering WG > > > AP, I use the following criteria: > > > > > > > > is the document reasonably well-written; does it addresses a > > > > practical problem; is the proposed solution viable? > > > > > > > > On the first point, I commend you - the draft is easy to read. > > > > On the second point, I have several questions: > > > > > > > > What is the benefit of using Loopback flag in the Trace mode? > > > > > > This is unclear to me also. Additionally, I am concerned that > > > protocol blindly reflects the packet back to the source without any > > > regard to what else the packet contains. For instance, if a TCP > > > packet is reflected by ten intermediate nodes this is nonsensical. > > > The possibility of an amplification attack is obvious and in fact > > > mentioned in the security section, however I'm skeptical that the proposed > mitigation of rate limiting is sufficient. > > > > > > Minimally, it seems like the reflected packets should be wrapped in > > > ICMP to mitigate spoofing attacks. Also, I wonder if traceroute > > > methodology could be used for tracing, i.e. one sent packet results > > > in at most one return packet (ICMP), to mitigate the amplification problem. > > > > > > Tom > > > > > > > Why is it important to limit the applicability of Loopback to only Trace > mode? > > > > What is the benefit of collecting the same, as I understand the > > > > description, > > > data on the return path to the source? > > > > What is the benefit of using Active flag comparing to existing > > > > active OAM > > > protocols? > > > > What is the benefit of using Immediate flag comparing to > > > > Postcard-Based > > > Telemetry (PBT) proposal? > > > > > > > > On the third point, I'd appreciate your clarification on these points: > > > > > > > > In which transports (I find that iOAM encapsulation has been > > > > proposed for all > > > known transports) you've envisioned to use Loopback flag? > > > > The third bullet in Section 5 refers to a replica of the data > > > > packet that follows > > > the same path as the original packet. What controls that replication? > > > > The last paragraph in the Security Consideration section relies on > > > > "restricted > > > administrative domain" to mitigate the threat of malicious attacks > > > using a combination of iOAM extensions. That might be the case when > > > operating in a PNF environment, but it is much more challenging to > > > maintain such a trusted domain in VNF environment. How can these new > > > security risks be mitigated in a VNF environment? > > > > > > > > Appreciate your consideration and clarifications to my questions. > > > > > > > > Regards, > > > > Greg > > > > > > > > On Thu, Jul 25, 2019 at 2:07 PM Brian Trammell (IETF) > > > > <ietf@trammell.ch> > > > wrote: > > > >> > > > >> hi Greg, > > > >> > > > >> Thanks for the feedback; absolutely, we can do this the normal way. > Authors: > > > let's do a normal two-week adoption call for this document before > > > publishing the update. > > > >> > > > >> This adoption call starts now. > > > >> > > > >> IPPM, please respond to this message with an indication to the > > > >> mailing list of > > > your support for adopting draft-mizrahi-ippm-ioam-flags as a working > > > group document, in partial fulfillment of our charter milestone > > > "submit a Standards Track draft on inband OAM based measurement > methodologies to the IESG" > > > (obviously, depending on how many documents we end up sending to the > > > IESG, we may have to change the plurality of this milestone). If you > > > do not support this, please send a message to the list explaining why. > > > >> > > > >> Thanks, cheers, > > > >> > > > >> Brian (as IPPM co-chair) > > > >> > > > >> > > > >> > On 25 Jul 2019, at 13:15, Greg Mirsky <gregimirsky@gmail.com> wrote: > > > >> > > > > >> > Dear Chairs, et al., > > > >> > I appreciate that editors of draft-ietf-ippm-ioam-data followed > > > >> > on the > > > decision of the WG reached at the meeting in Prague to extract > > > material not directly related to the definition of iOAM data > > > elements from the document. The new draft was presented earlier this > > > week and generated many comments. I feel that it would be right to > > > discuss the draft and its relevance to the charter of the IPPM WG before > starting WG adoption poll. > > > >> > > > > >> > Regards, > > > >> > Greg > > > >> > > > > _______________________________________________ > > > > 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
- [ippm] Regarding draft-mizrahi-ippm-ioam-flags Greg Mirsky
- [ippm] Adoption call for draft-mizrahi-ippm-ioam-… Brian Trammell (IETF)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Frank Brockners (fbrockne)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Jai Kumar
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Tommy Pauly
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Barak Gafni
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Jai Kumar
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… John Lemon
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Carlos Pignataro (cpignata)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Tianran Zhou
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Parviz Yegani
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Giuseppe Fioccola
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Greg Mirsky
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Tom Herbert
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Frank Brockners (fbrockne)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Greg Mirsky
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Frank Brockners (fbrockne)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Tom Herbert
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Frank Brockners (fbrockne)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Tom Herbert
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Greg Mirsky
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Frank Brockners (fbrockne)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Frank Brockners (fbrockne)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Mickey Spiegel
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Tom Herbert
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Shwetha Bhandari (shwethab)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Rakesh Gandhi (rgandhi)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Vengada Prasad Govindan (venggovi)
- Re: [ippm] Adoption call for draft-mizrahi-ippm-i… Tommy Pauly