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

[Yakov Rekhter <yakov@juniper.net>]

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

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.

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

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

Yakov.