Re: Fwd: I-D ACTION:draft-ietf-tewg-interas-mpls-te-req-03.txt

Hi Yakov,

Thanks for the additional input...

At 08:28 AM 1/12/2004 -0800, Yakov Rekhter wrote:
>Raymond,
>
> > Hi Jim and Ed,
> >
> > Happy new year !
> >
> > The following emails were sent to both of you nearly a month ago.  I am 
> not
> > sure if you are having problem receiving email again so I am copying Bert
> > and posting to the list also.
> >
> > The -03 version of the draft
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-tewg-interas-mpls-te-req-03.t
>xt)
> > is ready for last call as per our minutes from the Minneapolis meeting.
>
>I think that the latest version of the draft still require few
>changes/updates.
>
>1. The document should state up front the following:
>
>       This document doesn't make any claims with respect to whether
>       it is possible to have a practical solution that meets all the
>       requirements listed in this document.
>
>(That point have been discussed before, and I thought the authors
>agreed to include the above in the text, but I wasn't able to find
>it in the -03 version).

In section 6.1, I included wording "

If a solution can fulfill just a subset of those requirements in
    section 5, then it MUST be explicitly documented"

Would this reflect your point above ?


>2. From 5.1.5 ("Re-optimization"):
>
>    Once an inter-AS TE LSP has been established and should there be any
>    resource or other changes inside anyone of transiting ASes, the
>    solution MUST be able to re-optimize the LSP accordingly and
>    non-disruptively, either upon expiration of a configurable timer or
>    triggered by a network event or a manual request at the TE tunnel
>    Head-end.
>
>    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.
>
>The above it too restrictive, as it restricts re-optimization to
>only the case where resource changes are in the set of ASs (currently)
>transited by the LSP. To remove this restriction I'd like to propose the
>following replacement:
>
>    Once an inter-AS TE LSP has been established and should there be any
>    resource or other changes inside anyone of the ASes, the
>    solution MUST be able to re-optimize the LSP accordingly and
>    non-disruptively, either upon expiration of a configurable timer or
>    triggered by a network event or a manual request at the TE tunnel
>    Head-end.
>
>    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 ASes.

"along the inter-AS TE LSP path" was left there by mistake, sorry...  As 
per our last discussion, the text should appear exactly the same as you 
proposed above.  Thanks for catching it !

>3. Section 6.2 ("Performance") should include control plane overhead
>as one of the criteria. Ditto for data plane overhead.

Will do, thanks.

>4. In 5.1.6 replace "CSPF" with "Path computation").

You meant 5.1.8 ?  Will do...

Cheers,
Raymond
>Yakov.