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.
