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

From: Alia Atlas <[email-masked]>
Date: Tue, 9 Jul 2013 12:42:07 -0400

Hi Xuxiaohu,

I apologize for the long delay in responding.

On Wed, Apr 10, 2013 at 12:17 AM, Xuxiaohu <[email-masked]> 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:[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
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 9 Jul 2013 12:50:05 -0400

Please see in-line

On Thu, Apr 11, 2013 at 2:49 AM, Xuxiaohu <[email-masked]> wrote:
<cut>

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

So your concern is what constraint to relax if a path can't be found?  I
don't think that is something that needs to be standardized...  It depends
on what you want to trade-off for the various constraints.  I can easily
see storing the lowest latency over the latency bound that was seen - or
other techniques.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 9 Jul 2013 13:45:52 -0400

Hi Sri,

I apologize for the delay in responding.

On Mon, Apr 22, 2013 at 4:32 AM, Sriganesh Kini <[email-masked]
> wrote:

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

This draft is connected to a set of work that was originally termed TE
Express Path for the ability to create "express" or low-latency LSPs.   The
OSPF and IS-IS related work has been renamed.  I'd be happy to rename this
if/when it becomes a working group draft. I would prefer
mpls-te-path-selection-metric-extensions (or something even shorter!)

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

Changed to "Path Selection with TE Metric Extensions"

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

Changed to:
"This specification uses network performance data, such
as is advertised via the OSPF and ISIS TE metric extensions (defined
outside the scope of this document) to perform such path selections."

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

Yes - as long as we confine the computation to the ingress, network-wide
consistency isn't required.
I've updated the second sentence in the introduction to be:

"Network performance information
can be obtained via either the TE Metric Extensions in OSPF <xref
target="I-D.ietf-ospf-te-metric-extensions"/> or ISIS <xref
target="I-D.previdi-isis-te-metric-extensions"/> or via 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.
>

This is the same as everything else advertised about TE via the IGP...  Why
does it need to
be especially called out?

Added

" As with other TE information flooded via OSPF or ISIS, the TE
metric extensions have a flooding scope limited to the local area or level."

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

I added some pseudo-code (see email response to Xiaohu).
Do you have a suitable reference for a CSPF algorithm?  There has been no
need
to standardize it.

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

Please do read the new pseudo-code and example.  The link is not explored
if it
will violate the bounded constraint - that's the point of the modified
exploration.

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

Sure - any link changing state might provide better paths - but those that
were specifically moved away
are more likely to want to move back.

I added "This may help optimize when to recompute for a better path."

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

I'm happy to have their comments as well - but I don't think it really
applies for PCE.
In a PCE scenario, computation is not as much a concern and better
algorithms can be used.

Thanks,
Alia

>
>
> Thanks
> -- Sri
>
>
>
>
>
>
> On 4/5/13 9:50 PM, "Loa Andersson" <[email-masked]> wrote:
>