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

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> 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]
> *发送时间:* 2019年11月18日 6:20
> *收件人:* Tianran Zhou <zhoutianran@huawei.com>
> *抄送:* Weiqiang Cheng <chengweiqiang@chinamobile.com>; Tarek Saad <
> tsaad.net@gmail.com>; draft-cheng-mpls-inband-pm-encapsulation@ietf.org;
> 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>
> 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]
> *发送时间**:* 2019年11月13日 5:12
> *收件人**:* Weiqiang Cheng <chengweiqiang@chinamobile.com>
> *抄送**:* Tarek Saad <tsaad.net@gmail.com>;
> draft-cheng-mpls-inband-pm-encapsulation@ietf.org; 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> 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
>
>