Re: comments on draft-kompella-mpls-multiarea-te-02.txt

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Francois,

Thanks for your comments. See in line,

At 12:21 19/11/2001 +0100, Francois Le Faucheur wrote:
>Kireeti, Yakov, Jean-Philippe,
>
>
>A few suggestions on the Multi-Area TE draft for your consideration:
>
>Independent per-area TE
>=======================
>The draft currently restricts its scope of multiple-area TE to only those 
>scenarios using LSPs that span multiple areas.

yes the idea is to specifically address the inter-area TE case.

>Some SPs have/will deploy TE in multiple areas simply by running TE 
>independently in each area. Although, this does not really require any 
>specific new mechanisms, it is a valid scenario for doing TE in multi-area 
>environments. So my suggestion would be to slightly broaden the scope of 
>the draft (ie to not deliberately restrict it to the scenarios using 
>inter-area LSPs) and include a section on the multiarea TE scenario where 
>only intra-area LSPs are used.
>You could then clarify that no new mechanisms are required for this (only 
>require that routers at boundary may have to keep TED from two areas).
>I think it would also be useful to highlight a few properties of such a 
>deployment scenario (scalability/achieves kind of a natural "hierarchy" in 
>the sense that you keep a small number of tunnels in the backbone area and 
>packets from many leaf-area tunnels get aggregated into core-area tunnels, 
>dynamic routing onto tunnels at Head-ends is somewhat simpler since 
>Head-end IGP "sees" tail-end in its intra-area IGP Database, does not 
>allow end-to-end control of smaller traffic trunks ie two traffic trunks 
>from two head-end areas going to same tail-end cannot be "routed" 
>separately in backbone area or tail-end area...).
>

fair comment.

>Reoptimisation
>==============
>Since you discuss how "optimal" is the routing for each scenario of 
>section 4, I'd suggest a clarifying statement that handling reoptimisation 
>on a per-area basis does not allow "globally optimum" reoptimisation.

or this may even not be locally optimum (as with rerouting with crankback). 
Performing rerouting/reoptimization on the ABR (so on a per area basis) may 
or not be more optimal than head-end rerouting/reoptimization. So moreover, 
as you said, this cannot be globally optimum.

>I would also suggest adding a statement making it explicit that other 
>methods of reoptimisation are possible which may reuse the mechanisms 
>described earlier for initial path computation (e.g. Path Computation server).

True. That's what we meant by "Periodic (time-driven) reoptimization is 
performed by the head-end LSR" but ok we should make it more explicit, thanks.

In this case, the LSR needs to signal the already in place TE LSP for the 
PCS not to perform double counting. 
draft-vasseur-mpls-computation-rsvp-01.txt (to be published shortly) allows 
this.


>Vocab
>=====
>in section 3, you clarify that you will be using OSPF terminology  to 
>dicuss both OSPF and ISIS. You mention "backbone area" as one such term. 
>You may want to mention ABR as another.

ok

>Typos/Editos
>=============
>         - 4.2: 2nd paragraph., last sentence. "LSR setup" should read 
> "LSP setup".
>         - 4.3: 2nd paragraph, 1st sentence . "in the tail-end area the 
> head-end area)" should read  " in the tail-end area"
>         - 4.4: paragraph 5 and 7 say the same thing and should be combined.

Thanks !

JP.

>Hope this is useful
>
>Francois