[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-srisuresh-ospf-te-04.txt
I guess i can live with that...
still, Jim, Pyda, i have some suggestions that might interest TE wg. They are general, not specific only to this draft.
I started posting on TE, CCAMP and OSPF to get the opportunity to contribute with something from implementation experiences (such as Pyda's). I'm currently doing a ASTN-GMPLS implementation for SDH-SONET network elements, and stumbled across many questions, that i see uncovered on all the mentioned charters.
I think the first leafs of these postings could be "flooded" (to use OSPF terms :-) ) outside the WGs lists... because it could all just be uninteresting for all the IP people that actually are doing most of the work. However, and i'm sure you all hear this argument too many times, my time to write drafts, comments and follow up posts is proportionally diminuished as the ongoing work with the actual implementation proceeds...
Nevertheless, i'll try to make a summarized post that, hopefully, will catch TE wg attention:
Concerning TDM technologies in general, already experienced in SDH/SONET:
(sorry for the eventual typos: on a hurry, and not my mother tongue)
The use of Unreserved Bandwidth figures, do denote the fact that some resources are allocated, and oters are free, to any giving te class, is a "multiple possible answer" challenge on SDH/SONET.
Take this light example:
a STM4 interface contains 4 AU-4 payload containers. The 1st AU-4 is altogether allocated. The Unreserved Bandwidth figure, neverminding classes, cannot be expressed in Bits/Bytes per second.
Proof: the Bytes per second number only has some validity when you consider that the remaining AU4 (2nd, 3rd and 4th) are structured in a given way. Lets assume that all Au4 were individually structured as VC-4 "bulk": 3*(~)155000=465000 Kbits/s are available to carry payload. To complete my example, if all AU-4 are structured in the c11 granularity (the ones that carry DS1) we only have 3*(3*7*4)*1544Kbits/s=389088 Kbits/s.
Another worring aspect of this "Unreserved Bandwidth" is that my example talks about very simple structured STMs... if you have a AU4 that has complex structured payloads, you simply cannot answer the question "How many Kbits/s are available", because the question should be "in the X container granularity, with/without concatenation(s), bla, bla, bla, how many containers am i able to squeeze in this frame?"...
My suggestion is that TE wg makes possible, or at least entertains the possibility, that for a specific technology, one is able to express the Reserved Resources figure (notice "Resources" rather than "Bandwidth"). The Unreserved/Free figure is only answer-able with the knowledge of the currently allocated payload structure, and the SDH/SONET parameterized question.
And now for something completely different (Pyda directed):
I've failed to prove any use of flooding TE information only at link level... Won't every CSPF-TE, that might get queried, need *ALL* TE information to path-find properly? In IMHO, LSA-TE information always REQUIRES the AS flooding... all instances of a TE path-finding algorithm must produce the same answers disregarding where they are. I know that eventually, the Link-scope information will get AS flooded, but that takes processing and forwarding time, for something that should be as fast as 50ms: protection and restoration (the calculation of a backup/working paths). Nevermind the 50ms goal, but "below 10s" would suffice for the majority of data services.
I think this is enough for now, please repeat to me that TE wg has no interest in this, or comment on,
best regards,
Jorge Pinto
-----Original Message-----
From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
Sent: Sexta-feira, 13 de Dezembro de 2002 3:57
To: Jim Boyle
Cc: Jorge Pinto; te-wg@ops.ietf.org; pjoseph@Force10Networks.com
Subject: RE: draft-srisuresh-ospf-te-04.txt
No problem. I will exclude te-wg from the Cc list in the future.
cheers,
suresh
-----Original Message-----
From: Jim Boyle [mailto:jboyle@pdnets.com]
Sent: Thursday, December 12, 2002 7:17 PM
To: Pyda Srisuresh
Cc: Jorge Pinto; te-wg@ops.ietf.org; pjoseph@Force10Networks.com
Subject: RE: draft-srisuresh-ospf-te-04.txt
There doesn't appear to be much interest in this particular draft in
TEWG (or even in changing intra-area te igp functionality in general).
regards,
Jim
On Thu, 12 Dec 2002, Pyda Srisuresh wrote:
> Jorge,
>
> TE extenstions to the OSPF protocol are not part of the
> TE-WG charter. But, TE-WG folks do have FYI interest in
> the subject matter. This was pointed out in the Utah IETF,
> I believe.
>
> If you are refering to non-packet networks, section 9 of
> the draft is devoted to support for non-packet networks.
> However, I agree, the OSPF-TE draft is predominantly focussed
> on TE in packet networks. If you have specific comments on the
> non-packet extensions, please do send them. Thanks.
>
> regards,
> suresh
>
> -----Original Message-----
> From: Jorge Pinto [mailto:Jorge.Pinto@siemens.com]
> Sent: Thursday, December 12, 2002 2:19 AM
> To: Jim Boyle; Pyda Srisuresh
> Cc: te-wg@ops.ietf.org; pjoseph@Force10Networks.com
> Subject: RE: draft-srisuresh-ospf-te-04.txt
>
>
> I'm sorry to budge in,
>
> I really don't see the point in this move towards OSPF only...
> There are several aspects on this and other drafts that concern only to
the
> TEWG. For instance, the fact that the draft is neglecting the structure of
> SDH/SONET frames, which is the only way to describe bandwidth in this
> tecnology (nevermind the bytes per second... their useless in SDH).
Another
> example is the fact that all drafts are trying to flood UN-reserved BW
> information, but for SDH-SONET, this kind of answer is a multiple choice
(a
> AU4 can be decomposed in a lot of different things). However, i concede
that
> the draft presents more suggestions to the OSPF WG than to the TE.
> IMHO, this draft should be presented to TEwg and to the OSPFwg. The TE wg
> can surely keep its mind on the TE issues, while OSPF, CCAMP, etc will
> focus on the rest.
>
> Anyway, keep up the good work, Pyda, et al,
>
> Jorge Pinto
>
> -----Original Message-----
> From: Jim Boyle [mailto:jboyle@pdnets.com]
> Sent: Quinta-feira, 12 de Dezembro de 2002 1:08
> To: Pyda Srisuresh
> Cc: te-wg@ops.ietf.org; pjoseph@Force10Networks.com
> Subject: RE: draft-srisuresh-ospf-te-04.txt
>
>
>
> So it is more of a contribution to the OSPF WG, not the TEWG?
> I'll ask ietf-secretary to make the corresponding changes.
> You might want to forward the announce message to OSPF WG.
>
> thanks,
>
> Jim
>
> On Wed, 11 Dec 2002, Pyda Srisuresh wrote:
>
> > Hi Jim,
> >
> > The draft was not on the OSPF agenda for 51st IETF (London) or the 55th
> > IETF(Atlanta), as far as
> > I can tell. Besides, I did not attend either of the two IETFs. I did
> attend
> > the Utah IETF (52nd). But,
> > there wasn't a slot for OSPF. Oh, well..
> >
> > You are right, the above OSPF-TE draft is a competing draft to
> > draft-katz-yeung.
> > The OSPF-TE draft does more than TE topology discovery and restricted
> > flooding along the
> > topology. The draft also covers inter-area TE and pre-engineered
circuit
> > path LSAs.
> > A stand-alone TE-LSDB, independent of the native LSDB is generated for
TE
> > computations.
> >
> > Please send in any comments you might have on the draft. Thanks.
> >
> > Regards,
> > suresh
> >
> >
> > -----Original Message-----
> > From: Jim Boyle [mailto:jboyle@pdnets.com]
> > Sent: Tuesday, December 10, 2002 6:52 AM
> > To: te-wg@ops.ietf.org
> > Cc: srisuresh@yahoo.com; pjoseph@Force10Networks.com
> > Subject: draft-srisuresh-ospf-te-04.txt
> >
> >
> > This was on the agenda for the 51st and 55th IETF, but no presentation
> > (I think I remeber some discussion at the 51st, but it's not in the
> > minutes).
> >
> > Also, no discussion on the lists.
> >
> > What's up with this? Does anyone see a need to toss out
> > draft-katz-yeung-ospf-traffic-09.txt
> > for draft-srisuresh-ospf-te-04.txt so that non TE nodes
> > don't have to be bothered with the opaque LSA? Or
> > is there a grander scope to this?
> >
> > If not, I'm not sure why we keep seeing this draft rev change
> > as an individual contribution to tewg.
> >
> > Jim
> > ---------- Forwarded message ----------
> > Date: Wed, 11 Dec 2002 08:12:35 -0500
> > From: Internet-Drafts@ietf.org
> > To: IETF-Announce: ;
> > Cc: te-wg@ops.ietf.org
> > Subject: I-D ACTION:draft-srisuresh-ospf-te-04.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Internet Traffic Engineering Working
> Group
> > of the IETF.
> >
> > Title : OSPF-TE: An experimental extension to OSPF for
> > Traffic
> > Engineering
> > Author(s) : P. Srisuresh, P. Joseph
> > Filename : draft-srisuresh-ospf-te-04.txt
> > Pages : 45
> > Date : 2002-12-9
> >
> > This document defines OSPF-TE, an experimental traffic engineering
> > (TE) extension to the link-state routing protocol OSPF. New TE
> > LSAs are designed to disseminate TE metrics within an autonomous
> > System (AS) - intra-area as well as inter-area. An Autonomous
> > System may consist of TE and non-TE nodes. Non-TE nodes are
> > uneffected by the distribution of TE LSAs. A stand-alone TE Link
> > State Database (TE-LSDB), separate from the native OSPF LSDB, is
> > generated for the computation of TE circuit paths. OSPF-TE is
> > also extendible to non-packet networks such as SONET/TDM and
> > optical networks. A transition path is provided for those
> > currently using [OPQLSA-TE] and wish to adapt OSPF-TE.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-srisuresh-ospf-te-04.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the
> message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > "get draft-srisuresh-ospf-te-04.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-srisuresh-ospf-te-04.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant mail
> readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
>
>