Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation

"Weiqiang Cheng" <chengweiqiang@chinamobile.com> Wed, 25 September 2019 07:00 UTC

Return-Path: <chengweiqiang@chinamobile.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 D414D1200B8; Wed, 25 Sep 2019 00:00:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 KUlPQj4Z9_BF; Wed, 25 Sep 2019 00:00:18 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBF27120041; Wed, 25 Sep 2019 00:00:13 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee65d8b1071c35-0b7bb; Wed, 25 Sep 2019 15:00:01 +0800 (CST)
X-RM-TRANSID: 2ee65d8b1071c35-0b7bb
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc (unknown[117.136.0.206]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee95d8b106fabc-eb35b; Wed, 25 Sep 2019 15:00:00 +0800 (CST)
X-RM-TRANSID: 2ee95d8b106fabc-eb35b
From: Weiqiang Cheng <chengweiqiang@chinamobile.com>
To: 'Tarek Saad' <tsaad.net@gmail.com>, draft-cheng-mpls-inband-pm-encapsulation@ietf.org
Cc: mpls@ietf.org
References: <BYAPR19MB3415E16096ADA1A714B09D93FCC40@BYAPR19MB3415.namprd19.prod.outlook.com>
In-Reply-To: <BYAPR19MB3415E16096ADA1A714B09D93FCC40@BYAPR19MB3415.namprd19.prod.outlook.com>
Date: Wed, 25 Sep 2019 14:59:59 +0800
Message-ID: <017701d5736e$d9153460$8b3f9d20$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0178_01D573B1.E7387460"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHVQJIWax8TxKN6GECB1mNyFzhZn6c8W4IA
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/oLSKg6xyzjnf00pLzjRab3SY45U>
Subject: Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation
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, 25 Sep 2019 07:00:23 -0000

Hi Tarek,

Thank you very much for your comments.

We authors had some discussion on it and our feedback is in-line.

 

B.R.

Weiqiang Cheng

 

发件人: mpls [mailto:mpls-bounces@ietf.org] 代表 Tarek Saad
发送时间: 2019年7月22日 21:34
收件人: draft-cheng-mpls-inband-pm-encapsulation@ietf.org
抄送: mpls@ietf.org
主题: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation

 

Hi authors,

 

>From reading your draft, have the following comments:

*	There’s a similar proposal in draft-ietf-mpls-rfc6374-sfl that the
WG has worked on to achieve similar PM measurements. That proposal did not
require a special label, nor requires carrying 2 new additional labels in
label stack. Do you see any downside to the approach in
draft-ietf-mpls-rfc6374-sfl vs. the new one introduced one? If so, can this
be highlighted.

[Weiqiang]   Yes, the SFL proposal was carefully considered before this
draft was written, and the major downsides of SFL include:

1. It seems that the current version of SFL targets at end-to-end
performance measurement,  but our draft targets at both end-to-end and
hop-by-hop performance measurement. Of course, someone may argue that the
SFL can be extended to support hop-by-hop performance measurement, but if
that happens, the SFL method is too complex for label management, because
basically it assigns two implications to one mpls label.

2. The SFL method can't be applied when we want to achieve performance
measurements on both LSP and PW synchronously, but the method described in
our draft can simply achieve that.

 

*	It appears that the label below the “Flow Indicator Label” is used
to carry/embed context information: including a flow identifier and
additional flags - that are set by ingress. Normally, MPLS labels do not
embed any context information about the flow they carry within them. The
context of the label is held by the node that allocates the label.

[Weiqiang]   Your understanding is perfectly correct. And please also note
that in our draft the Flow-ID label values are allocated by an external NMS
or a controller, that means the context of the Flow-ID label is held by all
the nodes within the administrative domain. Furthermore, I want to stress
that the method described in our draft has already been implemented by more
than two vendors, and we plan to deploy it in our commercial 5G backhaul
networks.

 

 

Regards,

Tarek