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

Hi Yakov,


At 11:42 AM 1/12/2004 -0800, Yakov Rekhter wrote:
>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.

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

Cheers,
Raymond
>
> > >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.