IETF Logo Mail Archive

Re: [ippm] Lars Eggert's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

Lars Eggert <lars@eggert.org> Mon, 12 April 2021 17:38 UTC

Return-Path: <lars@eggert.org>
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 7B8703A1027; Mon, 12 Apr 2021 10:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 GYqKlADn-tOJ; Mon, 12 Apr 2021 10:38:40 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840513A0EC4; Mon, 12 Apr 2021 10:38:33 -0700 (PDT)
Received: from [IPv6:2a00:ac00:4000:400:8430:ee31:d2a:d1fd] (unknown [IPv6:2a00:ac00:4000:400:8430:ee31:d2a:d1fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 52B5160032E; Mon, 12 Apr 2021 20:38:26 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1618249106; bh=n6DurymPeSt5sZFk50Zn9ua5AzaK01KR13Ff+DiivOg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Icm+JDlVoIw0N0QFkXh/vL4UIx4zNdrWetC7Dlp8C+1P6xTBtq/SdVeQViGSCa4nW 4EsjujAqWmGIpufTALokcQ0Ph+apDJN31WKMGPlbT7mwB5aBoBWG4cUDZY/+14tbWo QOLZLJhOCwxYovzlhhixw22Ltu/z5RivLUQn1JoM=
From: Lars Eggert <lars@eggert.org>
Message-Id: <30029000-BD9A-40B9-B1E9-7F88B108F187@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_6B569076-8C55-4F43-BB07-A77C0CA2532A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Mon, 12 Apr 2021 20:38:25 +0300
In-Reply-To: <BYAPR11MB2584B4F0CF9DF43370D103D0DA709@BYAPR11MB2584.namprd11.prod.outlook.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-ippm-ioam-data@ietf.org" <draft-ietf-ippm-ioam-data@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, Al Morton <acm@research.att.com>
To: "Frank Brockners (fbrockne)" <fbrockne@cisco.com>
References: <161667538893.15241.7322339760692550091@ietfa.amsl.com> <BYAPR11MB258481FC2FB8EC909D59969EDA719@BYAPR11MB2584.namprd11.prod.outlook.com> <3D4CC7F2-66F5-4EE3-AFC0-315BD2C7E0D2@eggert.org> <BYAPR11MB2584B4F0CF9DF43370D103D0DA709@BYAPR11MB2584.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
X-MailScanner-ID: 52B5160032E.AFCC8
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/A8QQ8GzSA_WQQm4mHJ-t_nJYpbU>
Subject: Re: [ippm] Lars Eggert's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
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, 12 Apr 2021 17:38:51 -0000

Hi,

On 2021-4-12, at 19:58, Frank Brockners (fbrockne) <fbrockne@cisco.com> wrote:
> ... FB: Perhaps a picture can help - see attached. The example shows a 5 node setup:

<snip>

thanks, that example was VERY helpful. Stressing in the document that because encap and decap nodes MUST be able to support both option types, it is sufficient if transit nodes only support one such type, assuming that the controller/collector can integrate both sets of data, would address my DISCUSS.

> ...FB: Agree that we'd need to add a statement that encap/decap nodes SHOULD be able to insert/remove both trace Option-Types, because on encap/decap the effort between forwarders is comparable.
> Per my note above, there is no need for the decap node to do any type of consolidation. It would just strip the different option types, and there could be additional ones, like POT or E2E Option-Types and ship the information to some controller/management station for further processing.

Right - the controller would be the entity to do the integration.

(Remainder of the email was about comments, which are not blocking and your resolutions seem fine.)

Thanks,
Lars

v2.23.0 | Report a Bug | By Email