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(_at_)yahoo(_dot_)com]
Sent: Friday, December 13, 2002 11:13 AM
To: ietf(_at_)ietf(_dot_)org
Cc: Pyda Srisuresh; iesg(_at_)ietf(_dot_)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(_at_)DISCUSS(_dot_)MICROSOFT(_dot_)COM]On
Behalf Of The
IESG
Sent: Monday, November 25, 2002 3:47 PM
To: OSPF(_at_)DISCUSS(_dot_)MICROSOFT(_dot_)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(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)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