Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path

From: Xuxiaohu <[email-masked]>
Date: Wed, 10 Apr 2013 04:17:05 +0000

Hi all,

I have reviewed this doc. I believe this doc is useful, but I have a few comments as follows for consideration:

1. in section 2.1, it said " While it has been possible to compute a CSPF where the link latency
   values are used instead of TE metrics, this results in ignoring the
   TE metrics and causing LSPs to prefer the lowest-latency paths.
   Instead of this approach to minimize path latency, an end-to-end
   latency bound merely requires that the path computed be no more than
   that bound without being the minimum.  This bound can be used as a
   constraint in CSPF to prevent exploring links that would create a
   path over the end-to-end latency bound.

   This is illustrated as follows.  Let the LSP have an end-to-end
   latency bound of 20ms.  Assume that the path to node X has been
   minimized and its latency is 12ms.  When X's links are to be
   explored, the link X<->Y has a link latency of 5ms and the link X<->Z
   has a link latency of 9ms.  The path via X to Y along link X<->Y
   would have a path latency of 12ms + 5ms = 17ms < 20ms; therefore, the
   link X<->Y can be explored.  In contrast, reaching Z via link X<->Z
   would result in a path latency of 12ms + 9ms = 21ms > 20ms; therefore
   the link X<->Z would not be explored in the CSPF."

   Comment: According to an above statement of " an end-to-end latency bound merely requires that the path computed be no more than that bound without being the minimum ", it seems that latency is not used as a metric for SPF algorithm but only used as a constraint. If so, how do you decide which specific link(s) of the first-round calculated SPF path should be pruned prior to executing the second-round SPF calculation?  The same question exists when considering end-to-end packet loss ratio and latency variation bounds. The example illustrated in the draft seems not clear to me. Would any co-author please clarify the above doubt?

2.  in section 2.1, it said "For link loss, the path loss is not the sum of the used links'
   losses.  Instead, the path loss percentage is (100 - loss_L1)*(100 -
   loss_L2)*...*(100 - loss_Ln), where the links along the path are L1
   to Ln.  The end-to-end link loss bound, computed in this fashion, can
   also be used as a constraint in the CSPF on what links to explore". 

   Comment: I guess co-authors wanted to say packet loss ratio here. If so, the formula of packet loss ratio here needs to be correctly expressed.

3.  In section 2.2, it said " When computing
   the path for a TE tunnel, only links with at least a configurable
   amount of Unidirectional Available Bandwidth might be permitted."
   
   Comment: I wonder whether it is suitable to consider Residual Bandwidth and Unidirectional Available Bandwidth parameters as performance metrics and therefore discuss them in this doc. Furthermore, whether or not the measured bandwidth used for the actual forwarding of non-
   RSVP-TE LSP packets should be a constraint for CSPF depends on many factors, such as whether or not this bandwidth can be occupied by future RSVP-TE LSP traffic. Hence, maybe it's more suitable to discuss in details the bandwidth constraint related issues in a separate doc. 

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Loa Andersson [mailto:[email-masked]]
> 发送时间: 2013年4月6日 12:51
> 收件人: Dutta, Pranjal K (Pranjal); Sriganesh Kini; Rajiv Asati (rajiva); Xuxiaohu;
> [email-masked]; [email-masked]
> 主题: MPLS-RT review of draft-atlas-mpls-te-express-path
> 
> Xiaohu, Sri, Rajiv and Pranjal,
> 
> You have been selected as an MPLS Review team reviewers for
> draft-atlas-mpls-te-express-path-02.
> 
> Note to authors: You have been CC'd on this email so that you can know
> that this review is going on. However, please do not review your own
> document.
> 
> Reviews should comment on whether the document is coherent, is it
> useful (ie, is it likely to be actually useful in operational
> networks), and is the document technically sound?  We are interested
> in knowing whether the document is ready to be considered for WG
> adoption (ie, it doesn't have to be perfect at this point, but should be
> a good start).
> 
> Reviews should be sent to the document authors, WG co-chairs and
> WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
> may be sent privately to only the WG chairs.
> 
> Are you able to review this draft by April 20, 2013?
> 
> Thanks, Loa
> (as MPLS WG chair)
> 
> /Loa
> --
> 
> 
> Loa Andersson                        email: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 11 Apr 2013 06:49:39 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Xuxiaohu
> 发送时间: 2013年4月10日 12:17
> 收件人: Loa Andersson; Dutta, Pranjal K (Pranjal); Sriganesh Kini; Rajiv Asati
> (rajiva); [email-masked];
> [email-masked]; [email-masked]
> 主题: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path
> 
> Hi all,
> 
>    Comment: According to an above statement of " an end-to-end latency
> bound merely requires that the path computed be no more than that bound
> without being the minimum ", it seems that latency is not used as a metric for
> SPF algorithm but only used as a constraint. If so, how do you decide which
> specific link(s) of the first-round calculated SPF path should be pruned prior to
> executing the second-round SPF calculation?  The same question exists when
> considering end-to-end packet loss ratio and latency variation bounds. The
> example illustrated in the draft seems not clear to me. Would any co-author
> please clarify the above doubt?

