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

[Tarek Saad <[e-mail]>]

Hi Cheng,

Thanks. I¡¯m explicitly adding the SFL ID authors to comment on some of your concerns too.
See Inline for response..

From: Weiqiang Cheng <[e-mail]>
Date: Wednesday, September 25, 2019 at 3:00 PM
To: 'Tarek Saad' <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [mpls] Comments on draft draft-cheng-mpls-inband-pm-encapsulation

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:

     *   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.
[TS]: Yes, don¡¯t see reason for SFL not working for hop-by-hop measurements too.. ¡°too complex¡± is probably subjective here.. What I see is SFL is not introducing new HW requirements/support and hence arguably less complex than the alternative proposed here which requires new HW support. Also note, rfc8321 Alternate states that 2 SFL labels can be used for coloring flows.

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.
[TS]: differing answer to this to authors for SFL document.

¡¤         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.
[TS]: I am concerned that you are redefining the format of the MPLS label ¨C In Figure 1 in draft-cheng-mpls-inband-pm-encapsulation, I see the last label in the MPLS label stack is overloading MPLS label fields (TC, and TTL) to carry flags and other reserved field.. This is in violation to RFC3032 (to the least) and may have other implications too.

Regards,
Tarek

Regards,
Tarek