Subject: Re: [mpls] MPLS-RT review of draft-tsaad-mpls-p2mp-loose-path-reopt

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Mon, 2 Jun 2014 12:38:36 +0000

Hi Sri,

Thanks for the review and comments. Please find responses inline.

On 2014-05-19, 6:10 PM, "Sriganesh Kini" <[email-masked]>
wrote:

>Hello,
>
>Some review comments are below. Overall, the draft is addressing a
>useful-problem but is not coherent. I think the problem statement has to
>be clearly defined and terminology fixed before the draft proceeds to WG
>acceptance call.
>
>
>1. Abstract should state that the specific limitation being addressed is
>one of tree-optimization as opposed to the individual sub-LSP
>re-optimization that is already defined.
[TS]: will revise to:
"For a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched
Path (LSP), it is preferable in some cases to re-evaluate and reoptimize
the entire P2MP-TE LSP by resignaling all its S2L sub-LSP(s). Existing
mechanisms allow the path re-evaluation and the signalling of a the
notification of preferred path exists for a single S2L sub-LSP only.

This document defines RSVP-TE signaling extensions to allow an ingress
Label Switching Router (LSR) of a P2MP-TE LSP to trigger the re-evaluation
of the entire LSP tree containing one ore more S2L sub-LSPs whose paths
are loose (or abstract) hop expanded, and for a midpoint LSR to signal to
the ingress LSR that a better tree exists for the entire P2MP-TE LSP."

>
>2. The "egress border" node used in Pg-3 bullet-1 should be defined. I am
>assuming you intended to say mid-point LSR of RFC 4736 ?
[TS]: correct. Will change.

>
>3. Pg-3 last para. RFC 4736 states that reoptimization is for a preferable
>path i.e. shorter path. This should be re-defined for a P2MP LSP so that
>the notion of preferable is clear. This is critical to define the problem
>statement.
[TS]: the definition of “preferable” or optimal is local function/policy
to the (mid-point) path expanding LSR. IMO, should remain beyond the scope
of this draft. Even RFC4736 mentions “shorter path” as an “example" of
more preferable path. The proposed extensions in this draft are limited to
procedures to trigger/relay/response of the request/notify of a better
p2mp tree availability.

>
>4. Pg-4 bullet-1.  What is the 'query' being referred to here? Is it path
>re-evaluation request ?
[TS]: yes, this will be replaced by trigger "a re-evaluation request”.

>
>5. Pg-4 sec 1. A figure to illustrate the problems would be very useful.
>
>6. Pg-5 section-3 last para. "...re-evaluating loosely expanded paths of
>all S2L sub-LSP(s)...". Shouldn't the PathErr be sent even if a single S2L
>sub-LSP can be re-optimized. Why should 'all' be re-evaluated ?
[TS]: An example is when computing the P2MP minimum cost tree (MCT)― as
opposed to the tree of Shortest Paths (SP)s. The former, attempts to
minimize the cost of the tree to reach “all” destinations, while the
latter minimizes the cost of a path to a single destination ― from each
independent of the tree cost.

>
>7. Do the procedures in this draft guarantee 'global optimization' ?
[TS]: Not necessarily, especially given the mid-point LSR has area local
topology visibility only. Again, I believe this is to be kept beyond the
scope of the draft.

Regards,
Tarek

>
>
>
>Thanks
>Sri
>
>
>On 4/22/14 6:45 AM, "Loa Andersson" <[email-masked]> wrote:
>
>>All,
>>
>>I was to conservative sending this out, authors, co-chairs and
>>wg secretary should have been copied.
>>
>>/Loa
>>
>>On 2014-04-22 14:51, Loa Andersson wrote:
>>> Curtis, Xiaohu, Sri, Thomas,
>>>
>>> You have been selected as an MPLS Review team reviewers for
>>> draft-tsaad-mpls-p2mp-loose-path-reopt.
>>>
>>> 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
>>> 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 May 7, 2014?
>>>
>>> Thanks, Loa
>>> (as MPLS WG chair)
>>>
>>>
>>
>>-- 
>>
>>
>>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