Re: [mpls] Concerns about ISD

Tony Li <tony.li@tony.li> Tue, 12 April 2022 05:56 UTC

Return-Path: <tony1athome@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 DE1EF3A0820 for <mpls@ietfa.amsl.com>; Mon, 11 Apr 2022 22:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.512
X-Spam-Level:
X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 T71pimqjVJMs for <mpls@ietfa.amsl.com>; Mon, 11 Apr 2022 22:55:59 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 507823A0854 for <mpls@ietf.org>; Mon, 11 Apr 2022 22:55:59 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id mm4-20020a17090b358400b001cb93d8b137so1652231pjb.2 for <mpls@ietf.org>; Mon, 11 Apr 2022 22:55:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=k+j8KlzvM1kly7+nhcMROOB3nGvE7UUmlG6Hi/Wjjs8=; b=h1GD8GN/5k41/slwBQcBvEv1TA3zCUZL3DKlyw+GvKUNf50hzCC3/99WOMdjOXrkE6 hzeHUCKYbIS+y/z2SoceQYW73UHdv24eABY5/CtV405O/ULnEvovWg3U/JeajDG/C6kE R2O+OtIQAe/kEg78/gagOvyDLTJWq0vvurr0OuhbL+gvbQdDpDrVnlHiEH9D8oheeVy7 AuTyIb7qfyXHBcTYyCXeelEVjuyDYseM1YP1xqYr3pbHQNZF0VxFXH7EwHDxtVBOHmrf wnAnD4dC7ASsAvIkc9GC0FI8LNLhVe8BgyExAyRJE7+KnzN+L7a7Gt0DbyDqLffIOyON 8GCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=k+j8KlzvM1kly7+nhcMROOB3nGvE7UUmlG6Hi/Wjjs8=; b=2EYIVr0bLgczhc3o1Jqc/gUrOyHjS/dU6zGPK9tIPLZZvUBSCiwLQMktiwt7Nd3Hpc Ln75Z1QqgUwQFyQx6hb/kqI81eYyI4jEiEZIJnLYM/LclRHTmXbx77TQUTPCSwmVxfzJ i+duLqaQwsYFsDAKKV11orcbN+eGa09nz+n85Rj87tScvZmI8SOsxuOavFEew+jFH69e wKWu5CRGIBpXJK/HKAV1oQvVfjtliKPa+9xMvQHW4MAgaaF3qS4xKc+gcD4VBYRzXYj/ f4MiHShVWf64UdiE9OXt+VGWr6toJyXJLttHied6DYBMsWjFPam6rk1LuPO9Qfj6azmP y8eQ==
X-Gm-Message-State: AOAM530wGCTXOgOTfhpSFCMXBYeJ26aRgHNnstg4qHAITDRKWV55ENFP 50zhbVYSkh1ejlWJ92wLYmY=
X-Google-Smtp-Source: ABdhPJyItsLDRp6DL9tPa4b6ngz8ch4dXrFQfDJE4c4hOgOiLf2/u5RAQdv0t5nRgmIt7gitUupaTw==
X-Received: by 2002:a17:90a:ab08:b0:1cd:34ec:c731 with SMTP id m8-20020a17090aab0800b001cd34ecc731mr168924pjq.202.1649742958153; Mon, 11 Apr 2022 22:55:58 -0700 (PDT)
Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id mq6-20020a17090b380600b001c6357f146csm1544251pjb.12.2022.04.11.22.55.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Apr 2022 22:55:57 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <8F23F80A-A8A3-4A09-8538-EF744CC1FEDC@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB015AD0-477F-47FD-84C4-5C43518ED9B3"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Mon, 11 Apr 2022 22:55:57 -0700
In-Reply-To: <CA+RyBmVVROUDLx0eco=L4r0x_GC3St8tbVmzXxFYW-q0JgLr5w@mail.gmail.com>
Cc: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
To: Greg Mirsky <gregimirsky@gmail.com>
References: <6cc272447d2f4c779e85d5c42d3b3c6c@huawei.com> <8623637D-A32E-47A4-B5FC-4D2CF40BEDD1@tony.li> <6199e0e886f9437c95ef9b70719b00ec@huawei.com> <BCFD3F4A-36D6-47C2-B907-FC40B402F97C@tony.li> <3fb1f261ddff48deb0c2ea083cdbd16f@huawei.com> <6B96F21B-9331-4FA8-AD7B-84A4CA8B6FAB@tony.li> <903c57a48280454091495673ec2fe275@huawei.com> <BD5C1BE7-4633-4B51-BAC1-B2AE1C537F36@tony.li> <ad6b8c42b0aa4880b9dee02516f5e46f@huawei.com> <CA+RyBmVVROUDLx0eco=L4r0x_GC3St8tbVmzXxFYW-q0JgLr5w@mail.gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/EnF0k-3OxxqYSDI05ZlrnWGeqeo>
Subject: Re: [mpls] Concerns about ISD
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2022 05:56:04 -0000

Greg,

Thank you. Well said.

Tony


> On Apr 11, 2022, at 7:47 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> thank you for a lively and helpful discussion. I believe it is good to lay our assumptions on the table, check what is real and what is not so much.
> To me, both ISD and PSD are essential elements of MNA. I expect that there will be lots of considerations, discussions and arguments around where a particular MNA will have its associated data - ISD or PSD. And, as the case with ELI/EL, there will come necessary extensions to routing protocols and corresponding YANG data models. In my view, the new MPLS data plane must be accompanied with extensions in the control and management plane. 
> To summarize my position, it seems that constrains of available today HW must be considered but should not prevent us from defining a more powerful, flexible new MPLS architecture. As our common experience has demonstrated again and again - HW advances faster than we can standardize protocols. I view architectural optional capabilities as an opportunity to realize a new functionality, for example on-path telemetry like IOAM, but only when when that does not affect the main goal of the network - efficiently forward data flows. that seems as an obvious, and I believe that the MNA framework and requirements documents express it clearly. We only need to follow them.