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

[Rakesh Gandhi <[e-mail]>]

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 <[e-mail]>
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:[e-mail]]
> *发送时间:* 2019年11月13日 5:12
> *收件人:* Weiqiang Cheng <[e-mail]>
> *抄送:* Tarek Saad <[e-mail]>;
> [e-mail]; [e-mail]
> *主题:* 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 <
> [e-mail]> 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:[e-mail]] *代表 *Tarek Saad
> *发送时间:* 2019年7月22日 21:34
> *收件人:* [e-mail]
> *抄送:* [e-mail]
> *主题:* [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>
>