On Wed, 18 Dec 2002, Pyda Srisuresh wrote:
...
Hence, a statement of applicability and limitations is
warranted in the draft.
Let me be more precise: draft-katz-yeung says how TE in a single OSPF
area can be accomplished. It doesn't aim to address the multi-area
case; *nor does it say that it cannot do so*; *nor should it do so*.
There is work going on to address multi-area TE *that builds on this
draft*. In spite of your "recommendations", this multi-area work
building on draft-katz-yeung has a lot of traction. I therefore have
no intentions of putting in incorrect or incomplete limitations.
...
Kireeti - I am aware of RFC 2702 and have reviewed it.
The RFC is about requirements and applications of TE over MPLS.
The RFC is *not* about requirements for the IGP collecting
TE metrics within an Autonomous System(AS). I was refering
to the latter.
draft-katz-yeung is *not* about collecting TE metrics. It's about
providing a topological database that can be used for routing traffic
trunks; the parameters that are carried in this database are those
whose semantics and applicability are described in RFC 2702.
...
The whole crux of my comments has been on scaling and applicability
limitations.
Large OSPF networks with multiple areas will not
run this protocol.
Crystal ball? I suggest you get a new one.
READ - This protocol is restricted in scope to a single area.
I beg to differ -- see above.
In response to your comments, I will add the following statement
at the end of the second para in the Introduction:
"This document purposely does not say how the mechanisms described
here can be used for traffic engineering across multiple OSPF areas;
that task is left to future documents."
Kireeti.