Rohit, My comments were made solely in reference to the draft-katz-yeung draft; not in comparison to any specific draft, as you might believe. As for the comment from John Moy (circa July 2001) about the availability of an inter-area OSPF draft, I do recall responding that the inter-area draft was assuming additive properties to TE metrics to advertise summary info. It is a mistake to assume that all TE metrics can be additive. Below is a pointer to the response I sent. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&T=0&F=&S=&; P=5937 This goes right back to the comment I made below about using the draft-katz-yeung draft as the basis for inter-area TE. regards, suresh -----Original Message----- From: Rohit Dube [mailto:rohit@xebeo.com] Sent: Tuesday, December 17, 2002 11:46 AM To: srisuresh@yahoo.com Cc: ietf@ietf.org; iesg@ietf.org; zinin@psg.com; fenner@research.att.com; acee@redback.com Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard Suresh, You have brought up this issue on the ospf mailing list a couple of times and as such the topic has been addressed on the list. Here is pointer to an email from John Moy (circa July 2001) http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0107&L=OSPF&D=0&I=-3&P =15162 and another more recent one from me in response to your email on your alternate-te proposal http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0212&L=OSPF&D=0&I=-3&P =6031 Best, --rohit. (OSPF WG co-chair) ::The draft is a solution to providing TE within an OSPF area. ::The draft has serious scalability limitations in ::extending this to inter-area and mixed networks (with TE and ::non-TE nodes). Please see my comments below. I would not ::recommend using this draft as the basis for building further ::TE-extensions to inter-area and mixed networks. :: ::The draft apparently evolved over time with no requirements ::document to guide it. The vendors and implementors behind the ::draft may have been guided by different set of requirements ::and motivations, such as having some working code. Unfortunately, ::this ad-hoc approach has a cost. Any new requirements are having ::to be met in a reactive mode and having to be provided as fixes ::on top of this "working" code. This is not right and doesnt bode ::well for the future of the protocol. [snip]