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

Hi Yakov,

>I understand the reason to keep Item 3 as "MUST". But I still
>think that Item 2 should be "SHOULD".

Ok since there are only some SPs who have multi-ASes.  So I will change 
item 2 to "SHOULD".

> > >
> > >    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 between
> > >    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.
So it is much better to make things explicit this way.

> > > > > > >3. In Section 5.1.3 the document needs to explicitly state whether
> > > > > > >it is a requirement to maintain optimal path all the time, and if
> > > > > > >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 corresponded
> > > > 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.

Thanks
Raymond

>Yakov.