Yakov, Are you saying inter-area OSPF TE is not required?
Without the inter-area OSPF TE, the non-backbone areas of an OPPF AS boil down to being *stub areas* and the backbone area becomes the only area. The round-robin ABR based trial-and-error CSPF computations can take inordinate amounts of time for LSP convergence. As LSPs are setup, TE network reachability changes. Without the inter-area OSPF TE, nodes are blind to TE reachability outside the area. Not offering inter-area OSPF TE, I believe, is a disservice to customers who need predictability. Same goes with the flooding and other limitations imposed on mixed networks. Lack of a requirements document for OSPF TE is clearly the cause of this debate. It may not be too late to work on one. Borrowing Keith's words, it sounds like we have a group of people insisting on adopting the "one solution" without significant change - treating it as inviolate rather than as a proof of concept. regards, suresh > -----Original Message----- > From: Yakov Rekhter [mailto:[EMAIL PROTECTED]] > Sent: Sunday, December 22, 2002 6:29 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 > to Proposed Standard > > > Suresh, > > > > > 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. > > > > > > As I said in my previous e-mail 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. That is precisely > > > while quite a few scenarios in the "Multi-area MPLS Traffic > Engineering" > > > draft do not require any additions to what is already defined > > > in the katz-yeung draft. > > > > > > Yakov. > > > > Yakov, > > > > Yes, quite a few scenarios described in > kompella-mpls-multiarea-te draft > > are supported with single-area TE extensions and do not require any > > additions. And, katz-yeung draft proposal will suffice for single-area > > TE extensions. > > Good. So we are in agreement that the katz-yeung draft can support > both single area and multi-area TE. > > > katz-yeung draft does not cover dissemination of inter-area TE info > > (which I was refering to as *inter-area OSPF-TE*). Neither does the > > draft claim to do so. > > That is correct too. > > > Inter-area OSPF-TE is a scenario described in > > kompella-mpls-multiarea-te for faster convergence in LSP computation. > > I am not sure which scenario you are referring to. But anyway, this > is outside the scope of the present discussion... > > > In this context - my recommendation to not use katz-yeung draft as the > > basis to extend to inter-area OSPF-TE was because of its scaling > > limitation. > > And my recommendation is exactly the opposite - start multi-area TE > with what is already in the katz-yeung draft, gain some operational > experience with it, and then improve this, *if necessary*, based on > the experience. But anyway, this is outside the scope of the present > discussion... > > > Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed > > networks. katz-yeung draft has limitations with flooding disruption > > and topology isolation in a mixed network - both intra-area and > > inter-area. This was another reason why I recommended to not use > > katz-yeung draft as the basis to extend to inter-area OSPF-TE. > > To avoid any confusion I would suggest to add the following to > the katz-yeung draft: > > It is an explicit non-goal of the solution described in this > document to address all possible (as well as impossible) > requirements. Therefore, the solution described in this document > is clearly not a perfect solution, and as such doesn't quality > for being a LTSFGTC (Long Term Solution For Generations To Come). > Work on the perfect solution (aka LTSFGTC) is in progress, and is > expected to be published in RFC100000. > > Yakov.
