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

[Xuxiaohu <[e-mail]>]

> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]] 代表
> Xuxiaohu
> 发送时间: 2013年4月10日 12:17
> 收件人: Loa Andersson; Dutta, Pranjal K (Pranjal); Sriganesh Kini; Rajiv Asati
> (rajiva); [e-mail];
> [e-mail]; [e-mail]
> 主题: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path
> 
> 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?

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

> 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]
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls