[mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec

Italo Busi <Italo.Busi@huawei.com> Mon, 14 June 2021 13:56 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 405993A254A for <mpls@ietfa.amsl.com>; Mon, 14 Jun 2021 06:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 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] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RrgkBWPp565m for <mpls@ietfa.amsl.com>; Mon, 14 Jun 2021 06:55:56 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D49E3A2548 for <mpls@ietf.org>; Mon, 14 Jun 2021 06:55:56 -0700 (PDT)
Received: from fraeml710-chm.china.huawei.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G3XmB5WD2z6G8tf for <mpls@ietf.org>; Mon, 14 Jun 2021 21:46:18 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com ( by fraeml710-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 14 Jun 2021 15:55:53 +0200
Received: from fraeml715-chm.china.huawei.com ([]) by fraeml715-chm.china.huawei.com ([]) with mapi id 15.01.2176.012; Mon, 14 Jun 2021 15:55:53 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: "'mpls@ietf.org'" <mpls@ietf.org>
Thread-Topic: MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec
Thread-Index: AddhI9L1yOOS4MxaRt24LmA/Qqe0iA==
Date: Mon, 14 Jun 2021 13:55:53 +0000
Message-ID: <fa5f1e295e0946c5928613f49e24bddf@huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_fa5f1e295e0946c5928613f49e24bddfhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/7vAGjcY8TMCU83B_tKhgW8FxUuo>
Subject: [mpls] MPLS-RT review for draft-rathi-mpls-egress-tlv-for-nil-fec
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: Mon, 14 Jun 2021 13:56:00 -0000

Hi all,
I have been selected as one of the  MPLS-RT reviewers of draft-rathi-mpls-egress-tlv-for-nil-fec-04

IMHO, being able to use LSP Ping/Traceroute perform to validate only the data path and not the control plane state makes sense but I think that the draft requires more information about the problem that it is trying to address and why existing solutions are not suitable

Let me try to clarify my confusion after having read the draft
Unless I am missing something, section 4.4.1 of RFC8029 already provides support for checking only the data path and not the control plane state:

   If the outermost FEC of the Target FEC stack is the Nil FEC, then the
   node MUST skip the Target FEC validation completely.

The draft mention some challenges with the current definition, but it seems describing only one potential issue:

   ... When router in the label-stack path
   receives MPLS ping/traceroute packets, there is no definite way to
   decide on whether its egress or transit since Nil FEC does not carry
   any information.

However, I am not sure about this issue: looking at the example in the draft, my understanding is that R7 will reply with code 3 while, in traceroute, the intermediate nodes will reply with code 8.

Reading the procedure in section 4.2, I am wondering whether the real intention is to be able to validate the prefix X in R7, rather than the SR path toward R7.

However, in this case, it is not clear why using a FEC for the prefix X instead of the Nil FEC is not suitable.

I also think that section 5 requires more details about how backward compatibility is achieved. What is the behavior of a node that does not support this solution when it receives the EGRESS TLV?