Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Dave Katz (dkatzJUNIPER.NET)
Date: Thu Oct 11 2001 - 15:20:13 CDT
1. Given that the document clearly states that (a) this is
an extension using Opaque LSAs, and (b) this uses type 10
opaque LSA, which has area flooding scope, I would suggest
renaming the document to be something like - "Traffic Engg
extensions within a OSPF area using Opaque LSAs"
This is made clear when reading the spec; changing the title seems
like an unnecessary nit.
2. Section 1.1. Applicability - I agree with the statement in the
first paragraph, which states that the draft really is about
"Extended Link attributes" for traffic engineering. However, I
see this draft as covering two different items.
A) Description of extended Link attributes for TE using TLVs
(Section 2.5) and
B) Traffic engineering extensions within a OSPF area using
In my mind, Item A) is applicable to multiple approaches to
OSPF-TE - Item B) being one such application. Item B) is really
about Opaque LSA approach to flooding and what is mandated in
the Opaque LSAs.
As such, I think, it would be useful to split the draft into two
along the above lines.
Unnecessarily producing multiple documents is not helpful. If a
viable alternative to using Opaque LSAs gains sufficient support, it
could either include the TLV definitions by reference to this
document, or else it could be split at that time.
3. Section 1.1. - Applicability
I dont understand the text on "global traffic engineering".
How can this do global TE, when the TE data is limited to an
This spec does not purport to do global traffic engineering; it simply
states that building a TE database can operate in support of global
traffic engineering, by building on this technology.
4. Section 1.2 - Limitations. I believe, the document should state
the following limitations.
a) The LSDB model can be detrimental to TE-link SLA enforcing.
This is because the approach is based on a native OSPF-LSDB
to which all links belong and an Opaque-LSDB to which only
the TE links belong. I am not aware of a case where a link
can be a pure-TE link with no native-IP traffic allowed on it.
When TE and native topologies are not separated (as is the
case with Opaque LSAs), an OSPF node could be utilizing
a TE link as its least-cost link, thereby rendering the TE link
ineffective for SLA enforcement.
b) The Opaque LSDB does not reflect the TE capabilities of routers.
It can only synthesize based on TE link attachment, whether a
router is TE capable or not. The document does not address
subteleties of distinction between TE routers (such as TE
selection criteria supported by the router, LSR/LER capability,
MPLS signaling capability etc.)
c) Flooding topology limitation: The flooding of the TE LSAs is
not limited to TE routers alone. FLooding of TE LSAs is extended
to all routers within the area. This can be a significant problem
in a network where TE and non-TE nodes co-exist. This is especially
the case when the TE circuit paths are constantly in flux.
d) TE Link attributes are limited to that of packet networks and
packet based links only. Not sure whether this shoudl go into
section 1.1. or 1.2. Either section would probably suffice.
The spec does what it does. The above issues should be abundantly
obvious to the informed reader; we should not feel as though it is
necessary to list all things that a spec does not support (there are,
after all, an infinite number of such things.)
It is clear that you feel strongly that these issues are important
enough to have proffered an alternative proposal in the past; if
these issues turn out to be operationally important to those deploying
this technology, then I'm quite sure that your proposal will receive
the attention it deserves.
5. Section 2.4.2 - Replace "Cisco-specific extensions" with
vendor specific extensions.
Cisco asked for these code points; they are assigned as such.