Re: [mpls] Concerns about ISD

"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 20 April 2022 09:59 UTC

Return-Path: <jie.dong@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 4E8D13A0C0D for <mpls@ietfa.amsl.com>; Wed, 20 Apr 2022 02:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 JLG7JZGFlGUd for <mpls@ietfa.amsl.com>; Wed, 20 Apr 2022 02:59:50 -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 5378A3A0C51 for <mpls@ietf.org>; Wed, 20 Apr 2022 02:59:50 -0700 (PDT)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Kjx106sVMz67NKF; Wed, 20 Apr 2022 17:57:24 +0800 (CST)
Received: from kwepemi100016.china.huawei.com (7.221.188.123) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 20 Apr 2022 11:59:46 +0200
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by kwepemi100016.china.huawei.com (7.221.188.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 20 Apr 2022 17:59:45 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2375.024; Wed, 20 Apr 2022 17:59:45 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Robert Raszuk <rraszuk@gmail.com>
CC: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Thread-Topic: [mpls] Concerns about ISD
Thread-Index: AdhKc4fdvDv9lzMNTfy5c++8iNI9i///poSA//7GfeCAAt4vgP/7wPiAgAhY2QD//2GkAAAn72wA//7TxPD//eE1gP/7NOOg//aGzID/67yBQP/XK+UA/6x794D/V7AIAP6vG0OA/V4yzID6vGKOAPV4wUgA6vF9xYDV4vMTgKvF3LWA14uv0wCvFxZWAN4uHVMAvFgOF4D4sBPvAPFgDAwA4sATwoDFf73RAIr/MYiAlf4v3oCr/AnWANf4D1uAr+//U4Df38PAgL+/hVsA/38JLoD+/NKzoP36HgaA+/OZ3DA=
Date: Wed, 20 Apr 2022 09:59:45 +0000
Message-ID: <193cc34dd5ec43de858c4cbfd8134cd1@huawei.com>
References: <1B54CB37-7C2F-438B-AB9C-03C1B3A644A1@tony.li> <CA+b+ERk8NJrj0eV63-ppEEj3KVYEuptJdXg6e2WEoRCj4ROdbQ@mail.gmail.com> <0de2adb00c17405cbaccf065cf3bc1e2@huawei.com> <CA+b+ERnxEBkxCtuBe_kQ80uboCpzeOsTXhW9TnkYTFsSuOD2RA@mail.gmail.com>
In-Reply-To: <CA+b+ERnxEBkxCtuBe_kQ80uboCpzeOsTXhW9TnkYTFsSuOD2RA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: multipart/alternative; boundary="_000_193cc34dd5ec43de858c4cbfd8134cd1huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Hv1or843Lxun4jIzDKegzh07DDU>
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, 20 Apr 2022 09:59:56 -0000

Hi Robert,

Agreed, and this applies not only the ELI, but any label which are not the at the top of stack. As specified in section 3.9 of RFC 3031, the classic MPLS forwarding operation is based on the top label only:

   Although, as we shall see, MPLS supports a hierarchy, the processing
   of a labeled packet is completely independent of the level of
   hierarchy.  The processing is always based on the top label, without
   regard for the possibility that some number of other labels may have
   been "above it" in the past, or that some number of other labels may
   be below it at present.

We need to assume this is the default behavior of the legacy LSRs.

Best regards,
Jie

From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Wednesday, April 20, 2022 4:09 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>; mpls@ietf.org; John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Subject: Re: [mpls] Concerns about ISD

Jie,

I think we have the same understanding. Not every LSR parses the entire label stack in search for ELI. And for hashing what I recall most implementations just take multiple LSEs not specific EL. EL just happens to be part of it making it more random.

My understanding is that ELI marker is primarily used for handling (apply special operations like insertion or removal) of EL tuple.

Thx,
Robert.



On Wed, 20 Apr 2022 at 09:57, Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>> wrote:
Hi Robert,

This is also the point I raised on the DT meetings.  Neither RFC 3031 nor RFC 6790 mandate the lookup of a bSPL down in the label stack.

RFC 6790 mentions an optional mechanisms based on the lookup of ELI in the label stack so that only EL is used for load balancing. And RFC 8662 (Entropy label for SR) says:

“Then, this entropy label can be used as part of the hash keys used by an LSR.  Using the entropy label as part of the hash keys reduces the need for deep packet inspection in the LSR while keeping a good level of entropy in the load-balancing.  When the entropy label is used, the keys used in the hashing functions are still a local configuration matter, and an LSR may use solely the entropy label or a combination of multiple fields from the incoming packet.”

As long as entropy label is part of the hash key, the expected load balancing result could be achieved.

Best regards,
Jie

From: mpls [mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>] On Behalf Of Robert Raszuk
Sent: Wednesday, April 20, 2022 4:17 AM
To: Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>>
Cc: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>>; John E Drake <jdrake=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>>; mpls@ietf.org<mailto:mpls@ietf.org>
Subject: Re: [mpls] Concerns about ISD


> That died a long time ago, when the Entropy Label came out.

I don't see it that way. And perhaps that was also Haoyu's point.

There is a significant functional and performance difference from using N labels for hashing vs checking (doing lookup) if you recognize value of specific labels embedded down deep in the label stack.

Thx,
R.


On Tue, 19 Apr 2022 at 22:11, Tony Li <tony.li@tony.li<mailto:tony.li@tony.li>> wrote:

Hi Robert,

If those 9 are not MNA capable, then they would see a label (bSPL) that they don’t recognize and should drop the packet.

The whole idea is to avoid having them to even look beyond their own transport label.


That died a long time ago, when the Entropy Label came out.

Tony