Re: [mpls] mpls open dt & the first nibble discussion

Vasilenko Eduard <vasilenko.eduard@huawei.com> Fri, 16 April 2021 12:36 UTC

Return-Path: <vasilenko.eduard@huawei.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 C11CD3A24B4 for <mpls@ietfa.amsl.com>; Fri, 16 Apr 2021 05:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MfeNtvrwqyiV for <mpls@ietfa.amsl.com>; Fri, 16 Apr 2021 05:36:04 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C5F3A245F for <mpls@ietf.org>; Fri, 16 Apr 2021 05:36:03 -0700 (PDT)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FMFt763sRz689qb; Fri, 16 Apr 2021 20:30:39 +0800 (CST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 16 Apr 2021 14:35:59 +0200
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 16 Apr 2021 15:35:59 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2106.013; Fri, 16 Apr 2021 15:35:59 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: "Fomin, Sergey (Nokia - US/Mountain View)" <sergey.fomin@nokia.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: mpls open dt & the first nibble discussion
Thread-Index: AdcyKOoHIJniKIfTSHaMs13RHJd6pQAkQeRA
Date: Fri, 16 Apr 2021 12:35:59 +0000
Message-ID: <157cfa3b102649eeac2cec69f6346d3e@huawei.com>
References: <BYAPR08MB549352C0F7E74A097378AED8854D9@BYAPR08MB5493.namprd08.prod.outlook.com>
In-Reply-To: <BYAPR08MB549352C0F7E74A097378AED8854D9@BYAPR08MB5493.namprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.205.190]
Content-Type: multipart/alternative; boundary="_000_157cfa3b102649eeac2cec69f6346d3ehuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/l1afiTWJHFRCBYCEqo8IVps3UqM>
Subject: Re: [mpls] mpls open dt & the first nibble discussion
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: Fri, 16 Apr 2021 12:36:14 -0000

Hi all,
Investigation for how legal is the requirement to have IP header just after MPLS stack
Is very interesting and important.
But even if it would be discovered that no one document gives the ground for such assumptions then what?
Almost all LSRs have a microcode that assumes this.
Insert arbitrary header in this pace and get packet reordering for traffic going through old LSRs?
IMHO: interoperability should be preserved.
Hence, whatever header would be defined after the label stack – it should start from something that would not create packet reordering.
Yesterday we have discussed getting from IANA codepoint (like “3“) – it is probably the best way because it would mean “MPLS metadata is here”.
But it did come to me now that it is not mandatory. “0” does mean “non-IP”. Old boxes would not try to search for IP header and load balance - it should be no reordering.
Whatever header we would insert – we would break load balancing effectiveness of old boxes– they would not find TCP anymore. They have to calculate hash only from labels.
Eduard
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Fomin, Sergey (Nokia - US/Mountain View)
Sent: Thursday, April 15, 2021 10:04 PM
To: mpls@ietf.org
Subject: [mpls] mpls open dt & the first nibble discussion

Hi,
this "first nibble" discussion took up a lot of time in today's meeting, but I'm not quite sold on the idea.
Perhaps I'm missing some context, but what exactly are we trying to achieve with it?

Let me share a few thoughts, starting with a relevant paragraph from Stewart’s draft-bryant-mpls-dev-primer/meeting agenda
>    Note that when we define new first nibbles we are technically taking
   IP versions away from the IETF Internet Area.  When PWE3 first
   proposed this we agreed with the IETF of the day that we would only
   take 0b0000 and 0b0001.  I am looking to see if this agreement was
   documented.
I don't think this is the case.

0x4 and 0x6 have meaning in the context of IP header.
After an MPLS header with BoS=1 we may encounter any type of payload (with currently dominant IP & Ethernet). And we all know that this the reason how we got into the whole ECMP/CW mess in the first place. And that the first nibble was never intended to be used as a protocol identifier from MPLS point of view, it’s just a byproduct of load-balancing needs.
Which leads me to a few points:

  1.  We are not 'taking' anything from IP folks as long as we are not claiming that an IP header follows (VTN folks do not make such claim, instead using their own VTN header; same as BIER-MPLS and bier header).
  2.  We already put all sorts of things into that first nibble (e.g. when encapsulating ethernet frames without CW).
  3.  We can't directly/solely use "first nibble" after as an analogue to ethertype or next protocol/next header/etc. Its meaning by itself is not defined; and I don’t think we should (or can, for that matter) change that logic.

--
Sergey