Suresh:

      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
            opaque LSAs.

         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
         area?

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.

--Dave

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]