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

Hi Yakov,


At 07:04 AM 1/20/2004 -0800, Yakov Rekhter wrote:
>Raymond,
>
> > Hi Yakov,
> >
> >
> > At 12:59 PM 1/19/2004 -0800, Yakov Rekhter wrote:
> > >Raymond,
> > >
> > > > Hi Jim and Ed,
> > > >
> > > > Here is the most updated one.  Would you please initiate the WG 
> last call
> > > > for this draft ?
> > >
> > >This draft still doesn't include some of the changes you agreed to make
> > >in your e-mail on Jan 12 (the e-mail is attached).
> > >
> > >Specifically, it doesn't include the changes you agreed to make
> > >to 5.1.5, and it didn't list forwarding plane overhead in the
> > >list of criteria in 6.2.
> >
> > [snip..]
> > > >3. Section 6.2 ("Performance") should include control plane overhead
> > > >as one of the criteria. Ditto for data plane overhead.
> > >
> > >Will do, thanks.
> > [snip..]
> >
> > I see... I interpreted "ditto" as "ok" above, meaning no additional 
> changes
> > required regarding data plane.
> >
> > Can you propose some wording which can be incorporated into the final
> > version after the last call commenting period ?
>
>Here is the proposed text, although I think that the text has to be
>incorporated *prior* (and not after) the last call commenting period.

Surely.. I will post -05 for it.

>In  5.1.5 replace
>     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.

This was the text in -03...  In -04, I have updated the text to the following:

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


>with the following:
>
>     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.

But I have not problem with proposed above either (one word difference 
"transit as")

>In 6.2 add the following:
>
>     - Impact and scalability of the data/forwarding plane due to added
>         overheads, etc.

thanks !

Cheers,
Raymond

>Yakov.