> -----Original Message----- > From: Kireeti Kompella [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 3:37 PM > To: Pyda Srisuresh > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 > to Proposed Standard > > > 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 - You apparantly have an attitude and it shows. Outside of your attitude, you have not said anything in your defence. All my comments including those on limitations remain unanswered. > > > 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." > This is *not* what I stated in my comments and is *not* a characterization of my commnents. I gave backing for all the comments I made. I am sorry to say you did little on your part, other than come back with an attitude. > Kireeti. regards, suresh
