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

[Rakesh Gandhi <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 代表 Giuseppe Fioccola <
> [e-mail]>
> *发送时间:* 2019年11月18日星期一 下午5:17
> *收件人:* Greg Mirsky; Rakesh Gandhi
> *抄送:* [e-mail]; [e-mail]
> *主题:* 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:[e-mail]] *On Behalf Of *Greg Mirsky
> *Sent:* Monday, November 18, 2019 8:07 AM
> *To:* Rakesh Gandhi <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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 <[e-mail]>
> 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:[e-mail]]
> *发送时间:* 2019年11月18日 6:20
> *收件人:* Tianran Zhou <[e-mail]>
> *抄送:* Weiqiang Cheng <[e-mail]>; Tarek Saad <
> [e-mail]>; [e-mail];
> [e-mail]
> *主题:* 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 <[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
> <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 <
> [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
> <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
> [e-mail]
> 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>
>
>
>