<... snip> > > > Please look at draft-kompella-mpls-multiarea-te-03.txt, as > > > at least some of the approaches described in that draft > > > do *not* assume additive properties of TE metrics (and do not > > > advertise summary info). > > > > > > Yakov. > > > > Yakov - You are right. The draft does talk about different > > mechanisms the MPLS signaling protocols could use to setup > > LSPs in an AS spanning multiple areas. However, the draft is > > not about inter-area OSPF TE. > > The draft is about multi-area TE, as it describes how to solve > the problem of supporting TE in a multi-area environment. > OK.
> > Clearly, there is interplay between signalling protocols and > > the extent of TE link state data base (TE-LSDB) a node has. > > I believe, scenario-3 is where the inter-area OSPF-TE is in > > place and all nodes in an area have the same information as > > their ABRs do. This scenario presents the signalling protocols > > with fast convergence in settign up an LSP, right. > > Just to point out that quite a few scenarios described in > draft-kompella-mpls-multiarea-te-03.txt are supported with the TE > extensions that are subject to this Last Call. To repeat what > Kireeti said already "There is work going on to address multi-area > TE *that builds on this draft*." > Yakov - My comment on the katz-yeung draft concerning multi-area is that it supports TE in a single OSPF area; and hence to rename the draft as "TE extensions to an OSPFv2 area". My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the "Multi-area MPLS Traffic Enginering" draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. > Yakov. regards, suresh
