John,

You issued WG last call on the draft. I responded sincerely with
my comments. My comments relate to scope/applicability, limitations
and IANA considerations. You say, the document is implementable
and shouldnt be changed in response to my comments. I dont
appreciate your response. But, I dont intend belaboring on that.
Have it as you please.

Thank you for the opportunity to comment.

regards,
suresh

--- "Moy, John" <John.MoySYCAMORENET.COM> wrote:
> Suresh-
>
> I do not think that the authors of draft-katz-yeung-ospf-traffic-06.txt
> should be required to update their document in response to your comments.
> Dave is right -- the document is what it is. And for what it is, it is
> clear and implementable. Your comments don't improve it. At best they
> would just add unnecessary text. At worst your comments, such as the
> request to change a two-year-old document's name or to split it into pieces,
> would just create confusion.
>
> As for your latest message, a protocol spec needn't always say "why" for
> everything. On the previous last call we asked the authors to say just
> how much LAN and unnumbered support the document provided. And they did.
> That is sufficient. Unnumbered link support is being added in the
> referenced document. If you want to create a new document to add better
> LAN support, I'm sure people would read it with interest.
>
> John
>
> > -----Original Message-----
> > From: Pyda Srisuresh [mailto:srisureshYAHOO.COM]
> > Sent: Friday, October 19, 2001 11:30 AM
> > To: OSPFDISCUSS.MICROSOFT.COM
> > Subject: Re: Second Last Call for draft-katz-yeung-ospf-traffic-06.txt
> >
> >
> > 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
> >

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

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