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 06:51 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 7A9F6120134; Sun, 4 Aug 2019 23:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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=ddPd9IER; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DrCCzzRQ
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 CHMkCEJwvQN1; Sun, 4 Aug 2019 23:51:08 -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 98F2512004D; Sun, 4 Aug 2019 23:51:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24108; q=dns/txt; s=iport; t=1564987868; x=1566197468; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bLvqwUQNUEDWBF65Ayzcs0f3sFG05xSgbCpPMEzVxO8=; b=ddPd9IERI0dGMfWs3AYkxFD4muuygTGKmqeX7Fa9SRKvTE5TY1dbs1n0 VFY8KJQkaI/ZycijWrN6eqGiS19zp2JYWG5xJHzoSQ2B3YF1VCbF7Kxcf 15QDxFCz401z793usTq8nobPSycHk9xK4B8UQIT19auZxNHPgmXK9OxM/ Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3ALL6HuxKkKAL1Gbz0O9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEPxNvnhbCo3NM9DT1RiuXq8NBsdFQ=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AABY0Udd/40NJK1cChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWeBRSknA21VIAQLKgqEFINHA4srgluJV44CgUKBEAN?= =?us-ascii?q?UCQEBAQwBARgLCgIBAYQ/AheCTiM4EwEDAQEEAQECAQZthR4MhUoBAQEBAgE?= =?us-ascii?q?BARALBhEMAQEsCwELBAIBCBEEAQEBAgIRDgcCAgIfBgsVCAgCBA4FCBMHgwG?= =?us-ascii?q?BagMODwECDJ93AoE4iGBxgTKCegEBBYEzAYNQDQuCEwmBDCiGFIFagSyCSRe?= =?us-ascii?q?BQD+BEUaBTn4+ghpHAQGBHA0NBAEoPYJMMoImjA8SCBkegimHMoYIjiFACQK?= =?us-ascii?q?CG4ZciUuEEoIvhyyEEoo8jGYJggyGJIF4i2iCOAIEAgQFAg4BAQWBZyGBWHA?= =?us-ascii?q?VO4JsCYI5N28BAYJJgmSCMIU/coEpikEBJYELAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.64,348,1559520000"; d="scan'208";a="611408365"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Aug 2019 06:51:07 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x756p6MV015030 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Aug 2019 06:51:07 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 01:51:06 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 5 Aug 2019 02:51:05 -0400
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 5 Aug 2019 01:51:04 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ccKbicVtfTEXGkJDUAkI2smu/NpZZgkLBm9yr/TUCdFU2ISLZomRD87B+U4Z4GdJvA9h65RAaXoC0v+i2Q00hWL/5EEWh8VTHhyzjasn66ryFr0dMq0ODB465CVFdwWfys0QJALXB7fd1+yueeLnXqGXssEwTQA739WmHM+/aFVpPbga8Qrf8ySxs+5Hs8UYSpGyJ1GDhT8BLwsyyM79uJNzGEezo6UweAlNMxo1bNMqNI2b7U6aGAY/7ZDigBOhIcYcYaZXyZU3t41Muj7VvubpOtzpR4GkH8qQg2fb/lwx/GVwEZyuSUerMLBsp5Rtwbo6vtbWLr7DJzVCGOUsIg==
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=bLvqwUQNUEDWBF65Ayzcs0f3sFG05xSgbCpPMEzVxO8=; b=Ut3dbFtS98xK8G2obwqPz7v0wgriMlZqlwGVN2ANgKtLAgySMVZq/fPiYgwSoBOqXeSE79bkka97p8WX8VWL7Thx8KbykIgBPmcKNYz/GVk7DtwjXtOeYbCGOLxXoqEVBZz7N/8yA7C9MSItKlOIyIpTVOrvZHB1fnTozNl1ldoIxsiNP7Z+T5Ek7G6y/LHhj9oc1Y/uhS1Af3pa5O0yOeUgSQ4G9QS8qBNduYJh65rAdtfkuedza8aiCs8EsPj3yG8cvv3gUfHfBnoUVtgeNHiWjlJUkkFz4kdzSFOpAJqJcObKYDLqv/VjUVKSWoRus24AoKr7ZuQdkUXJ4HH72Q==
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=bLvqwUQNUEDWBF65Ayzcs0f3sFG05xSgbCpPMEzVxO8=; b=DrCCzzRQ46K3EDYtmgXD84un88GMR0yuGXN7HhgGvZToCPDloW95ippPyTkCJuUID3Pyx3VFYErH13urNYYxb2LRmbU75qyGUAHOSyUQX36IdTHA+olBvszvdIZAPlLDjRlDQ0EW1ZJZEYKfS7f+TctB//G6IQ23furdsj+7/YM=
Received: from BYAPR11MB2584.namprd11.prod.outlook.com (52.135.227.17) by BYAPR11MB2901.namprd11.prod.outlook.com (20.177.225.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Mon, 5 Aug 2019 06:51:03 +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 06:51:03 +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/ZQCAASInQIAAMOeAgAADY5CAADg8gIAAiZcAgACaxACABBjlUA==
Date: Mon, 5 Aug 2019 06:51:03 +0000
Message-ID: <BYAPR11MB258416FFB5C93FF4C21685F3DADA0@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> <CAPDqMepi=ZoBj8LBc+yrVV7jhddwFKY6RmcKecQJGe1yKx_A-Q@mail.gmail.com>
In-Reply-To: <CAPDqMepi=ZoBj8LBc+yrVV7jhddwFKY6RmcKecQJGe1yKx_A-Q@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: 46892121-7fbe-45da-2d7d-08d719714898
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR11MB2901;
x-ms-traffictypediagnostic: BYAPR11MB2901:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <BYAPR11MB29018957195A062C1EAC26BBDADA0@BYAPR11MB2901.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01208B1E18
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(366004)(136003)(39860400002)(51914003)(54094003)(51444003)(13464003)(189003)(199004)(33656002)(54906003)(8676002)(71190400001)(52536014)(30864003)(71200400001)(8936002)(68736007)(81166006)(6916009)(86362001)(53936002)(9686003)(316002)(81156014)(4326008)(446003)(561944003)(25786009)(11346002)(26005)(76176011)(53946003)(6246003)(966005)(53546011)(102836004)(186003)(3846002)(99286004)(7696005)(6506007)(66066001)(256004)(5024004)(14444005)(486006)(6116002)(5660300002)(14454004)(66476007)(66556008)(64756008)(66446008)(478600001)(76116006)(6306002)(229853002)(74316002)(55016002)(2906002)(305945005)(476003)(6436002)(66946007)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2901; H:BYAPR11MB2584.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: rfUE9VILJSYlrSIBnF+Z0jpywymB4HJ6/sAZZ8P/VGHb8VsP98fPTcu648SMM3S8WZPD0PuYL/B62kkhawOsdrsXJm0VO0gyne/o6NghDbkKwrY2+o28LQ9JiAlkp4gVdw/JE1LbMXA16rbzspotEGofSKkYrULEP6OvU/Cqbfe7nsP13LmvQQ4CaSMTOEUo3wD9LZLoHAsWFZx9xFeUnjunCE631n+hynPUpE/WGoH7+aZn2AyES57eYlZ3NfxRU2n9HnYZYeM8zBz1LLA0rZs+4NpAfTY8Zs1EoAgPiBhc0hwJOuhlUdGKDcaqazAIRo0Pe+NSEL0yPl0gWKiX7uDJhNZTT4YN+U8/vZq9e6QazmIxffW5Sr8z+Wxr9l06iS3GQRWZxcNDx41SSK9mbnB205IzDNp2IlYJ0ADJsv0=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 46892121-7fbe-45da-2d7d-08d719714898
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 06:51:03.1928 (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: BYAPR11MB2901
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/u7u38QIrPWEENSvnp3yNKJAwtzw>
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 06:51:12 -0000


> -----Original Message-----
> From: Tom Herbert <tom@quantonium.net>
> Sent: Freitag, 2. August 2019 17:54
> To: Frank Brockners (fbrockne) <fbrockne@cisco.com>
> Cc: Greg Mirsky <gregimirsky@gmail.com>om>; IPPM Chairs <ippm-
> chairs@ietf.org>gt;; 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 11:48 PM Frank Brockners (fbrockne)
> <fbrockne@cisco.com> wrote:
> >
> >
> >
> > > -----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>om>; IPPM Chairs <ippm-
> > > chairs@ietf.org>gt;; 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>et>; IPPM Chairs
> > > > <ippm-chairs@ietf.org>rg>; 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.
> 
> Frank,
> 
> If the operator is tunneling everything IOAM could be probably attached to
> every packet and active probing my not be needed. i.e. the peer tunnel endpoint
> could reflect the forward path IOAM information on packets in the reverse path
> of the tunnel. This motivates an "endpoint reflect flag" that I mentioned
> previously.

...FB: Agreed. In case of normal operation, a "reflect flag" could be used to constantly measure "to" and "back" path and have all that information available to the encapsulating node. 

> 
> > * On detecting failure of a specific probe for a specific connection, IOAM
> tracing is turned on with loopback for *that* connection.
> 
> I assume by connection you mean path in this context.

... FB: In a proper setup, there would be a probe connection for every single path - so yes. 
 
> 
> How is failure of a specific path determined? If just one probe is is lost that be
> could the result of a transient condition like congestion. It seems like multiple
> probes need to fail before link failure should be suspected. So the time to detect
> a failed path might be the period of sending a probe plus some time to observe
> the failure of multiple probes. This might be several RTTs.

... FB: Failure detection is somewhat orthogonal to the discussion here. I just used the use-case with application probing and subsequent IOAM attached to the probe as an example use-case how IOAM loopback can be used. Even for that use-case you could go with the assumption that you have an issue and are trying to better understand the situation. For that the loopback flag can help you.

> 
> > * 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.
> >
> These probes might also be dropped due to transient conditions, so once a
> candidate link is determined it might make sense to probe some more to verify.
> 
> > 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.
> >
> But we don't live in an ideal world and "small set of packets" may be relative :-).
> Consider a provider that has N possible paths that applications follow and M
> intermediate nodes in each path. Now suppose that there is common link in all
> paths that fails and that each prober in step one of your algorithm detects the
> failed link. So the loopback probes generate a flood of O(N*M) packets in the
> network. In a large scale deployment N*M could be a large number to the
> extent that the probes themselves create congestion in the network. There are
> some classic examples similar to this where synchronized UDP probes have
> resulted in bricking an application. The answer to this problem is avoid
> synchronizing probes, but that probably means longer periods to send the probe.

...FB: The whole point of the example use-case was to explain how application level probing, combined with IOAM can help you detect and isolate an issue rapidly. Like with any method, you have to understand the side-effects - which you point out. I.e. an operator needs to make sure that probes are not synchronized; scaling limit / max. number of packets have to be taken into account etc. - which IMHO is perfectly ok, given that such a tool would only be used in a controlled domain.


> 
> In any case, my point is that the whole time from when a link fails to when a
> endpoint node is able to identify the failed link needs to be taken into account
> when comparing loopback method and traceroute. A single loopback or
> traceroute probe is just one component of the algorithm above, so the net
> speedup we get from loopback may be limited per Amdahl's law. It might be help
> to have some more specifics on the link failure detection algorithm including
> some estimates about the time required for the whole process and how multiple
> probers avoid creating problems like congestion.

...FB: It wasn't really the intention to develop a new generic fault detection and fault isolation mechanism here. It is more the other way around. For certain scenarios, IOAM loopback can be a tool which helps speed up localizing a failure -  especially when comparing to traceroute. You can use IOAM loopback for other purposes, like assessing the performance of a path at regular intervals from an encapsulating node's point of view. 

Thanks, Frank

> 
> Thanks,
> Tom
> 
> > 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_grmTqwcZHSdpy3C
> > > mRk
> > > ):
> > > > 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>rg>; 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