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

[Loa Andersson <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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]>
>      > <mailto:[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:[e-mail]> <mailto:mpls- <mailto:mpls->
>      > [e-mail] <mailto:[e-mail]>>> 代表 Giuseppe Fioccola
>      >     <[e-mail]
>     <mailto:[e-mail]>
>     <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >     *发送时间:* 2019年11月18日星期一 下午5:17
>      >     *收件人:* Greg Mirsky; Rakesh Gandhi
>      >     *抄送:* [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>;
>      > [e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[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]>
>      >     <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]>
>      >     <mailto:[e-mail] <mailto:[e-mail]>>>
>      >     *Cc:* [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>;
>      > [e-mail]
>     <mailto:[e-mail]>
>      >     <mailto:[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]>
>     <mailto:[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]
>     <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]>
>      >             <mailto:[e-mail]
>     <mailto:[e-mail]>>]
>      >             *发送时间:* 2019年11月18日 6:20
>      >             *收件人:* Tianran Zhou <[e-mail]
>     <mailto:[e-mail]>
>      >             <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >             *抄送:* Weiqiang Cheng <[e-mail]
>     <mailto:[e-mail]>
>      >             <mailto:[e-mail]
>     <mailto:[e-mail]>>>; Tarek Saad
>      >             <[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>>;
>      > [e-mail]
>     <mailto:[e-mail]>
>      >           
>       <mailto:[e-mail]
>     <mailto:[e-mail]>>;
>      > [e-mail] <mailto:[e-mail]> <mailto:[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]> <mailto:[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]>
>      >                 <mailto:[e-mail]
>     <mailto:[e-mail]>>]
>      >                 *发送时间**:*2019年11月13日5:12
>      >                 *收件人**:*Weiqiang Cheng
>     <[e-mail] <mailto:[e-mail]>
>      >                 <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>      >                 *抄送**:*Tarek Saad <[e-mail]
>     <mailto:[e-mail]>
>      >                 <mailto:[e-mail]
>     <mailto:[e-mail]>>>;
>      > [e-mail]
>     <mailto:[e-mail]>
>      >               
>       <mailto:[e-mail]
>     <mailto:[e-mail]>>;
>      > [e-mail] <mailto:[e-mail]> <mailto:[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]>
>      >                 <mailto:[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]>
>      >                     <mailto:[e-mail]
>     <mailto:[e-mail]>>] *代表***Tarek Saad
>      >                     *发送时间**:*2019年7月22日21:34
>      >                     *收件人**:*draft-cheng-mpls-inband-pm-
>      > [e-mail] <mailto:[e-mail]>
>      >                   
>       <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >                     *抄送**:*[e-mail] <mailto:[e-mail]>
>     <mailto:[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]> <mailto:[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]> <mailto:[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] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/mpls
>      >
> 
>     -- 
> 
> 
>     Loa Andersson                        email: [e-mail] <mailto:[e-mail]>
>     Senior MPLS Expert
>     Bronze Dragon Consulting             phone: [phone]
> 
>     _______________________________________________
>     mpls mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mpls
> 

-- 


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