Re: [mpls] Concerns about ISD

Robert Raszuk <rraszuk@gmail.com> Wed, 13 April 2022 20:31 UTC

Return-Path: <rraszuk@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 C589C3A1605 for <mpls@ietfa.amsl.com>; Wed, 13 Apr 2022 13:31:39 -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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYtSB9JeXwZp for <mpls@ietfa.amsl.com>; Wed, 13 Apr 2022 13:31:36 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 B6B7B3A1604 for <mpls@ietf.org>; Wed, 13 Apr 2022 13:31:36 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id z15so2205089qtj.13 for <mpls@ietf.org>; Wed, 13 Apr 2022 13:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g9Qbaz7Le4NPPofMnbH+qww8C8mfMMd6Ya3Sq3p2WDk=; b=k38648aWfUgTVF02ecOcvNCuejJ10T7dQwJcgCJ7PzoSnOpqLWf5/pN9u2bCsIGCt+ mT6EokK81idkG4MtENAc2ri45ctutAuuuSKJnQ4ptm0HM4HtuH8msU8Aruxq2yVF0tbX Hgd+sbypGoCmHhG2HbdZb+81lANf/5xVLSHS14QliejExAXMUDL//VyHXFtul6sirGcg /2OkwbQlJtvFKOEawi7FT/IPEHCt/8vJUjS8oVR9MBU1PfnThF/Mb6pCEH4bQc01Hprw Appw2sD1+dd1/ZC3kbSS0PRkpR+EOO6tEv4ZUs5W2gyuBThMwcaUXEwU8yKf8Ole/3Dr QcgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g9Qbaz7Le4NPPofMnbH+qww8C8mfMMd6Ya3Sq3p2WDk=; b=pqMOZOGbxjxuATySGE6AdSV9dL5U5qJq5kIH8eEjzaIIXYcQ6ntJW/KAmsUOpeFxeK 1F3dFk0ukhO5f1y7gGrjQrmejYdKD0ucOCUQxjnkP3SAXaGOxJDhtSF9vUaon+7R5mYa UBgCg/ogUVnPzQdplq/7axZH39+/2Q+2fLMPKneUyB6n9vBNR1DmM+haRqJkWul6Jc00 PTXGUGSLDy07yBiY2Bjy3Y2NWyPQUGGgs0xKPRR6AVcmxm4OvDIL7KAH1qZ6IXvFWdgl JIoUmK1q+UZU3dRSwwqnqKahydljHZgVa1ZXtas3v8AlHm28ZEnFo/kAI3MTi7jFIVno JK3A==
X-Gm-Message-State: AOAM530w9RuqHNIQBnpM6C+iM1O3ocMcLRv0bHUA+Rf4AynJ2BM9bLFk vyCX6ieEIN3wmaFGiZWBof63oOLIn+OyGgLoC1M=
X-Google-Smtp-Source: ABdhPJzaCv75jjbFQtpTNWiXLCXYERATBBGqjbGEklCNU5EUfH92S3APUjitVruFA6a6fdjvuZ+Zesn1FHUmW4WAXU4=
X-Received: by 2002:ac8:728d:0:b0:2eb:d3c3:7915 with SMTP id v13-20020ac8728d000000b002ebd3c37915mr8897671qto.645.1649881895475; Wed, 13 Apr 2022 13:31:35 -0700 (PDT)
MIME-Version: 1.0
References: <BY3PR13MB4787BFC0BE610AEDEC0925919AED9@BY3PR13MB4787.namprd13.prod.outlook.com> <60FA12CB-9955-4A19-97AC-917FD9AC1D64@gmail.com> <BY3PR13MB47874837B2BC69992E5103839AEC9@BY3PR13MB4787.namprd13.prod.outlook.com> <BY3PR05MB8081FA851029B917B5626EBDC7EC9@BY3PR05MB8081.namprd05.prod.outlook.com> <BY3PR13MB47878C6DDF33073B5B783B119AEC9@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB47878C6DDF33073B5B783B119AEC9@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Wed, 13 Apr 2022 22:32:43 +0200
Message-ID: <CA+b+ERkVb87kJpJAq=7QMsOSwihRsTE8-m9fxbd-OHOafbAVMw@mail.gmail.com>
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: John E Drake <jdrake@juniper.net>, Kireeti Kompella <kireeti.kompella@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004d1d5305dc8f1084"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/UB8XbPmo13fKghfQwggWowgCBEc>
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: Wed, 13 Apr 2022 20:31:40 -0000

Hi Haoyu,

> *[HS] It’s not about easy or hard to implement, it’s about the tradeoff
> between performance, cost, flexibility, and extensibility. Unlike the
> control plane protocols, the design will run in high performance device
> data plane, so every clock tick counts. In this regard, “Easy” or “Hard”
> can be and should be evaluated based on a set of solid qualitative and
> quantitative criteria when we compare different schemes.  We should choose
> the best design to the best of our knowledge.  *
>

I believe this is very well said indeed.

What is apparently being worked on here for months is in my view merely a
CPR for MPLS.

Instead IMO (and that is why I brought up the control plane assisted model)
MPLS could way exceed capabilities of SR NP without any excessive load on
packets or major surgery to MPLS architecture by encoding reference to
forwarding behaviour itself instead of just a pile atomic "actions"
(irrespective if those are stuffed into ISD or PSD).

So yes - no draft no proposal - I get this. I will write one. When I get to
it.

Kind regards,
Robert.