[mpls] Re: Poll: IOAM and PSD

Greg Mirsky <gregimirsky@gmail.com> Fri, 09 August 2024 00:03 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F63C14F6F3 for <mpls@ietfa.amsl.com>; Thu, 8 Aug 2024 17:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69KoTHziEw-L for <mpls@ietfa.amsl.com>; Thu, 8 Aug 2024 17:03:28 -0700 (PDT)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF665C14F6E3 for <mpls@ietf.org>; Thu, 8 Aug 2024 17:03:28 -0700 (PDT)
Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-e0e76380433so1329044276.2 for <mpls@ietf.org>; Thu, 08 Aug 2024 17:03:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723161807; x=1723766607; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hmBFkbxLr4wElLk0APqSWoGNzFZRf2JPUMuAcn72X4A=; b=BgL5itmpj8oiG+lAwzfkMXTPjl541iF/hFkTINwj3IHCwEf+jf4F9WSI5/ACKGIKF4 stXlPis1Te6UIsl5xPjVSeWcHGV5/BcxFqv3+8NXBVA1CA66fNiHR9cIXS3h3SM35gGH GZ/uxBT+YjlwGCfGpSLRNUcNagofNsIC6Hwlqd+kFdo2RY3v5vVzgkFqHvYuU7l47ZyU IcA4VhgpojLSmCLRPq6XW/Fw8eHOzYHCW3E1gvPr7daWmdDv+bK5oplPrRDol9rpiOFP a0SvjX4iJXzi4e50jIi/wVQfxNHRv58AUb64m68EeAw4ypeK7telaENmlaGydoP2C0B5 0wlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723161807; x=1723766607; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hmBFkbxLr4wElLk0APqSWoGNzFZRf2JPUMuAcn72X4A=; b=dsh44XOIgmZAUDyaSmHscuaAHHdfLZ3AhucUjF2iIQi5PWigezSOA1YUBcG8RDyn5m 1CHQ4hFmv2WwQD+ln+GWYTypcrIcErmRgqH5ea83UJifjxQynksxH0QM5l6w4s88m9lK NAebZMWqwUbumGL95fZ/ae3BFIrwOdcgOkmBfjEh6fxL7IZj0tKkTqKXkQoZtIvXsvo0 ySHmrLRsUcsx79IiXy1KrhvFmhACrWctv0tIR/U7mvim5fkYy5XiPFlGiWpNgdbgmZGO OKXdZpCPbpRwpmq2Is0IOYTlnVlnPQ/PpfYKcRB6GsZXPisKkRwmqZ5AXcAAimed25/8 LcZQ==
X-Forwarded-Encrypted: i=1; AJvYcCWMbpGeoTAAX7grOhLaurccLxdMIAO6M5fvWNQPQ0M2H3hJDRm1Q97SJPX8TDn/97wbwxAI041lUwf+Kgc3
X-Gm-Message-State: AOJu0YzCnCzftJh2L/C3rUgMZgmSoX8MQBaqMUbQ1d+rYmUJZ5ojt8jP TGmytlz+WO+abX3TtKh7erKjuNPCoci45OFplPF6qFs5KdGRgjSzft9YuGrvvJCtYvlZthOWd6H WCpVKfNn+Ht/Vda1+w4Yz9m8C24BNwA==
X-Google-Smtp-Source: AGHT+IFRbqnazOnLvUKaRAyrvfmzH4jyahO29v+Z+4kkWKX+6YXzrlB6wcL6uwNCnOmeauNQWofiUG6lRz6oTaul6VA=
X-Received: by 2002:a05:6902:1584:b0:e0b:eb79:d49 with SMTP id 3f1490d57ef6-e0e9daaf150mr4060761276.18.1723161807394; Thu, 08 Aug 2024 17:03:27 -0700 (PDT)
MIME-Version: 1.0
References: <F78CB19B-2880-48AB-99CE-D46280014A87@tony.li> <BY3PR13MB4787298A531DFA3812CAAB9F9AB92@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB4787298A531DFA3812CAAB9F9AB92@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 08 Aug 2024 17:03:16 -0700
Message-ID: <CA+RyBmVaWJiv4UqSK2DRBRbnQOwKHf+SQFOFvf338P2F6OuWEw@mail.gmail.com>
To: Haoyu Song <haoyu.song@futurewei.com>
Content-Type: multipart/alternative; boundary="0000000000006ba10b061f34dffc"
Message-ID-Hash: R64OLRQWCSZUUDI53HWQQBZ6HHQ4DRXR
X-Message-ID-Hash: R64OLRQWCSZUUDI53HWQQBZ6HHQ4DRXR
X-MailFrom: gregimirsky@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: mpls <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [mpls] Re: Poll: IOAM and PSD
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/YoS7xa0GzeCtNG2II8jfsemShkw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Hi Haoyu,
could you help me understanding how you envision using IOAM across several
domains. As I understand RFC 9197, IOAM domain follows the definition of a
limited domain (RFC 8799) and the decapsulating IOAM node is in the same
administrative domain as the corresponding encapsulating IOAM node. AFAICS,
RFC 9197 precludes scenario where IOAM encapsulating packet crosses from
one administrative domain into another. Am I missing something?

Regards,
Greg

On Thu, Aug 8, 2024 at 4:35 PM Haoyu Song <haoyu.song@futurewei.com> wrote:

> Hi Tony,
>
>
>
> My response is inline.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* Tony Li <tony1athome@gmail.com> *On Behalf Of *Tony Li
> *Sent:* Tuesday, July 30, 2024 8:26 AM
> *To:* mpls <mpls@ietf.org>
> *Subject:* [mpls] Poll: IOAM and PSD
>
>
>
> [WG chair hat: on]
>
>
>
> Hi all,
>
>
>
> We’ve had many discussions about IOAM and PSD over the last few years. We
> need to reach consensus on the problems that need to be addressed in these
> areas. Therefore, we would like to hear from everyone, especially
> independent operators:
>
>
>
>    1. There are many flavors of IOAM.  Which ones would you like to
>    deploy/implement with MNA?
>
>
>
> [HS] I’d like MNA to support IOAM DEX and Trace option as specified in
> RFC9326 and RFC9197 using PSD. The reasons are:
>
>    1. Comply with existing standards, can be directly used without any
>       hassle
>       2. Support potential cross-domain interoperation (e.g., cross the
>       boundary of MPLS domain and non-MPLS domain)
>       3. IOAM trace (i.e., the passport mode) is very useful in many
>       realtime measurement/congestion control applications (e.g., HPCC and tons
>       of published research papers), therefore it has great potential for future
>       wider application.
>
>
>
>    2. Do you have other applications of MNA that have not been proposed
>    yet?
>
>
>
> [HS] I’d like to see a simple flag-based action to support the postcard
> mode telemetry.
>
> I’d like also see the support of application level ID and metadata to
> better support the application-aware networking.
>
>
>
>  This poll will close in two weeks, at 9am PDT, Aug 13.
>
>
>
> Regards,
>
> MPLS chairs
>
>
>
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org
>