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

[Yakov Rekhter <yakov@juniper.net>]

Raymond,

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

Great !!!

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

Looking forward for the -05 version.

Yakov.