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

[Yakov Rekhter <yakov@juniper.net>]

Raymond,

>  > > > >    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 SHOU
LD
> > > > > 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-A
S
> > > 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.

I still don't quite understand what it adds...

> > > 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 su
ch
> > > > > > > >a path), then the requirement has to be very explicit with respe
ct
> > > > > > > >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 optima
l
> > > > > > > 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 whethe
r
> > > > > > > path optimality should be maintained  "all the time"  or triggere
d
> > > > > > > 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 case
s
> > > > > it is also a matter of tuning trade-offs between optimality and netwo
rk
> > > > > 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 ?

Ok.

Yakov.

> 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.
> 
>