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

From: Tianran Zhou <[email-masked]>
Date: Mon, 18 Nov 2019 05:56:56 +0000

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

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 18 Nov 2019 14:56:39 +0800

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 <[email-masked]> wrote:

> 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.
>
> *发件人:* Rakesh Gandhi [mailto:[email-masked]]
> *发送时间:* 2019年11月18日 6:20
> *收件人:* Tianran Zhou <[email-masked]>
> *抄送:* Weiqiang Cheng <[email-masked]>; Tarek Saad <
> [email-masked]>; [email-masked];
> [email-masked]
> *主题:* 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 <[email-masked]>
> wrote:
>
> Hi Rakesh,
>
>
>
> *发件人**:* Rakesh Gandhi [mailto:[email-masked]]
> *发送时间**:* 2019年11月13日 5:12
> *收件人**:* Weiqiang Cheng <[email-masked]>
> *抄送**:* Tarek Saad <[email-masked]>;
> [email-masked]; [email-masked]
> *主题**:* 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:
>
>
>
> On Wed, Sep 25, 2019 at 3:00 AM Weiqiang Cheng <
> [email-masked]> wrote:
>
> Hi Tarek,
>
> *发件人:* mpls [mailto:[email-masked]] *代表 *Tarek Saad
> *发送时间:* 2019年7月22日 21:34
> *收件人:* [email-masked]
> *抄送:* [email-masked]
> *主题:* [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation
>
>
>
> Hi authors,
>
>
>
>    - 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
>
> [email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 18 Nov 2019 15:07:18 +0800

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 <[email-masked]>
wrote:

> Question is why a light way is required when there is already direct
> export IOAM available.
>
>> 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.
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    be highlighted..
>> [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
>>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 18 Nov 2019 09:16:49 +0000

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:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, November 18, 2019 8:07 AM
To: Rakesh Gandhi <[email-masked]>
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,

BR,
Tianran

发件人: Rakesh Gandhi [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2019年11月18日 6:20
收件人: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
抄送: Weiqiang Cheng <[email-masked]<mailto:[email-masked]>>; Tarek Saad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
主题: Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation

Hi Tianran,
Thanks for your reply.

Thanks,
Tianran

Hi Authors,
FYI:

Thanks,
Rakesh

B.R.
Weiqiang Cheng

Hi authors,

  *   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...

Regards,
Tarek

---

From: Haoyu Song <[email-masked]>
Date: Mon, 18 Nov 2019 09:55:22 +0000

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 <[email-masked]> 代表 Giuseppe Fioccola <[email-masked]>
发送时间: 2019年11月18日星期一 下午5:17
收件人: Greg Mirsky; Rakesh Gandhi
抄送: [email-masked]; [email-masked]
主题: Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation

Hi All,

Best Regards,

Giuseppe

Hi Rakesh, et al.,

Regards,
Greg

Thanks,
Rakesh

BR,
Tianran

Hi Tianran,
Thanks for your reply.

Thanks,
Tianran

Hi Authors,
FYI:

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>

Thanks,
Rakesh

B.R.
Weiqiang Cheng

Hi authors,

Regards,
Tarek
_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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>

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 19 Nov 2019 07:52:52 +0800

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 <[email-masked]> 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 <[email-masked]> 代表 Giuseppe Fioccola <
> [email-masked]>
> *发送时间:* 2019年11月18日星期一 下午5:17
> *收件人:* Greg Mirsky; Rakesh Gandhi
> *抄送:* [email-masked]; [email-masked]
> 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:[email-masked]] *On Behalf Of *Greg Mirsky
> *Sent:* Monday, November 18, 2019 8:07 AM
> *To:* Rakesh Gandhi <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [mpls] Comments on draft
> *主**题**:* Re: [mpls] Comments on draft
> <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>
>
>
>
> *发件人**:* mpls [mailto:[email-masked]] *代表* Tarek Saad
> *发送时间**:* 2019年7月22日 21:34
> *收件人**:* [email-masked]
> *抄送**:* [email-masked]
> *主**题**:* [mpls] Comments on draft
>    be highlighted...
> <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>
>
> <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>
>
>
>

---

From: Loa Andersson <[email-masked]>
Date: Tue, 19 Nov 2019 09:03:21 +0800

Rakesh,

Good idea, would be enough if we captured this in the MPLS document, or
should it be in the IPPM draft also?

/Loa

PS
I added the IPPM chairs to this thread.

On 19/11/2019 07:52, Rakesh Gandhi wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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 <[email-masked] <mailto:mpls-
>     [email-masked]>> 代表 Giuseppe Fioccola
>     <[email-masked] <mailto:[email-masked]>>
>     *抄送:* [email-masked] <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>
>     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:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Greg Mirsky
>     *To:* Rakesh Gandhi <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>
>     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
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi Tianran,
> 
>         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 <mailto:[email-masked]>> wrote:
> 
>             Hi Rakesh,
> 
>             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.
> 
>             *发件人**:*Rakesh Gandhi [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *发送时间:* 2019年11月18日 6:20
>             *收件人:* Tianran Zhou <[email-masked]
>             <mailto:[email-masked]>>
>             *抄送:* Weiqiang Cheng <[email-masked]
>             <mailto:[email-masked]>>; Tarek Saad
>             <[email-masked] <mailto:[email-masked]>>;
>             [email-masked]
>             <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>
>             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
>             <[email-masked] <mailto:[email-masked]>> wrote:
> 
>                 Hi Rakesh,
> 
>                 *发件人**:*Rakesh Gandhi [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 *发送时间**:*2019年11月13日5:12
>                 *收件人**:*Weiqiang Cheng <[email-masked]
>                 <mailto:[email-masked]>>
>                 *抄送**:*Tarek Saad <[email-masked]
>                 <mailto:[email-masked]>>;
>                 [email-masked]
>                 <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>
>                 *主**题**:*Re: [mpls] Comments on draft
>                 The draft has some similarity with the functionality
>                 defined in the following draft which is generically
>                 applicable to the all encap types:
> 
>                 On Wed, Sep 25, 2019 at 3:00 AM Weiqiang Cheng
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
> 
>                     Hi Tarek,
> 
>                     *发件人**:*mpls [mailto:[email-masked]
>                     <mailto:[email-masked]>] *代表***Tarek Saad
>                     *发送时间**:*2019年7月22日21:34
>                     *收件人**:*draft-cheng-mpls-inband-pm-
>                     [email-masked]
>                     <mailto:[email-masked]>
>                     *抄送**:[email-masked] <mailto:[email-masked]>
>                     *主**题**:*[mpls] Comments on draft
>                       * 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
> 
>                     [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 19 Nov 2019 12:47:18 +0800

Hi Loa,
I think that the IPPM document already exists - it is RFC 8321. Also, there
are a number of drafts, e.g., in BIER, SFC, and NVO3 WGs, that describe how
the Alternate Marking method can be applied to the particular network.

Regards,
Greg

Regards,
Greg

On Tue, Nov 19, 2019 at 9:03 AM Loa Andersson <[email-masked]> wrote:

> >                 <mailto:
> [email-masked]>;
> >                 <
> 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
> >
> >
> >                     <mailto:
> [email-masked]>
> >                     <
> 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
> >
> >
> >         <
> 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
> >
> >
> >
> >

---

From: Loa Andersson <[email-masked]>
Date: Tue, 19 Nov 2019 13:56:02 +0800

Greg,

tnx! Then we have the question on there to document the differences
between the two solutions, do we have any ideas?

/Loa

On 19/11/2019 12:47, Greg Mirsky wrote:
> Hi Loa,
> I think that the IPPM document already exists - it is RFC 8321. Also, 
> there are a number of drafts, e.g., in BIER, SFC, and NVO3 WGs, that 
> describe how the Alternate Marking method can be applied to the 
> particular network.
> 
> Regards,
> Greg
> 
> Regards,
> Greg
> 
> On Tue, Nov 19, 2019 at 9:03 AM Loa Andersson <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Rakesh,
> 
>      > On Mon, Nov 18, 2019 at 5:55 PM Haoyu Song
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     *发件人:* mpls <[email-masked]
>     <mailto:[email-masked]> <mailto:mpls- <mailto:mpls->
>      > [email-masked] <mailto:[email-masked]>>> 代表 Giuseppe Fioccola
>      >     <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >     *抄送:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>;
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     I agree with Greg. And there are at least 3 big differences
>     between
>      >     IOAM/IOAM-DEX and Alternate Marking:
>      >
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>] *On Behalf Of *Greg Mirsky
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >     *Cc:* [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>;
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >         Hi Tianran,
>      >
>      >         <zhoutianran@huawei..com <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >             Hi Rakesh,
>      >
>      >             We bring a new encapsulation here to mitigate the
>     deployment
>      >             issue when we try to apply the SFL.
>      >
>      >             *发件人**:*Rakesh Gandhi
>     [mailto:[email-masked] <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>]
>      >             *发送时间:* 2019年11月18日 6:20
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >             <mailto:[email-masked]
>     <mailto:[email-masked]>>>; Tarek Saad
>      >             <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>;
>       <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >             <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >                 Hi Rakesh,
>      >
>      >                 This draft is only for performance measurement in
>     a lite
>      >                 way.
>      >
>      >                 *发件人**:*Rakesh Gandhi
>     [mailto:[email-masked] <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>]
>      >                 *发送时间**:*2019年11月13日5:12
>      >                 *收件人**:*Weiqiang Cheng
>     <[email-masked] <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>     <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>>;
>       <mailto:[email-masked]
>     <mailto:[email-masked]>>;
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked]>
>      >                 <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >                     Hi Tarek,
>      >
>     <mailto:[email-masked]>
>      >                     <mailto:[email-masked]
>     <mailto:[email-masked]>>] *代表***Tarek Saad
>      >                     *发送时间**:*2019年7月22日21:34
>      > [email-masked] <mailto:[email-masked]>
>      >                   
>       <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
>     Senior MPLS Expert

--

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 19 Nov 2019 08:03:13 +0000

I think we can describe the difference and design choice in draft-cheng-mpls-inband-pm-encapsulation.

Tianran

Sent from WeLink

发件人： Loa Andersson<[email-masked]<mailto:[email-masked]>>
收件人： Greg Mirsky<[email-masked]<mailto:[email-masked]>>
抄送： Rakesh Gandhi<[email-masked]<mailto:[email-masked]>>;Haoyu Song<[email-masked]<mailto:[email-masked]>>;mpls<[email-masked]<mailto:[email-masked]>>;ippm-chairs<[email-masked]<mailto:[email-masked]>>;draft-cheng-mpls-inband-pm-encapsulation<[email-masked]<mailto:[email-masked]>>
主题： Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation
时间： 2019-11-19 13:56:31

Greg,

/Loa

--