Re: [OPSAWG] [Lsr] I,Scope of FIT Capability: a node or a link?

Jeff Tantsura <jefftant.ietf@gmail.com> Sun, 05 April 2020 23:46 UTC

Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572E73A08C6; Sun, 5 Apr 2020 16:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.com
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 AaVhzzH5Ekdd; Sun, 5 Apr 2020 16:46:32 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 A66563A08C7; Sun, 5 Apr 2020 16:46:32 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id q3so6649368pff.13; Sun, 05 Apr 2020 16:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=U2zDSv7Kzwyi2WWmVof1zRnyJM6YU4TN4epi8DBwe8w=; b=IKibZOZIAQkgeBKrgEGxE9PXVs9cHPBeSV1ROH/QHyDqihbN/HSgutkpXNlPi1mYsf 5p5dghqeNyKHCIkv1uCQvMlog0dNvW1Ng1v5vh+dvfztu1pt7mB8rQN1rnbJ+QUcwoKe p3uCDalaJJDRfGMkwdobhGjsony8sCOQ16kzkJwl2Bw+fBQNHzrBovWbb7NBgixHOmtp ZFVWaqEnyMF9CuAuGJ4ZB+P4XS3NRTC5asjMF3Wft51851oo+B2rZ1DR0f+clii3u8IW 8YryNi9vSC8BwnxbjK219txbUYStHYd+/5jesCX2Tv86ghidNf70nKg0H3HoxIi2GmeT 7yew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=U2zDSv7Kzwyi2WWmVof1zRnyJM6YU4TN4epi8DBwe8w=; b=qNzUJ9LWGR0CyN0/V2C63Aru8XbkJLPNzR+QWmFKy1X1YJv8mYsYq5BGhT3EAXODUN h1b/0iXDM1xnOj1qcSTtrEkwZajZnfjr7EGC84BluyMD7T2rast/niyjzCUHREXLclFF P/xYB3SZwXjCdkYX6DZBzAEk+i8BNZaVMYv4zn383Og6/ZU0SApA2pQzrRJVEEoaInnl NVnDgbtyaOuoQkHpNPctppJ1OGkk1awmdJZp8LOTVnKBJ1+7WQ/GNDaq/2HG85vT3+NH H6l1AFNfm/qjeRhcwitxOzyhDjSO0DfqXFG7xCqYnkoNJwTN0NDStViuwf7c2owybGpo EuOQ==
X-Gm-Message-State: AGi0PuaqxYQ06enxuQe/bWrSvyMC0UvceUJL+fitZkXCbC6M+tSpL1XC 6ytXkSi3PCQMsex/VZeuY7I05DKf
X-Google-Smtp-Source: APiQypKvKBjIA5GgQA+BbwYZgp71iMfW3gtsQtaQO9eNPi/Wb4rtbb8RWYkcPutco3/dvJjHiYpGoA==
X-Received: by 2002:aa7:9471:: with SMTP id t17mr18680638pfq.272.1586130391516; Sun, 05 Apr 2020 16:46:31 -0700 (PDT)
Received: from [192.168.1.2] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id 144sm9473508pgd.29.2020.04.05.16.46.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Apr 2020 16:46:30 -0700 (PDT)
Date: Sun, 05 Apr 2020 16:46:24 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: draft-wang-lsr-ifit-node-capability-advertisement@ietf.org, lsr@ietf.org, draft-song-opsawg-ifit-framework@ietf.org, opsawg@ietf.org, Greg Mirsky <gregimirsky@gmail.com>
Message-ID: <a0270dae-e4ab-48d0-8acf-a7e4c0d1b710@Spark>
In-Reply-To: <CA+RyBmXe4BrzvcZ4V_R0KtCOwKgCFMrKEmfA3OQVQdms-mjsGg@mail.gmail.com>
References: <CA+RyBmXe4BrzvcZ4V_R0KtCOwKgCFMrKEmfA3OQVQdms-mjsGg@mail.gmail.com>
X-Readdle-Message-ID: a0270dae-e4ab-48d0-8acf-a7e4c0d1b710@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5e8a6dd5_f641ca2_16f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/v5xTKxz2FdYTysEh6hZeY3BMjoc>
Subject: Re: [OPSAWG] [Lsr] I,Scope of FIT Capability: a node or a link?
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Apr 2020 23:46:36 -0000

Very valid comment - When working on MSD - we had exactly same considerations, since path computation could use different links over different line cards that may have different capabilities, hence we decided to have per link granularity, details in RFC 8491

Cheers,
Jeff
On Apr 4, 2020, 7:33 PM -0700, Greg Mirsky <gregimirsky@gmail.com>, wrote:
> Dear All,
> I've read these two drafts with interest.. In light of the discussion on the LSR WG list, I've been thinking about the scenarios where IFIT is being used.
> draft-song-opsawg-ifit-framework defines the overall IFIT architecture that, as I understand it, applicable to different methods of collecting and transporting telemetry information. draft-wang-lsr-ifit-node-capability-advertisement is based on the view that IFIT is a node-wide capability advertised as a binary flag for each listed method of collecting telemetry information (Option-Type enabled Flag). On-path telemetry collection is performed in the fast path, i.e., at a link layer. But a node might include ports with different capabilities. How such a heterogeneous, IFIT-wise, node will advertise IFIT Capability? To better use available resources for telemetry information collection, it might be helpful to advertise IFIT as a capability of a link, not of a node?
> What do you think?
>
> Regards,
> Greg
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr