resending... My apologies, if you receive two copies of this. I believe, the orginal e-mail did reach the ietf list. Thanks. regards, suresh -----Original Message----- From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] Sent: Friday, December 13, 2002 11:13 AM To: ietf@ietf.org Cc: Pyda Srisuresh; iesg@ietf.org Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard 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. Below are my specific comments on the draft. 1. The draft basically describes link TLVs for area-wide flooding. OSPF is an AS-wide IGP, not just area-wide. So, I would suggest renaming the draft as "TE extensions to an OSPFv2 area", instead of the current title, "TE extensions to OSPFV2". Large OSPF networks with multiple areas will not run this protocol. 2. It is confusing to refer an opaque LSA with with a specific sub-type as "TE LSA". It makes it sound like a stand-alone OSPF LSA with a distinct LSA type - which is is not. OSPF LSAs define the flooding scope. TE LSA does not. One suggestion would be to refer Opaque LSAs with specific sub-type 1 as "TE-type Opaque LSA". 3. The limitations section (section 1.2) should mention the following limiations with a mixed network containing TE and non-TE nodes. 1. When a network area is constituted of TE and native-nodes (supporting IP-only links), the opaque LSAs will flood all nodes in the area, thereby disrupting native OSPF nodes. As As a general rule, a TE network is likely to generate significantly more control traffic than a native OSPF network. The excess traffic is almost directly proportional to the rate at which TE circuits are set up and torn down within the TE network. The more frequent and wider the flooding frequency, the larger the number of retransmissions and Acks. It is undesirable to flood non-TE nodes with TE TLVs. 2. A link cannot be reserved for TE-only use. All links must be subjectable to best-effort IP traffic first, before any of the links are permitted to carry TE traffic. In a mixed network, an OSPF router supporting TE-links and native IP-links could potentially select a TE link to be its least cost link and inundate the link with best-effort IP traffic, thereby rendering the link unusable for TE purposes. regards, suresh -----Original Message----- From: Mailing List [mailto:OSPF@DISCUSS.MICROSOFT.COM]On Behalf Of The IESG Sent: Monday, November 25, 2002 3:47 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard The IESG has received a request from the Open Shortest Path First IGP Working Group to consider Traffic Engineering Extensions to OSPF Version 2 <draft-katz-yeung-ospf-traffic-09.txt> as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by December 26, 2002 Files can be obtained via http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt