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

[Yakov Rekhter <yakov@juniper.net>]

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.

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.

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.

In 6.2 add the following:

    - Impact and scalability of the data/forwarding plane due to added
        overheads, etc.

Yakov.