[mpls] MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02

Mach Chen <mach.chen@huawei.com> Wed, 02 June 2021 03:59 UTC

Return-Path: <mach.chen@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 6A75A3A3338; Tue, 1 Jun 2021 20:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMY5mCxpnqhM; Tue, 1 Jun 2021 20:59:26 -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 EE2A73A3337; Tue, 1 Jun 2021 20:59:25 -0700 (PDT)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Fvw8w2qWRz6P3j6; Wed, 2 Jun 2021 11:52:48 +0800 (CST)
Received: from dggpemm500002.china.huawei.com (7.185.36.229) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 2 Jun 2021 05:59:17 +0200
Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm500002.china.huawei.com (7.185.36.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 2 Jun 2021 11:59:14 +0800
Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2176.012; Wed, 2 Jun 2021 11:59:14 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "draft-ninan-mpls-spring-inter-domain-oam@ietf.org" <draft-ninan-mpls-spring-inter-domain-oam@ietf.org>
CC: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02
Thread-Index: AddXYNePcnIVic4hQKi6eG9X0nDXKw==
Date: Wed, 02 Jun 2021 03:59:14 +0000
Message-ID: <5c57943cc68c4457ae622086cd484500@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.140]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/hy4CYpcAE3UgVYgzHQmCixDXsvw>
Subject: [mpls] MPLS-RT review on draft-ninan-mpls-spring-inter-domain-oam-02
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, 02 Jun 2021 03:59:29 -0000

Hi,

I am selected as a MPLS-RT reviewer of draft-ninan-mpls-spring-inter-domain-oam.

After review, I think the problem that the draft is trying to address is valid and useful. The solution is overall workable. My comments are mainly about Type 3 and Type 4 segment sub-TLV, I think it's better to address these comments before the adoption.

Type 3 and 4 sub-TLVs are supposed to be used when the headend/PMS does not have the labels or SRGB information of the remote nodes, and assume that the receiving node (egress node) can derive the MPLS labels according to the IPv4/IPv6 addresses. This assumption may not hold, because given that the headend/PMS does not have the information, it is very likely that the receiving node has no the information either. So the draft should add more text to clarify the use cases of type 3, 4 sub-TLVs, or just remove them.

In addition, given type 3 and 4 have valid use case, the optional SID fields of type 3 and 4 are redundant, I think that they should be removed. 

Section 4, 
"Below types of segment sub-TLVs are applicable for the Reverse Path
   Segment List TLV."

Should the "Reverse Path Segment List TLV" be "Return Path TLV"?

Best regards,
Mach