IETF Logo Mail Archive

Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

Tony Li <tony.li@tony.li> Fri, 17 June 2022 13:45 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 4D169C15AAF7; Fri, 17 Jun 2022 06:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.508
X-Spam-Level:
X-Spam-Status: No, score=-1.508 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.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vegwE32ofUa6; Fri, 17 Jun 2022 06:45:42 -0700 (PDT)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BB7C15AAE3; Fri, 17 Jun 2022 06:45:42 -0700 (PDT)
Received: by mail-pl1-x636.google.com with SMTP id d13so3901473plh.13; Fri, 17 Jun 2022 06:45:42 -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=WqvaAwyF2qgmTzhN+KMnuknuqNXjgx3R50W62PY5vwc=; b=ZVah/laYj+nD8c4Rj27Cp+MUWMqSr6FEpGE6XN/yLyAbOV0w6YayY26blbL8wDsu9p eVa2xNFo6qNZnGZIXuAu/bapAf1rb4WT6cHp7tH3ICy758kqSxUGcQW35TygyMYiS4Gm YuCSHKNGWjb9GOXeOGFy76LDDt/HHMJJgVZmDiu+73Wp+8Nd9n1xqQdvo7LtDCMNud9Y gv721tvMqSFSMjq9GKyHGZPguHN/SqTGcz2iV3AGuMzIIJjWFMHr+V0jdFVKZ7gtoXCg hRls8yHoCwVKqRjPYkparNMoIcVh6SNFKrXe4eqrEDWlrbtLDfuNRnZELyeb4QggzPym 3Yww==
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=WqvaAwyF2qgmTzhN+KMnuknuqNXjgx3R50W62PY5vwc=; b=j/sKB3IQEbh/2FYM6OiCg1j+FkFMMXwd5i6mfuiSAEQNtq6cmr34a0DYU3+AimikF6 yQiSNNPSNKNsoT71gIwIcITOvFN3UkGv7GIGp5/CTRZgTTXDjP10mG8ubB0zNRnoDhfG oW2u0LicI68WxI4xVH79UghL5f4HRVJk24fio2mFdptJCGptJHlZ8U+JMh89ZNhOaiFk SSKL61R0U7xcP0JUJryy2ytzcV7yi0OiPLl7LV/gAKEdkMnsocX9gqWY3lUIdO1ahgZu tPev2RZg3uTWKLmAB9qiE69ueFTEtE8M/BwD3HVWdEgkpyN3huYMPhUVuvR+0SDHmnUh sZ0g==
X-Gm-Message-State: AJIora9yGr/tPXUY/heZYb6axSl+JNMsUEIn5ALJ1jLv/x+3ca7CJNQV /5/bLMQop+mmj7i1pfdzGcM=
X-Google-Smtp-Source: AGRyM1uUCJGMHZPS+niOKcYZK7FvSFBe4Vhe89cOXCNoqZU74Vf5Jl+QoNjtssRtu44eYRREIw/8jw==
X-Received: by 2002:a17:90b:3909:b0:1e8:46ef:d64 with SMTP id ob9-20020a17090b390900b001e846ef0d64mr10701448pjb.90.1655473541595; Fri, 17 Jun 2022 06:45:41 -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 144-20020a621796000000b0051b693baadcsm3690188pfx.205.2022.06.17.06.45.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jun 2022 06:45:41 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <19982EDE-E56A-4EC3-9113-7CFED4012189@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A8D36FA0-BE68-4ACA-8505-BDDFB89D4AD2"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Fri, 17 Jun 2022 06:45:39 -0700
In-Reply-To: <CA+b+ER=A3R3s-=8gFZKNxs2oXkY52iy4EBFHZKzjxvnQ=buu6Q@mail.gmail.com>
Cc: "Zafar Ali (zali)" <zali@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
To: Robert Raszuk <rraszuk@gmail.com>
References: <6e5c6fa9-539f-80c3-7c92-5b97ad67560c@pi.nu> <447_1654704927_62A0CB1F_447_309_1_1f59cd955500419a988e2218a3f2246e@orange.com> <9F79E3D5-7ACE-4D15-83D7-8BF3FF60F671@gmail.com> <C9D1FD4A-2549-49C0-8904-84E3F559E85C@cisco.com> <988F5CAF-1A12-4209-92B5-B9AE75477B5C@tony.li> <4D3BA352-6E89-489D-A849-2B72A5D0DC1F@cisco.com> <1F0A4345-C258-4BE6-92D4-C846C0B77048@tony.li> <CA+b+ER=A3R3s-=8gFZKNxs2oXkY52iy4EBFHZKzjxvnQ=buu6Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/WTTVFzs7iOk1jE_fXfAEYVl3yxw>
Subject: Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 17 Jun 2022 13:45:43 -0000

Hi Robert,


> Can you please kindly explain why the proposed model is insufficient ? 8 bits of ELC seems more then enough to indicate presence of an ISD entry following EL entry. How you encode ISD itself is completely up to you. You could fill it up to the wire's MTU if deemed necessary. 


As I explained in my presentation in the last IETF, if you start expanding the ELI LSE’s, you run the risk of old implementations misinterpreting your ISD entries. It’s no longer backward compatible.


> I understand you are proposing to encode functions and actions immediately after the MNA indicator, but this is just a possibility - not sure WG agrees as the best one or clearly not a killer argument IMO. 


The alternatives are to shove it all to PSD or the control plane. Neither of those is compelling.


> Side note - IMHO pumping more bits into MPLS Label Stack is not a good thing. 


And adding complexity is not a good thing either, but people seem insistent.

Tony

v2.23.0 | Report a Bug | By Email