Re: [spring] ***CAUTION_Invalid_Signature*** Re: Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)

<Ruediger.Geib@telekom.de> Fri, 15 December 2017 07:20 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B791127867; Thu, 14 Dec 2017 23:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level:
X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de header.b=T9Gu7sw5; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=DuvtouL6
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 RSIZCZbA3aIJ; Thu, 14 Dec 2017 23:19:59 -0800 (PST)
Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36088126FB3; Thu, 14 Dec 2017 23:19:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1513322398; x=1544858398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WvZU34JoQeB91+6Rfsj92hR5C2B1hFdFQRd0756zyxE=; b=T9Gu7sw5Vrcsvu+dIyOHLFFiFlsSIC8mEunKZ6bcjMUh6Bk5jn6I91m/ aonWcaKiJY9TyGkMIx6lrSr0B+X6szOUNmfpGSnnM74t8FBa5Vuha7E9C DfCwHGLoBEyx3ChMAubH0lnu9HamFdgsbPKxITjCLpCFN/Tu9KBw+nU3y pxprYsaTVdVD8j/6QWDJYg3qUcs1wIIhIwC3twpzdFByb+jkvzHFpPeX8 VSwas1gCT3MAa8U0KVpYGIX7d5pOPGfrkcEpdP0SVTTWKuakPR7kltBTh pm0ZnQYezsTguc5BX5FyxbooKMwWGX6QyWhEV5MvhDwlj20vSoaPA83DO A==;
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 08:19:56 +0100
X-IronPort-AV: E=Sophos;i="5.45,403,1508796000"; d="scan'208,217";a="134307220"
Received: from he105878.emea1.cds.t-internal.com ([10.169.118.32]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 15 Dec 2017 08:19:56 +0100
Received: from HE105716.EMEA1.cds.t-internal.com (10.169.118.52) by HE105878.emea1.cds.t-internal.com (10.169.118.32) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Dec 2017 08:19:55 +0100
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE105716.EMEA1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 15 Dec 2017 08:19:55 +0100
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.15) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 15 Dec 2017 08:19:42 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WvZU34JoQeB91+6Rfsj92hR5C2B1hFdFQRd0756zyxE=; b=DuvtouL6gs2scv7teaPjFnWggwn7NR1kbCACCMUCOVwUdUxs6f5e1qDnMwA91KQnptXavXKYmy3HzGHpX2LXHbUpUbAB42UtBt7XkuAaixYDgcp0F2JS75T8MF4LMeeYd4ng0DOFz5/nAb4fznqtW5RCbttsk2KBwYWycu2Dz/E=
Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.139) by LEXPR01MB0095.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Fri, 15 Dec 2017 07:19:54 +0000
Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd79:9e12:5cb0:ec5a]) by LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::bd79:9e12:5cb0:ec5a%14]) with mapi id 15.20.0302.017; Fri, 15 Dec 2017 07:19:54 +0000
From: Ruediger.Geib@telekom.de
To: ben@nostrum.com
CC: spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, bruno.decraene@orange.com, iesg@ietf.org, draft-ietf-spring-oam-usecase@ietf.org
Thread-Topic: ***CAUTION_Invalid_Signature*** Re: [spring] Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)
Thread-Index: AQHTdI4AfmP+sZBYwkWn0bm6cJYEAqNC5gPwgACY6gCAAHsJYA==
Date: Fri, 15 Dec 2017 07:19:54 +0000
Message-ID: <LEXPR01MB00946F71B29C7E4EF45E43EB9C0B0@LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE>
References: <151322313115.6120.8756591218425505436.idtracker@ietfa.amsl.com> <LEXPR01MB0094B84B0C104FFE8219C9839C0A0@LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE> <CCE7B795-D86A-4D76-A4A1-186EC1A8A86A@nostrum.com>
In-Reply-To: <CCE7B795-D86A-4D76-A4A1-186EC1A8A86A@nostrum.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.3.185]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; LEXPR01MB0095; 6:iova2HOUKUCO6dJWws1HemhsnS8kJwImtAwj/eyvyaGXqGr/lLxg24yz0tgXl5n5m0WGMNB+XZcNyHkEybOGYG+SH3Sx1fNSufZtMad0eGzmC9HqxxZiJ0KuJPWxvJZptutZarogGT1u0QO00udO951tDiGsRQBBRHoNiMHRwXo86uk2Fgn5XzhlQb93eVOblycW+Suf7XNhUufPFGTtp3oKN+7UtbCPFVR/VYLq/6ie2kxO4isPu/oMP5fsnnD6HFlMsgd1sIn85ViZlqKLTb13/mt5NXow2Az1YrKcSxH5orC75j+JvsKC5cukHeozmBMz02GW/07B5Iq4LlMu2xUQVb04pJsZF/SiAgeYuVY=; 5:LloDGJoT2GE4DI7rbNx46mCjtLfR6c1+vtFy1xVdS/2ceB9h1lrL1KJ642yUJR2Dv9xgBAsTU+YCGlX/3WKgAKoiAXVxgVrc8akuEdeYLMZ2yzGsTxSe7fcvtmjlBwJwE+cxN+/jpXRsylXq18guX7Ifp1V5zAE0Ew21flC+p+c=; 24:qxMuKsrMp2xyTTwUgxpb3jTQhutrcSirl2/D59eVgDJVJbaglaP5cBywoTRbP8jHf01kqCjC8ZxKvTtcdDItQNAFafvVC5XNXFW2ZelRGTE=; 7:w8ijAjI7haoV6lJ1jkC0QPqgRYKJo2RtiuWPmLdV5enlF8v0x1TDg2At42wR71vQluXO05QVL3cOcT/5OtiAB+Pm1FQ2osvXdzTXnqfvCc2N96yKbGdRI9R64ODuO/DpHDbE61aOjrN8v0zsyojMoXotJQiqFSjW2Z8B43/oMhgUukXUKvY48QUTtUF6JdjW6n4pEOM3hLW3jtwrL08nKpNX1gYUXzedF0xyUJ2to/1Xzc9Osazz0fDyg2V0C9hB
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3e156c6f-ad37-4695-f2ac-08d5438c3d4b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:LEXPR01MB0095;
x-ms-traffictypediagnostic: LEXPR01MB0095:
x-microsoft-antispam-prvs: <LEXPR01MB00952F67E4E63056CC0673EF9C0B0@LEXPR01MB0095.DEUPRD01.PROD.OUTLOOK.DE>
x-exchange-antispam-report-test: UriScan:(72170088055959)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231023)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(6072148)(201708071742011); SRVR:LEXPR01MB0095; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:LEXPR01MB0095;
x-forefront-prvs: 05220145DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(39860400002)(199004)(40764003)(189003)(75402003)(33656002)(85202003)(106356001)(2950100002)(6916009)(105586002)(55016002)(74482002)(4326008)(39060400002)(2906002)(3280700002)(3660700001)(230783001)(6306002)(54896002)(9686003)(53936002)(316002)(5660300001)(8676002)(81166006)(81156014)(54906003)(7736002)(72206003)(76176011)(85182001)(102836003)(66066001)(3846002)(8936002)(6116002)(478600001)(790700001)(59450400001)(7696005)(52396003)(97736004)(68736007)(2900100001)(86362001)(5250100002)(14454004)(777600001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0095; H:LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_LEXPR01MB00946F71B29C7E4EF45E43EB9C0B0LEXPR01MB0094DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3e156c6f-ad37-4695-f2ac-08d5438c3d4b
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2017 07:19:54.5038 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0095
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/j78zMhNhg3sbCeaODHLjVLuOST4>
Subject: Re: [spring] ***CAUTION_Invalid_Signature*** Re: Ben Campbell's No Objection on draft-ietf-spring-oam-usecase-09: (with COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Dec 2017 07:20:03 -0000

Hi Ben,

thanks for your help. I repeat sections with agreed text following your suggestions below. I’d like to start with your question related to the content:

> -- [BC 1]  10, last paragraph: I don't understand the intent of this paragraph.
>
>   [RG 1]
>
>   OLD:    A PMS may operate routine measurements.  If these are automated, care
>   must be taken to avoid unintended traffic insertion.  On the other
>   hand, large scale operation based on operator configuration itself is
>   a source of unintended misconfigurations and should be avoided.
>
>   NEW: A PMS may be configured to permanently surveil a set of LSPs. Changes of the Segment Routing topology may occur at any time. The PMS design must stop a permanent LSP measurement, as soon as it detects that its locally stored SR domain topology information related to an LSP to be monitored is stale.

[BC 2]  Sorry, I’m still not following it. Is the point that a PMS may continuously monitor a set of LSPs, but it needs to stop doing that for a particular LSP if that LSP changes?

[RG 2] Yes, that’s the point. There are global segments and these should be stable. An LSP then may be broken, if a router is completely disconnected and a measurement packet might be dropped, which is a valid result. However a node may also assign local segments and their values might be dynamic. Reading these labels from a PMS likely requires access to the router management plane. That is feasible and that’s what our (LDP label) PMS implementation does. If the value of these labels changes after a router re-start, a PMS not adapting its topology database may misinsert packets at that router. This must be avoided, I think. Guts feeling tells me, the danger is biggest with automated measurement set up. The good case of a measurement set up with a stable label base is easier to implement than detection of topology change events, evaluation of that change, adaptation of measurements (stop, wait for topology recovery, repeat measurement set up, log event…).

Would a longer explanation help?

Regards, Ruediger



NEW: The document describes both use cases and a standalone monitoring framework. The monitoring system re-uses existing IETF OAM protocols and leverage Segment Routing (Source Routing) to allow a single device to both sends and receives its own probing packets. As a consequence, there are no new interoperability considerations. Standard Track is not required and Informational status _is_ appropriate.

NEW: _While_ a single PMS can detect the complete MPLS control- and data plane topology _, a_ reliable deployment requires two separated PMS. Scalable permanent surveillance of a set of LSPs could require deployment of several PMS. The PMS may be a router, …..