Re: few comments on draft-ietf-tewg-interas-mpls-te-req-01.txt

Hi Yakov,

 > > > >    The solution SHOULD provide an option for the Head-End LSRs to 
contr
>ol
> > > > >    if re-optimizing or not should there exist a more optimal path 
> betwe
>en
> > > > >    the Head-End and the Tail-End LSRs.
> > > >
> > > > Good point on the option of traversing the same path...   So we 
> will make
> > > > our original point as a
> > > > special case to your proposed wording above by adding the following:
> > > >
> > > > "In the case of an identical set of traversed path, the solution SHOULD
> > > > provide an option for the Head-End LSRs to control if
> > > > re-optimizing or not should there exist a more optimal path in one 
> of the
> > > > transit ASes along the inter-AS TE LSP path."
> > >
> > >Why do you need this "special case" ? In other words, why the text I
> > >proposed is not enough ?
> >
> > Well, in your proposed text, it is not specified if this HE LSR/TE LSP is
> > the HE/TE of the inter-AS LSP or just
> > a segment of the inter-AS LSP.  Our requirement is to have the HE LSR of
> > the inter-AS TE LSP, not just the mid point LSR of
> > segment LSP to have the control if re-opt or not in the case that inter-AS
> > TE LSP needs to traverse along the same AS path.
>
>Are you saying that your requirement applies only when the new and the
>old path traverse the same set of ASs ?

Oh no,,, this is just one of the applicable cases.

> > So it is much better to make things explicit this way.
> >
> > > > > > > > >3. In Section 5.1.3 the document needs to explicitly state 
> wheth
>er
> > > > > > > > >it is a requirement to maintain optimal path all the time, 
> and i
>f
> > > > > > > > >not then what percentage of overall path life time.
> > > > > > > >
> > > > > > > > Well, for some LSPs (not all, but some LSPs) it is 
> desirable to
> > > have
> > >a
> > > > > > > > solution being able to compute an optimal end to end path (a
> > > > > requirement
> > > > > > > > for SPs on the draft). The question of whether the TE LSPs 
> should
> > > > > > > always be
> > > > > > > > on the optimal is a question of implementation agreement and
> > > paramete
> > >r
> > > > > > > > setting. The requirement here is just that the solution must
> > > offer th
> > >e
> > > > > > > > possibility on compute an optimal path end to end (again by
> > > optimal w
> > >e
> > > > > > > > mean "shortest path").  Note this is a requirement listed as a
> > > > > "SHOULD".
> > > > > > >
> > > > > > >If the requirement here is to compute an optimal path end to end
> > > > > > >just for the sake of computation, then what are the practical
> > > > > > >benefits of such a requirement ?
> > > > > > >
> > > > > > >And if the requirement here is to compute an optimal path end to
> > > > > > >end for the sake of using it (means establishing an LSP along such
> > > > > > >a path), then the requirement has to be very explicit with respect
> > > > > > >to whether it expects path optimality to be maintained all the 
> time
> > > > > > >or not, and if not then what percentage of the time.
> > > > > >
> > > > > > This requirement is indeed for the ability to establish an optimal
> > > > > > path e2e for the inter-AS TE LSP ("using it").  For example, this
> > > > > > ability may be required for a SP with multiple ASes to be able to
> > > > > > deploy a set of meshed TE LSPs optimally across their own AS
> > > > > > boundaries and once established, it should be maintained at all
> > > > > > times.  However, in some cases it is also a matter of tuning,
> > > > > > trade-off between optimality and network stability, ... on whether
> > > > > > path optimality should be maintained  "all the time"  or triggered
> > > > > > after some timer has elapsed.  At the end, what we are actually
> > > > > > after in the req's draft is that a solution should offer this
> > > > > > capability of computing an optimal inter-AS TE LSP path 
> ("shortest")
> > > > > > end to end.
> > > > > >
> > > > > > Will have some additional wordings then to reflect what we 
> correspond
>ed
> > > > > > above. Your thoughts ?
> > > > >
> > > > >Please propose "some additional wording".
> > > >
> > > > Here it is...
> > > >
> > > > This requirement provides the ability for TE Head-end LSR to 
> compute and
> > > > establish an optimal end-to-end path for the inter-AS TE LSP. Once
> > > > established, it may be maintained at all times. However, in some cases
> > > > it is also a matter of tuning trade-offs between optimality and network
> > > > stability that SPs may elect to follow an optimal path, for example 
> only
> > > > when triggered after some timer has elapsed.
> > >
> > >How about the following:
> > >
> > >    Even if at the LSP's setup time path computation is optimal, the
> > >    path may not remain optimal for the life-time of the LSP. It is
> > >    a non-requirement to maintain path optimality all the time.
> >
> > This is basically the same as what I proposed above.
> >
> > >The
> > >    solution SHOULD provide mechanism(s) to reduce (but not eliminate
> > >    altogether) path suboptimality over the life-time of the LSP.
> >
> > I am afraid that I disagree here... "Reducing sub-optimality" is not the
> > same as the explicit requirement of "achieving e2e optimality". The
> > solution SHOULD provide mechanism(s) to compute and establish an optimal
> > end-to-end path for the inter-AS TE LSP.
>
>Ok. So how about the following:
>
>    The solution SHOULD provide mechanism(s) to compute and establish
>    an optimal end-to-end path for the inter-AS TE LSP. However,
>    even if at the LSP's setup time path computation is optimal, the
>    path may not remain optimal for the life-time of the LSP. It is
>    a non-requirement to maintain path optimality for the life-time
>    of an LSP. The solution SHOULD provide mechanism(s) to reduce (but
>    not eliminate altogether) path suboptimality over the life-time
>    of the LSP.

After giving some more thoughts on this, sorry but I think the text "It is 
a non-requirement to maintain path optimality for the life-time of an LSP." 
is too restrictive...   It may be a requirement to maintain path optimality 
at all times also in either inter-area or AS's case (for SPs with multi-ASs 
in their network).

How about the following with slight modification:

"The solution SHOULD provide mechanism(s) to compute and establish
an optimal end-to-end path for the inter-AS TE LSP and SHOULD also
allow for reduced suboptimality since the path may not remain optimal
for the life-time of the LSP "

This would then cover all of our concerns, yes ?

If so, I would like to post -03 to reflect what we've discussed up until 
now by this weekend so that I can get the last call process started...

Thanks once again for your input.
Raymond

>Yakov.