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

[raymond zhang <zhangr@info.net>]

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.