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:yakov(_at_)juniper(_dot_)net]
Sent: Sunday, December 22, 2002 6:29 AM
To: srisuresh(_at_)yahoo(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org
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.