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

[Yakov Rekhter <yakov@juniper.net>]

Raymond,

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

Thanks !!! 

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

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

Yakov.