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

[Xuxiaohu <[e-mail]>]

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:[e-mail]]
> 发送时间: 2013年4月6日 12:51
> 收件人: Dutta, Pranjal K (Pranjal); Sriganesh Kini; Rajiv Asati (rajiva); Xuxiaohu;
> [e-mail]; [e-mail]
> 主题: 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: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]