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> 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] *代表 *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
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>