Raymond,
> Hi Yakov,
>
> Thanks for the additional input...
welcome !
> 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 ?
No, I don't think this is sufficient. I really like to have the
sentence I suggested up front in the document.
> >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 !
welcome !
>
> >3. Section 6.2 ("Performance") should include control plane overhead
> >as one of the criteria. Ditto for data plane overhead.
>
> Will do, thanks.
Ok.
> >4. In 5.1.6 replace "CSPF" with "Path computation").
>
> You meant 5.1.8 ?
Yes.
> Will do...
Thanks !!!
Yakov.