Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation
Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Mon, 18 November 2019 09:16 UTC
Return-Path: <giuseppe.fioccola@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 AED74120919; Mon, 18 Nov 2019 01:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 ZoddfYsfBLn7; Mon, 18 Nov 2019 01:16:55 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695E51200D6; Mon, 18 Nov 2019 01:16:54 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A7FD552800DB17ACF5A7; Mon, 18 Nov 2019 09:16:50 +0000 (GMT)
Received: from fraeml707-chm.china.huawei.com (10.206.15.35) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Nov 2019 09:16:50 +0000
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) 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.1713.5; Mon, 18 Nov 2019 10:16:50 +0100
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1713.004; Mon, 18 Nov 2019 10:16:49 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Rakesh Gandhi <rgandhi.ietf@gmail.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, "draft-cheng-mpls-inband-pm-encapsulation@ietf.org" <draft-cheng-mpls-inband-pm-encapsulation@ietf.org>
Thread-Topic: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation
Thread-Index: AdWd1CvHKxbMHJ0KT7mOHILu0Wq0QgAAMXeAAABfOAAABbV+4A==
Date: Mon, 18 Nov 2019 09:16:49 +0000
Message-ID: <fe5ae561c8024c4682c5ca7cec887806@huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21BF0D1BD8@NKGEML515-MBX.china.huawei.com> <CAMZsk6d94O0_9KO93dTcSRSiid-Py3U2EwZ+GmLt4LzRi5UakA@mail.gmail.com> <CA+RyBmXpKbWq-qVu1R92zkg2BLj3Cfr5peUqXam2sxYjEVEC6w@mail.gmail.com>
In-Reply-To: <CA+RyBmXpKbWq-qVu1R92zkg2BLj3Cfr5peUqXam2sxYjEVEC6w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.52.42.109]
Content-Type: multipart/alternative; boundary="_000_fe5ae561c8024c4682c5ca7cec887806huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/EKxm3Mx9DDYAS31RGi98A2N6B0M>
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: Mon, 18 Nov 2019 09:17:04 -0000
Hi All, I agree with Greg. And there are at least 3 big differences between IOAM/IOAM-DEX and Alternate Marking: 1) IOAM/IOAM-DEX is a packet level monitoring while Alternate Marking is a flow monitoring solution 2) IOAM/IOAM-DEX introduces a new encapsulation while Alternate Marking can be encapsulated more easily and with less overhead (e.g. dedicated bits or TLV) 3) IOAM/IOAM-DEX architecture is more static (i.e. data specified by the IOAM-Trace-Type are exported by the nodes) while Alternate Marking includes a dynamic approach and can be adapted to the network conditions (i.e. draft-ietf-ippm-multipoint-alt-mark) Best Regards, Giuseppe From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: Monday, November 18, 2019 8:07 AM To: Rakesh Gandhi <rgandhi.ietf@gmail.com> Cc: mpls@ietf.org; draft-cheng-mpls-inband-pm-encapsulation@ietf.org Subject: Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation Hi Rakesh, et al., I don't consider AltMark/SFL as just a lighter version of DEX. One of the benefits of Alt.Marking, in my opinion, is that a node may be aggregating measurements, and export not the raw data, as with DEX, but calculated performance metrics. Regards, Greg On Mon, Nov 18, 2019 at 2:57 PM Rakesh Gandhi <rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>> wrote: Hi Tianran, Thanks for your reply. But this does not answer my question:) Question is why a light way is required when there is already direct export IOAM available. Regarding the SFL comment, when SFLs are used, we do not need L/D flags in the header for coloring, as an SFL itself indicates the color. Thanks, Rakesh On Mon, Nov 18, 2019 at 1:57 PM Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> wrote: Hi Rakesh, Thanks for your interest. I think the requirement of using alternate marking for mpls pm has already been acknowledged by this wg. As Tarek mentioned several times, the SFL is produced for this usage. We bring a new encapsulation here to mitigate the deployment issue when we try to apply the SFL. That’s our simple motivation. BR, Tianran 发件人: Rakesh Gandhi [mailto:rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>] 发送时间: 2019年11月18日 6:20 收件人: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> 抄送: Weiqiang Cheng <chengweiqiang@chinamobile.com<mailto:chengweiqiang@chinamobile.com>>; Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>; draft-cheng-mpls-inband-pm-encapsulation@ietf.org<mailto:draft-cheng-mpls-inband-pm-encapsulation@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org> 主题: Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation Hi Tianran, Thanks for your reply. Right, IOAM Direct Export covers more than just PM. Both drafts would also require special labels for the direct export for MPLS case. With this in mind, you may clarify in the draft why lite way is required for PM for MPLS case and how it is achieved with your draft compared to the IOAM direct export. Thanks, Rakesh On Sun, Nov 17, 2019 at 12:44 PM Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>> wrote: Hi Rakesh, As the coauthor of both drafts, I think they are different. This draft is only for performance measurement in a lite way. IOAM-DEX is to collect data based on the trace type instruction. Thanks, Tianran 发件人: Rakesh Gandhi [mailto:rgandhi.ietf@gmail.com<mailto:rgandhi.ietf@gmail.com>] 发送时间: 2019年11月13日 5:12 收件人: Weiqiang Cheng <chengweiqiang@chinamobile.com<mailto:chengweiqiang@chinamobile.com>> 抄送: Tarek Saad <tsaad.net@gmail.com<mailto:tsaad.net@gmail.com>>; draft-cheng-mpls-inband-pm-encapsulation@ietf.org<mailto:draft-cheng-mpls-inband-pm-encapsulation@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org> 主题: Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation Hi Authors, FYI: The draft has some similarity with the functionality defined in the following draft which is generically applicable to the all encap types: https://tools.ietf.org/html/draft-ioamteam-ippm-ioam-direct-export-00 You may want to have a look. Thanks, Rakesh On Wed, Sep 25, 2019 at 3:00 AM Weiqiang Cheng <chengweiqiang@chinamobile.com<mailto:chengweiqiang@chinamobile.com>> wrote: 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<mailto:mpls-bounces@ietf.org>] 代表 Tarek Saad 发送时间: 2019年7月22日 21:34 收件人: draft-cheng-mpls-inband-pm-encapsulation@ietf.org<mailto:draft-cheng-mpls-inband-pm-encapsulation@ietf.org> 抄送: mpls@ietf.org<mailto: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 _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org<mailto:mpls@ietf.org> https://www.ietf.org/mailman/listinfo/mpls
- [mpls] Comments on draft draft-cheng-mpls-inband-… Tarek Saad
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Weiqiang Cheng
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Rakesh Gandhi
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Tianran Zhou
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Tarek Saad
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Rakesh Gandhi
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Tianran Zhou
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Rakesh Gandhi
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Greg Mirsky
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Giuseppe Fioccola
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Haoyu Song
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Rakesh Gandhi
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Loa Andersson
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Greg Mirsky
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Loa Andersson
- Re: [mpls] Comments on draft draft-cheng-mpls-inb… Tianran Zhou