[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.