Here I meant when the first-round calculated SPF path with existing constraints (e.g., bandwidth, resource color etc) being met can't meet the end-to-end latency bound constraint, how do you decide which specific link(s) of that first-round calculated SPF path should be pruned prior to
executing the second-round SPF calculation? In other words, it would be very hard to use a cumulated value of a given type of link metric (e.g., end to end path latency, end to end latency variation) as a constraint for the CSPF algorithm, IMHO.

Best regards,
Xiaohu

>    Comment: I guess co-authors wanted to say packet loss ratio here. If so,
> the formula of packet loss ratio here needs to be correctly expressed.
> 
>    Comment: I wonder whether it is suitable to consider Residual Bandwidth
> and Unidirectional Available Bandwidth parameters as performance metrics
> and therefore discuss them in this doc. Furthermore, whether or not the
> measured bandwidth used for the actual forwarding of non-
>    RSVP-TE LSP packets should be a constraint for CSPF depends on many
> factors, such as whether or not this bandwidth can be occupied by future
> RSVP-TE LSP traffic. Hence, maybe it's more suitable to discuss in details the
> bandwidth constraint related issues in a separate doc.
> 
> Best regards,
> Xiaohu
> 
> 
> > -----邮件原件-----
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 22 Apr 2013 08:32:06 +0000

Hello Loa,

Overall I think the document is addressing a useful problem but needs an
update to make it more coherent and sound before going to WG acceptance
call.

My comments are listed below -

1. The filename "mpls-te-express-path" has no correlation to the title and
content of the draft. I would suggest a more appropriate filename such as
"mpls-te-path-selection-mechanism".

2. The "Short Title" should be changed to reflect that this is a path
selection mechanism. Suggest "Simple path selection mechanism".

3. Abstract last sentence is better worded as "This document specifies a
computationally simpler mechanism to select performance-constraint-bounded
paths by using performance data advertised via an IGP"

4. It is not clear why there is a dependence on the performance data being
advertised via IGP. Can't it come from other sources. E.g. a management
system ?

5. The limitations of the path computed due to the scope of link-state
advertisements should be stated. E.g. if the referenced docs for IGP
extensions have area scoped performance-data advertisements, then the
head-end may not be able to compute paths beyond the area.

6. Section 1.1 enum 3 - s/perforance/performance

7. Section 1.1 enum 4 suggest s/configuration/constraints

8. Section 2.1 - Need a reference for CSPF algorithm being referred to. It
may be of value to write an appendix that gives pseudocode on how the
constraint checking is inserted into the CSPF.

9. Section 2.1 - In the paragraph starting with "This is illustrated as
follows.". It may be useful to state that there are cases where all the
links of X when explored may violate the bounded constraint the algorithm
should backtrack from the point where the bounded constraint was still
being satisfied.

10. Sec 2.3.3 - Is this an optimization of when to re-optimize ? Because
any link coming out of Anomalous may provide a better path, not just a
link that caused LSPs to change when it went to the Anomalous state. If
so, it may be useful to state it.

Also this document should be posted to the PCE WG for comments.

Thanks
-- Sri