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

[Alia Atlas <[e-mail]>]

Hi Sri,

I apologize for the delay in responding.

On Mon, Apr 22, 2013 at 4:32 AM, Sriganesh Kini <[e-mail]
> 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" <[e-mail]> wrote:
>
> >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
>