[mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04

Mach Chen <mach.chen@huawei.com> Wed, 30 December 2020 09:19 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 51A613A040B; Wed, 30 Dec 2020 01:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bvcz3sRG4xpz; Wed, 30 Dec 2020 01:19:51 -0800 (PST)
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 D3E343A03FC; Wed, 30 Dec 2020 01:19:50 -0800 (PST)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4D5QdQ5KRRz67Ptx; Wed, 30 Dec 2020 17:16:26 +0800 (CST)
Received: from fraeml707-chm.china.huawei.com (10.206.15.35) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 30 Dec 2020 10:19:49 +0100
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 30 Dec 2020 10:19:49 +0100
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.102]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Wed, 30 Dec 2020 17:19:44 +0800
From: Mach Chen <mach.chen@huawei.com>
To: mpls <mpls@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>
CC: "draft-gandhi-mpls-ioam-sr@ietf.org" <draft-gandhi-mpls-ioam-sr@ietf.org>
Thread-Topic: MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
Thread-Index: AQHW2hyDHDvVF1VdnUGaj2r8EB36K6oPXEyw
Date: Wed, 30 Dec 2020 09:19:44 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2980ACEB1@dggeml530-mbs.china.huawei.com>
References: <CAA=duU21PHQoJP0cEX6o1K=EwUFqeH19YvcDPNJVKE9c2szS6w@mail.gmail.com>
In-Reply-To: <CAA=duU21PHQoJP0cEX6o1K=EwUFqeH19YvcDPNJVKE9c2szS6w@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.108.243.140]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/7YqdnmBPX79Gc7HpbeZA8y75JQk>
Subject: [mpls] MPLS-RT Review of draft-gandhi-mpls-ioam-sr-04
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, 30 Dec 2020 09:19:52 -0000

Hi, 

I've been asked to provide a pre-adoption MPLS-RT review of draft-gandhi-mpls-ioam-sr-04.

Below are my review comments:

1. I agree that it's more reasonable to leverage GAL/gACH with one or two new dedicated channel types for indicating the presence of iOAM data.

2. In addition, the draft proposes to support both E2E and hop-by-hop (HBH) options. It's nature to use GAL/gACH or the IOAM Indicator Label (IIL) to indicate the presence of iOAM data.  But for HBH case, each intermediate LSR is supposed to process the iOAM data, and the GAL or IIL is put at the bottom of the stack, how does an intermediate LSR know whether there is iOAM data present and it should process the iOAM data?  To scan the whole label stack to find the GAL/IIL or through other means (e.g., put an indicator label on the top the label stack, this may require that each LSR need to pop the IIL label firstly, then process the next label, and put the IIL label back onto the top when forwarding the packet to the next hop) ?  For either way, this needs to be explicitly defined in the document. 

I am OK with other parts of the draft, but the above comments would result in non-trivial updates to the draft, I would see an update before the WG adoption call.

Best regards,
Mach