Dave, Katz and Kireeti,

Couple of additional comments on section 1.2. Limitations. The link
extensions in the document are aparently limited only to point-to-point,
numbered links. Below is the text on limitations.

           The extensions specified in this document capture the reservation
           state of point-to-point links. The reservation state of multiaccess
           links is not accurately reflected, except in the special case that
           there are only two devices in the multiaccess subnetwork.

           This document also does not support unnumbered links. This
           deficiency is addressed in [4]; see also [5] and [6].

To not include LAN links in TE topology seems like a big limitation
to me. Please explain the rationale behind. Bandwidth reservation
on LAN links is not an issue with all routing vendors. Some have
this implemented in prorietary ways. Besides, bandwidth is not the
only criteria for TE link. Without the support for LAN links, Ethernet
network vendors (the likes of Yipes and COgent) will not be able to
apply Link extensions to their networks. That is not a good thing.

I understand, it is desirable for all all nodes and links that may
be party to a TE circuit to be uniquely identifiable by an IP
address. As such, I can see the need to manadate a separate loopback
IP address for the TE router, independent of the links attached. However,
to expect all point-to-point links to be numbered seems unreasonable.
IP addresses are an expensive resource to mandate. Please explain
the rationale behind.

Also, you refer signaling documents ([5] and [6]) to address the
deficiency w.r.t. unnumbered links. As you will probably agree, it is
not a good idea for the control protocol documents to refer
signaling documents to address TE characteristics issue. It should be
the way around. I.e., the control protocol should provide adequate
infrastructure information for use by the signalling protocol to
set up TE circuits.

In summary, I am concerned about requiring the point-to-point links to
be numbered and not including support for LAN links in the document.
I would like to see these restrictions eliminated. Thanks.

regards,
suresh

--- Pyda Srisuresh <srisureshYAHOO.COM> wrote:
> Please see my comments below. Thanks.
>
> --- Dave Katz <dkatzJUNIPER.NET> wrote:
> > 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.
> >
> Dave - This is not a nit. A Very sincere request.
>
> The document often gets quoted by its title and people have an
> expectation of the content from the title. For this reason alone,
> it is important to have the title reflect the content as accurately
> as possible.
>
> By identifying (in the title) the scope to be an OSPF area, it becomes
> apparent that other draft(s) will be required to address inter-area TE
> extensions. By identifying the approach to be Opaque-LSA based, it states
> that there may be viable alternatives to the Opaque-LSA-approach.
>
> > 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.
> >
>
> I understand what you mean. I can go with that, even though I do think
> it is much harder to split an RFC into two.
>
> The draft, titled, "OSPF Extensions in Support of Generalized MPLS"
> <draft-ietf-ccamp-ospf-gmpls-extensions-00.txt> merely extends the
> link TLVs for GMPLS, keeping the Opaque-LSA flooding approach.
>
> I was alluding to a case where the only TLVs in the document may be
> refered by other documents, but in the context of using an
> alternative approach to Opaque-LSAs.
>
> By splitting the two - it would be easier to make updates to either of
> the drafts independently and for other drafts to refer them. I can
> easily envisions updates to both these drafts in the days to come.
> The good news is that there is a clear line between the two.
>
> > 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.
> >
>
> If it stated so in the words that you just described, I will have no
> issues with it. But, the following paragraph doesnt state that.
>
> Finally, for "global traffic engineering", a device can build a
> traffic engineering database, input a traffic matrix and an
> optimization function, crunch on the information, and thus compute
> optimal or near-optimal routing for the entire network. The device
> can subsequently monitor the traffic engineering topology and react
> to changes by recomputing the optimal routes.
>
> It seems to imply that a device can take the LSDB and compute optimal
> routes for the entire network.
>
> > 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.)
>
> Dave - Even to an informed reader, the above limitations are not obvious.
> The intent is to make apparent any known limitations, so it is abundantly
> clear to the informed as well asnot so-informed readers.
>
> For example, there is an unstated assumption throughout that a network
> is used either for TE purposes or for native-IP forwarding purposes, not
> both. This is a fundamental assumption that has repurcussions on the
> structuring and use of LSDB. The LSDB model and flooding model is built
> on this premise. However, if a service provider chooses to make both
> these services available on the same network using the approach in this
> document, he could be surprised. This is what item a) above refers to.
> Item c) also refers to this from a different point of view.
>
> Likewise, there is an unstated assumption that all TE routers have the
> same features in support of TE extensions. The model does not make use
> of router-capability TLVs. This need not be the case. A multi-vendor or
> a multi-release-from-same vendor router network can have problems because
> of capability mismatch. This is what item b) above alludes to.
>
> >
> > 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.
> >
> Thanks, Dave. I appreciate that.
>
> If it turns out that the issues I point out are operationally
> unimportant now, then mentioning these as limitations would not do
> any harm, does it?
> On the other hand, It might do a lot of good at a different time to
> service providers when these issues become operationally important.
> (or) to a rare service provider who is offering TE and non-TE ; and
> packet and non-packet services on the same network, even at this time.
>
> >
> > 5. Section 2.4.2 - Replace "Cisco-specific extensions" with
> > vendor specific extensions.
> >
> > Cisco asked for these code points; they are assigned as such.
>
> OK, got it. But, isnt this an IANA function? IANA maintains a separate
> document to track which range is issued to whom. I believe, you should
> have an IANA considerations section and let the IANA assign numbers to
> vendors independent of this draft.
>
> >
> > --Dave
>
> Thanks.
>
> regards,
> suresh
>
> =====
>
>
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com

=====

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

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