I understand the reason to keep Item 3 as "MUST". But I still think that Item 2 should be "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 ?
> > > > > >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.
The solution SHOULD provide mechanism(s) to reduce (but not eliminate altogether) path suboptimality over the life-time of the LSP.
Thanks Raymond
Yakov.