Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation
Loa Andersson <loa@pi.nu> Tue, 19 November 2019 01:03 UTC
Return-Path: <loa@pi.nu>
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 A32E312012C; Mon, 18 Nov 2019 17:03:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 hIMYUfgglxRb; Mon, 18 Nov 2019 17:03:30 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142481200F7; Mon, 18 Nov 2019 17:03:30 -0800 (PST)
Received: from [31.133.157.221] (dhcp-9ddd.meeting.ietf.org [31.133.157.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 6D7DD35DF55; Tue, 19 Nov 2019 02:03:26 +0100 (CET)
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>, Haoyu Song <haoyu.song@futurewei.com>
Cc: "draft-cheng-mpls-inband-pm-encapsulation@ietf.org" <draft-cheng-mpls-inband-pm-encapsulation@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>
References: <BBA82579FD347748BEADC4C445EA0F21BF0D1BD8@NKGEML515-MBX.china.huawei.com> <CAMZsk6d94O0_9KO93dTcSRSiid-Py3U2EwZ+GmLt4LzRi5UakA@mail.gmail.com> <CA+RyBmXpKbWq-qVu1R92zkg2BLj3Cfr5peUqXam2sxYjEVEC6w@mail.gmail.com> <fe5ae561c8024c4682c5ca7cec887806@huawei.com> <MWHPR13MB1648AA2A53854A001E2F90129A4D0@MWHPR13MB1648.namprd13.prod.outlook.com> <CAMZsk6cccUx2dXFxdH7QkkONvS7=k2nknLOFZdVLiEOoOyK_Wg@mail.gmail.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <09e5a1cf-ed35-b014-8051-8a55cc2f91c0@pi.nu>
Date: Tue, 19 Nov 2019 09:03:21 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <CAMZsk6cccUx2dXFxdH7QkkONvS7=k2nknLOFZdVLiEOoOyK_Wg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/dckknwXlU1_I_X3rb29LIzy71Gg>
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: Tue, 19 Nov 2019 01:03:35 -0000
Rakesh, Good idea, would be enough if we captured this in the MPLS document, or should it be in the IPPM draft also? /Loa PS I added the IPPM chairs to this thread. On 19/11/2019 07:52, Rakesh Gandhi wrote: > Hi Folks, > Many thanks for providing the detailed comparison information for the > two approaches. It would be good to capture them in the draft. > > Thanks, > Rakesh > > > On Mon, Nov 18, 2019 at 5:55 PM Haoyu Song <haoyu.song@futurewei.com > <mailto:haoyu.song@futurewei.com>> wrote: > > I agree the two techniques covers different use cases with different > cost. Each has its own merits. Sometimes header overhead and data > export bandwidth are big concerns. If AM is all user needs, > there's no point to use a more powerful yet more costly technique. > > Haoyu > > > > ------------------------------------------------------------------------ > *发件人:* mpls <mpls-bounces@ietf.org <mailto:mpls- > bounces@ietf.org>> 代表 Giuseppe Fioccola > <giuseppe.fioccola@huawei.com <mailto:giuseppe.fioccola@huawei.com>> > *发送时间:* 2019年11月18日星期一 下午5:17 > *收件人:* Greg Mirsky; Rakesh Gandhi > *抄送:* mpls@ietf.org <mailto:mpls@ietf.org>; > draft-cheng-mpls-inband-pm-encapsulation@ietf.org > <mailto:draft-cheng-mpls-inband-pm-encapsulation@ietf.org> > *主题:* Re: [mpls] Comments on draft > draft-cheng-mpls-inband-pm-encapsulation > > 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 > <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 > <mailto:rgandhi.ietf@gmail.com>> > *Cc:* mpls@ietf.org <mailto:mpls@ietf.org>; > draft-cheng-mpls-inband-pm-encapsulation@ietf.org > <mailto: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 > <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ioamteam-ippm-ioam-direct-export-00&data=02%7C01%7Chaoyu.song%40futurewei.com%7Cb28cbc36bf1c4dc2b1ad08d76c082e64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096654713533899&sdata=8%2FMYlbsByQtiewLK0%2BgHzGu9rAJybEVbozdAG6mH5Jo%3D&reserved=0> > > 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 > <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=02%7C01%7Chaoyu.song%40futurewei.com%7Cb28cbc36bf1c4dc2b1ad08d76c082e64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096654713533899&sdata=eLlJd2dsRk5jZyOGbwGCGt6HushkmcjiEiGo3alzvOA%3D&reserved=0> > > _______________________________________________ > mpls mailing list > mpls@ietf.org <mailto:mpls@ietf.org> > https://www.ietf.org/mailman/listinfo/mpls > <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=02%7C01%7Chaoyu.song%40futurewei.com%7Cb28cbc36bf1c4dc2b1ad08d76c082e64%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637096654713543892&sdata=HeBC5bx%2F8nbA0wOPIXZiQNQz8JVGTE%2Fn4DAlpE6uVhY%3D&reserved=0> > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64
- [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