Re: [ippm] Adoption call for draft-mizrahi-ippm-ioam-flags Re: Regarding draft-mizrahi-ippm-ioam-flags

"Frank Brockners (fbrockne)" <fbrockne@cisco.com> Mon, 05 August 2019 07:17 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 7EFA3120157; Mon, 5 Aug 2019 00:17:17 -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=kMRhB2uC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AkB4U3d9
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 eGP5QjdKEptk; Mon, 5 Aug 2019 00:17:14 -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 1F9C612002F; Mon, 5 Aug 2019 00:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49150; q=dns/txt; s=iport; t=1564989434; x=1566199034; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4hsIhuv5Qy429WW3nDGEwD3XTcyTNp5rkWvkf2/4YPA=; b=kMRhB2uC9qujWJV99VEWM6zr2tTUWUfEH8DiCMoFlGyYp8M5eSGMQyyX GI48qKhi1GDYaBjw2Hkl7aRo7FCwCRni4FudLmDoUfDxfo1O1HUsOshfL eYNvgT4/ZL3ZYQl31PoTUOShZDyKuXGxNklpiqs6MfQBBq7lO3EWbfQ0+ Y=;
IronPort-PHdr: 9a23:OrjrJhLBfwTw0x5M8NmcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUgMdz8AfngguGsmAXEPxNvnhbCo3NM9DT1RiuXq8NBsdFQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AdAAA410dd/49dJa1cChkBAQEBAQEBAQEBAQEHAQEBAQEBgVYBAQEBAQELAYEVLyknA21VIAQLKgqEFINHA4srgluJV44CgUKBEANQBAkBAQEMAQEYAQoKAgEBhD8CF4JOIzcGDgEDAQEEAQECAQZthR4MhUoBAQEBAgEBARAIAwYKEwEBLAsBCwQCAQgRBAEBASABAgQDAgICHwYLFAkIAgQOBQgTB4MBgR1NAw4PAQIMoAACgTiIYHGBMoJ6AQEFgTMBg1INC4ITCYE0AYYTgVqBLIJJF4FAP4ERRoJMPoIaRwEBgSkNBSgrCQiCTTKCJowhCBkegimFBIIulClACQKCG4ZciUuEEoIvhyyEEoo8jGYJggyGJIF4i2iCOAIEAgQFAg4BAQWBZiKBWHAVO4JsCYI5DBcUbwEBgkmCZIIwhT9ygSmKQoEwAYEgAQE
X-IronPort-AV: E=Sophos;i="5.64,349,1559520000"; d="scan'208,217";a="611419974"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2019 07:17:12 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x757HCHI028423 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2019 07:17:12 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 02:17:11 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 02:17:10 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 02:17:10 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IjusSWjngeZeLyAlzRI0uXBOfvoCGwWnxLH9FidHzJon6pfUSCexJjQGkv2PTIhtj3zQzJUbcr+SuKX+erqG4FBS0hxyXpyykgG+funP05i/oqIzpaABEeKBiEF5HtigAPy8mzH2HEzAK59TaKaLYvHWbUAaOH9lafToFQ9CAzcuNMaAdmvzgQirq+/CKsZT+8UFKoWPjFZ5q25bLxEpJz/aP/FYAlFgUjK5C1pEuEe7MGUDDkmCEwcMiw4/z5tzKuh30lF9H0Rfr3J2kYGar70IbFTRjrT4KoAd3haO8wn5xHQbv30PzgKS4EAab4RrLGGBXlJjSEhX6WBXquag0w==
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=4hsIhuv5Qy429WW3nDGEwD3XTcyTNp5rkWvkf2/4YPA=; b=AOU+6km3+GVObMCufRD/EQ0856qcI1IuCXVmbTm5jUS9Qe081OgbWow2noRL16nNVRYEPHkmmdwjgfZqWcWW1ONG3ajvp9ZkWDbSM9FQSWLl+UdgCl8YMtTe6BMwUiowTsdkCusvx5DaVjWYg8vQNF6h3GdqOSLV5QOkNaKuEh0OR2jbxJIywGe5cRf/k0Z/QatsdOvyMZcTEzfTqXhWbE+jlmgdAHtBVWOqzH9gaBn/hpljT1qtQeOrEvDkDBCvI2QRSm7Wx6WvNw75hddTMsrEUpElvouWAh9rShqbFuzrOpybd+UM2MPmvZ8/ZbyAoKQTVjOM2086v1pbV7bDBQ==
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=4hsIhuv5Qy429WW3nDGEwD3XTcyTNp5rkWvkf2/4YPA=; b=AkB4U3d9JvyfsJJ4St47Jxf5oZb5UBVf0irLZVJXR5AzvlQy/KRLAoUbr1I8Lxvc3rnLEKZRjZkVLtTfbQ0zB/fJRHqwS6UlIjRxrWjwsljRlYYw1HC7hBMlqEEp/CZdao8mlzZlIOZhu9qEmocThcj51KvitCFE+GJdWVyvT5s=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.227.17) by BYAPR11MB2614.namprd11.prod.outlook.com (52.135.227.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.15; Mon, 5 Aug 2019 07:17:08 +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; Mon, 5 Aug 2019 07:17:08 +0000
From: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Tom Herbert <tom@quantonium.net>, 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/ZQCAASInQIAAMOeAgAADY5CAADg8gIAAiZcAgAKr4oCAAhLhsA==
Date: Mon, 05 Aug 2019 07:17:08 +0000
Message-ID: <BYAPR11MB2584910F5158BA66D4EA03F2DADA0@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> <BYAPR11MB2584978168353AC7C0D1493EDAD90@BYAPR11MB2584.namprd11.prod.outlook.com> <CA+RyBmWJ56FfrshsoqfpeGQ7zjZFK-oVU4iJjGbG4YsL68u-AQ@mail.gmail.com>
In-Reply-To: <CA+RyBmWJ56FfrshsoqfpeGQ7zjZFK-oVU4iJjGbG4YsL68u-AQ@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.54]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 55015fe8-3e01-4eaf-91c8-08d71974ed98
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2614;
x-ms-traffictypediagnostic: BYAPR11MB2614:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <BYAPR11MB261442B644BDF715847CF70FDADA0@BYAPR11MB2614.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01208B1E18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(199004)(51444003)(54094003)(189003)(51914003)(13464003)(9686003)(68736007)(6306002)(54896002)(236005)(53936002)(446003)(11346002)(99286004)(6436002)(186003)(4326008)(55016002)(25786009)(486006)(476003)(54906003)(316002)(52536014)(7696005)(102836004)(5660300002)(66066001)(1411001)(71190400001)(71200400001)(14444005)(256004)(30864003)(6916009)(606006)(86362001)(478600001)(26005)(14454004)(74316002)(66446008)(76176011)(9326002)(966005)(2906002)(6116002)(229853002)(64756008)(3846002)(66946007)(66476007)(66556008)(790700001)(76116006)(8936002)(6246003)(561944003)(33656002)(53546011)(6506007)(7736002)(81156014)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2614; 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: K8BsWEhDEIsSHQpXHdonOb7gg/3de0f7o459EhkUTunKXMmWUdYU1qWDjUqO6arbdBs4D/yfzsCTFc+c2Iw7EjRJN+VJt7+biL60GIb1LBmDG9wSYZUy7zsG6vCkTQk1sJQp0nNaLTvudst7sEN7IqHcRPef5ygY2EWntnHHCsiN9t51RH9Ha0znNBOcEjCC1W2n+JlXnFLztwhP/TKHYflAbb6MvW2Cj7RdvFZWZgkEwy9wEwR0HaFapYdEVNaWBhmg9CE+V1IUhIqw1GLb4JPCcnhSquNsExmXhXD+fiJS9ZkK2lkO3CJseuhATnlfxFfhBz0jUR4DzvXtzx7hhehECtgY92/Qij0zYbDtiu61jTwgSFhHmVZUYcZwTkgDg/NziJ+s47Wo7GJlD4xhQ7rhbbncmCPhHWDpBKQmcS4=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB2584910F5158BA66D4EA03F2DADA0BYAPR11MB2584namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 55015fe8-3e01-4eaf-91c8-08d71974ed98
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 07:17:08.7545 (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: BYAPR11MB2614
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/_-MaAwBL22Ltv_UqByeX5FUjVv4>
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: Mon, 05 Aug 2019 07:17:17 -0000

Hi Greg,

Sorry – looks like I created a bit of confusion with the example around using IOAM loopback to help isolate an issue rapidly. This was just *one* deployment example for IOAM loopback. The IOAM loopback flag is a tool that you can use for several things. An encapsulating node can use it to assess and retrieve the characteristics of a path a certain set of packets take, you can use it to identify issues in the network performance degradations, including potential faults. This is much like e.g. TWAMP – some people use it to assess the performance of a connection, others use it to just detect network or service failures. As such, IMHO IOAM loopback is as much in scope or out of scope for IPPM as TWAMP was.

Cheers, Frank

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Sonntag, 4. August 2019 01:28
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 the very detailed description of the use case for the Loopback flag. I think it would be helpful to add some text that explains the use case in the draft. But from your explanation, I cannot find how the Loopback flag can be used in any performance measurement method. What I gather is that the Loopback is used to localize a fault detected by another Fault Management OAM tool. If my understanding is correct, the Loopback may be useful as part of FM OAM. But Fault Management OAM is not part of the IPPM WG charter. It could be I've missed something and please correct me if I did, but I don't see that the Loopback flag and the use case it addresses, i.e., fault localization, is in the scope of this WG.

Regards,
Greg

On Thu, Aug 1, 2019 at 11:48 PM Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com>> wrote:


> -----Original Message-----
> From: Tom Herbert <tom@quantonium.net<mailto:tom@quantonium.net>>
> Sent: Freitag, 2. August 2019 00:27
> To: Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com>>
> Cc: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; IPPM Chairs <ippm-
> chairs@ietf.org<mailto:chairs@ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto: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<mailto:fbrockne@cisco.com>> wrote:
> >
> > Hi Greg,
> >
> >
> >
> > Please see inline…
> >
> >
> >
> > From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
> > Sent: Donnerstag, 1. August 2019 20:54
> > To: Frank Brockners (fbrockne) <fbrockne@cisco.com<mailto:fbrockne@cisco.com>>
> > Cc: Tom Herbert <tom@quantonium.net<mailto:tom@quantonium.net>>; IPPM Chairs
> > <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto: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<mailto: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<mailto:ippm-bounces@ietf.org>> On Behalf Of Tom Herbert
> > > Sent: Donnerstag, 1. August 2019 00:41
> > > To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
> > > Cc: IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>; IETF IPPM WG <ippm@ietf.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:ippm@ietf.org>
> > > > https://www.ietf.org/mailman/listinfo/ippm
> > >
> > > _______________________________________________
> > > ippm mailing list
> > > ippm@ietf.org<mailto:ippm@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/ippm