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