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

[Yakov Rekhter <yakov@juniper.net>]

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.