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

[Alia Atlas <[e-mail]>]

Hi Xuxiaohu,

I apologize for the long delay in responding.

On Wed, Apr 10, 2013 at 12:17 AM, Xuxiaohu <[e-mail]> wrote:

> 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?
>

I am not sure where the confusion lies.   This is known to be a heuristic
rather than an optimal algorithm, as is written.

I do not know what you precisely mean by a first-round calculated SPF vs. a
second-round SPF calculation.

I've added the following pseudo-code example:


  CSPF_with_bound(root, latency_bound)
    root.distance = 0
    root.latency = 0
    fibheap_insert(root, root.distance)
    while (fibheap_not_empty())
       next_rtr = fibheap_pop
       for each link next_link attached to next_rtr
          if (next_rtr.latency + next_link.latency) < latency_bound
              explore_link(next_rtr, next_link)

  Explore_Link(next_rtr, next_link)
    if (next_rtr.distance + next_link.metric) < next_link->neighbor.distance
       next_link->neighbor.distance = next_rtr.distance + next_link.metric
       next_link->neighbor.latency = next_rtr.latency + next_link.latency
    if (next_rtr.distance + next_link.metric) ==
next_link->neighbor.distance
       if (next_rtr.latency + next_link.latency) <
next_link->neighbor.latency
           next_link->neighbor.latency = next_rtr.latency +
next_link.latency




> 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.
>

This should have had 100 - in front of it - so basically
the path loss percentage is (100 - ((100 - loss_L1)*...(100 - loss_Ln))

(100 - loss_L1) is the traffic that makes it to link 2 (L2) and then (100 -
loss_L1)*(100 - loss_L2) is the traffic that makes it to L3 and so.
((100 - loss_L1) *... (100 - loss_Ln)) is the percentage of traffic that
makes it to the end of the path.


> 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.
>

Does more need to be said about this?  It's an ingress decision based on
configuration...

Thanks for the review!
Alia


>
> 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
>