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

[Loa Andersson <[e-mail]>]

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 <[e-mail] 
> <mailto:[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] <mailto:mpls-
>     [e-mail]>> 代表 Giuseppe Fioccola
>     <[e-mail] <mailto:[e-mail]>>
>     *发送时间:* 2019年11月18日星期一 下午5:17
>     *收件人:* Greg Mirsky; Rakesh Gandhi
>     *抄送:* [e-mail] <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[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]
>     <mailto:[e-mail]>] *On Behalf Of *Greg Mirsky
>     *Sent:* Monday, November 18, 2019 8:07 AM
>     *To:* Rakesh Gandhi <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>;
>     [e-mail]
>     <mailto:[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] <mailto:[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
>         <zhoutianran@huawei..com <mailto:[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]
>             <mailto:[e-mail]>]
>             *发送时间:* 2019年11月18日 6:20
>             *收件人:* Tianran Zhou <[e-mail]
>             <mailto:[e-mail]>>
>             *抄送:* Weiqiang Cheng <[e-mail]
>             <mailto:[e-mail]>>; Tarek Saad
>             <[e-mail] <mailto:[e-mail]>>;
>             [e-mail]
>             <mailto:[e-mail]>;
>             [e-mail] <mailto:[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] <mailto:[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]
>                 <mailto:[e-mail]>]
>                 *发送时间**:*2019年11月13日5:12
>                 *收件人**:*Weiqiang Cheng <[e-mail]
>                 <mailto:[e-mail]>>
>                 *抄送**:*Tarek Saad <[e-mail]
>                 <mailto:[e-mail]>>;
>                 [e-mail]
>                 <mailto:[e-mail]>;
>                 [e-mail] <mailto:[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]
>                 <mailto:[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]
>                     <mailto:[e-mail]>] *代表***Tarek Saad
>                     *发送时间**:*2019年7月22日21:34
>                     *收件人**:*draft-cheng-mpls-inband-pm-
>                     [e-mail]
>                     <mailto:[e-mail]>
>                     *抄送**:*[e-mail] <mailto:[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] <mailto:[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] <mailto:[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>
> 
> 
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> 

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert
Bronze Dragon Consulting             phone: [phone]