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

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 Jan 2004 08:28:56 -0800

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.

---

From: raymond zhang <[email-masked]>
Date: Mon, 12 Jan 2004 09:23:41 -0800

Hi Yakov,

Thanks for the additional input...

>agreed to include the above in the text, but I wasn't able to find

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 ?

>    control if re-optimizing or not should there exist a more optimal

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

>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

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 Jan 2004 11:42:58 -0800

Raymond,

> Thanks for the additional input...

welcome !

No, I don't think this is sufficient. I really like to have the
sentence I suggested up front in the document.
  
> proposed above.  Thanks for catching it !

welcome !

> >as one of the criteria. Ditto for data plane overhead.

Ok.

> You meant 5.1.8 ?  

Yes.

> Will do...

Thanks !!!

Yakov.

---

From: raymond zhang <[email-masked]>
Date: Mon, 12 Jan 2004 16:29:23 -0800

Hi Yakov,

At 11:42 AM 1/12/2004 -0800, Yakov Rekhter wrote:
> > > > The following emails were sent to both of you nearly a month 
> ago.  I am
> > > not

Ok, no problem. I will add it in the intro section.

Cheers,
Raymond

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 12 Jan 2004 17:20:04 -0800

Raymond,

[clipped...]

> Ok, no problem. I will add it in the intro section.

Thanks !!! Looking forward for the 04 version.

Yakov.