RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, You have brought up this issue on the ospf mailing list a couple of times and as such the topic has been addressed on the list. Here is pointer to an email from John Moy (circa July 2001) http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0107L=OSPFD=0I=-3P=15162 and another more recent one from me in response to your email on your alternate-te proposal http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0212L=OSPFD=0I=-3P=6031 Best, --rohit. (OSPF WG co-chair) ::The draft is a solution to providing TE within an OSPF area. ::The draft has serious scalability limitations in ::extending this to inter-area and mixed networks (with TE and ::non-TE nodes). Please see my comments below. I would not ::recommend using this draft as the basis for building further ::TE-extensions to inter-area and mixed networks. :: ::The draft apparently evolved over time with no requirements ::document to guide it. The vendors and implementors behind the ::draft may have been guided by different set of requirements ::and motivations, such as having some working code. Unfortunately, ::this ad-hoc approach has a cost. Any new requirements are having ::to be met in a reactive mode and having to be provided as fixes ::on top of this working code. This is not right and doesnt bode ::well for the future of the protocol. [snip]
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
On Tue, 17 Dec 2002 13:11:37 -0800 Pyda Srisuresh writes: =Rohit, = =My comments were made solely in reference to the =draft-katz-yeung draft; not in comparison to any specific draft, =as you might believe. [snip] Suresh, This is not the first time we are hearing from you on the topic. Your original mail to [EMAIL PROTECTED] does not mention any context or previous discussion on the topic when such a context exists. I simply wanted to make people not on the ospf list aware of this. --rohit.
Re: DNSEXT WGLC Summary: AXFR clarify
On Tue, 17 Dec 2002 10:53:28 +0100, Stephane Bortzmeyer said: On Tue, Dec 17, 2002 at 08:58:22AM -, D. J. Bernstein [EMAIL PROTECTED] wrote a message of 26 lines which said: DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, writes: For me, this is too much. Now, on the *one* hand, I'd be surprised indeed if the chair of DNSEXT had NOT been paid by somebody to do BIND consulting somewhere along the line. On the other hand, if Olafur is in fact making a living doing BIND9 development and coding for ISC or one of their clients, that might be called a conflict of interest when the issue at hand is that a specific document is too BIND9 specific. Personally, I'm OK with Olafur making money doing BIND. I'm even OK on him possibly making more if the draft becomes an RFC in its current state. I admit I've looked through RFC2026 and found nothing about disclosure of conflict of interest(*). I hate making more work for the AD and IESG, but I think at least a We've talked to Olafur and do/dont think there's a problem is called for. (*) I'll let wiser people than I decide if there should be such a section in a son-of-2026 -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg09798/pgp0.pgp Description: PGP signature
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
actually, in the IETF, having running code for *one* solution is a good way to demonstrate how much of the problem is understood, and if some of us had our way, it would be impossible to charter a Working Group *without* the understanding of the problem space being *at least* that good. cheers, -mo Always do right. It will gratify some people and astonish the rest. -Mark Twain
Re: DNSEXT WGLC Summary: AXFR clarify
On Tue, Dec 17, 2002 at 08:58:22AM -, D. J. Bernstein [EMAIL PROTECTED] wrote a message of 26 lines which said: DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, writes: For me, this is too much. For those who use procmail: :0 * ^From:.*D. J. Bernstein /dev/null
RE: DNSEXT WGLC Summary: AXFR clarify
Please god NO... I hope EVERYONE deeply involved in a WG documentation process has deep DEEP conflict of interest problems. I mean if we are not working on the things we are documenting, how will we know if they work or not. Saying that WG chairs can not work for companies that need the efforts of the WG seems like setting up a big failure, there are checks and balances, you don't like what the chairs of a WG are doing, talk to the ADs, don't like what the ADs say go to the IAB... This is a documented process. I do not know about the DNS WG, but most working groups that I am aware of also have two co-chairs, usually from different companies/areas - and I know that my co-chair and I have to be in agreement on char descisions, reducing the effect of one of us having a massive conflict of interest. Please do not require conflict of interest rules to enter the IETF, this isn't the government, we NEED this to work Bill Strahm -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, December 18, 2002 1:34 PM To: Stephane Bortzmeyer Cc: D. J. Bernstein; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: DNSEXT WGLC Summary: AXFR clarify On Tue, 17 Dec 2002 10:53:28 +0100, Stephane Bortzmeyer said: On Tue, Dec 17, 2002 at 08:58:22AM -, D. J. Bernstein [EMAIL PROTECTED] wrote a message of 26 lines which said: DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, writes: For me, this is too much. Now, on the *one* hand, I'd be surprised indeed if the chair of DNSEXT had NOT been paid by somebody to do BIND consulting somewhere along the line. On the other hand, if Olafur is in fact making a living doing BIND9 development and coding for ISC or one of their clients, that might be called a conflict of interest when the issue at hand is that a specific document is too BIND9 specific. Personally, I'm OK with Olafur making money doing BIND. I'm even OK on him possibly making more if the draft becomes an RFC in its current state. I admit I've looked through RFC2026 and found nothing about disclosure of conflict of interest(*). I hate making more work for the AD and IESG, but I think at least a We've talked to Olafur and do/dont think there's a problem is called for. (*) I'll let wiser people than I decide if there should be such a section in a son-of-2026 -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
I understand. The flip side to this is that once a solution is implemented and deployed, there is lethargy to look at other solutions (or) to expand the problem space. Then, there is the legacy of this implementation that future solutions have to live with. Anyways, this is all the more why I believe, the protocol document should at a minimum cover the boundaries of its applicability. regards, suresh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike O'Dell Sent: Wednesday, December 18, 2002 1:47 PM To: [EMAIL PROTECTED] Cc: Mike O'Dell; [EMAIL PROTECTED] Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard actually, in the IETF, having running code for *one* solution is a good way to demonstrate how much of the problem is understood, and if some of us had our way, it would be impossible to charter a Working Group *without* the understanding of the problem space being *at least* that good. cheers, -mo Always do right. It will gratify some people and astonish the rest. -Mark Twain
Re: DNSEXT WGLC Summary: AXFR clarify
On Wed, 18 Dec 2002 14:14:16 PST, Bill Strahm said: I hope EVERYONE deeply involved in a WG documentation process has deep DEEP conflict of interest problems. I mean if we are not working on the things we are documenting, how will we know if they work or not. Quite true. And I believe I said I'd be surprised if the WG chair didn't make money at it Saying that WG chairs can not work for companies that need the efforts of the WG seems like setting up a big failure, there are checks and balances, you don't like what the chairs of a WG are doing, talk to the ADs, don't I think that's what I did - if the AD or IESG says We talked to Olafur and there's nothing major I'll be happy. I'd even be OK with it if he had the prospect of a $400K consulting contract if the draft goes a certain way - we've certainly seen companies like Cisco have literally millions riding on a given RFC, but it's rare that such information isn't known. I know when MIME and ESMTP were being designed, everybody in the working group knew who had MUAs and MTAs in the pipe, and they were usually quite clear on exactly how much a given WG decision was going to cost in redesign/recoding. I don't even see the need for a formal public disclosure process - but djb *did* raise the point on the main IETF list, where probably most of the readers *dont* know Olafur's situation, so at least *some* response is probably called for. Regarding RFC2026, it looks like section 6.5 and friends *do* address the problem adequately *IF* you read the text in 6.5.1: ... (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. ... as including allegations of conflict-of-interest. If that's the understood reading of it by the IESG, then I'm OK with 2026 as it stands... /Valdis msg09803/pgp0.pgp Description: PGP signature
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 toProposed Standard
On Wed, 18 Dec 2002, Pyda Srisuresh wrote: ... Hence, a statement of applicability and limitations is warranted in the draft. Let me be more precise: draft-katz-yeung says how TE in a single OSPF area can be accomplished. It doesn't aim to address the multi-area case; *nor does it say that it cannot do so*; *nor should it do so*. There is work going on to address multi-area TE *that builds on this draft*. In spite of your recommendations, this multi-area work building on draft-katz-yeung has a lot of traction. I therefore have no intentions of putting in incorrect or incomplete limitations. ... Kireeti - I am aware of RFC 2702 and have reviewed it. The RFC is about requirements and applications of TE over MPLS. The RFC is *not* about requirements for the IGP collecting TE metrics within an Autonomous System(AS). I was refering to the latter. draft-katz-yeung is *not* about collecting TE metrics. It's about providing a topological database that can be used for routing traffic trunks; the parameters that are carried in this database are those whose semantics and applicability are described in RFC 2702. ... The whole crux of my comments has been on scaling and applicability limitations. Large OSPF networks with multiple areas will not run this protocol. Crystal ball? I suggest you get a new one. READ - This protocol is restricted in scope to a single area. I beg to differ -- see above. In response to your comments, I will add the following statement at the end of the second para in the Introduction: This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. Kireeti.
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
-Original Message- From: Kireeti Kompella [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 18, 2002 3:37 PM To: Pyda Srisuresh Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard On Wed, 18 Dec 2002, Pyda Srisuresh wrote: ... Hence, a statement of applicability and limitations is warranted in the draft. Let me be more precise: draft-katz-yeung says how TE in a single OSPF area can be accomplished. It doesn't aim to address the multi-area case; *nor does it say that it cannot do so*; *nor should it do so*. There is work going on to address multi-area TE *that builds on this draft*. In spite of your recommendations, this multi-area work building on draft-katz-yeung has a lot of traction. I therefore have no intentions of putting in incorrect or incomplete limitations. ... Kireeti - You apparantly have an attitude and it shows. Outside of your attitude, you have not said anything in your defence. All my comments including those on limitations remain unanswered. Kireeti - I am aware of RFC 2702 and have reviewed it. The RFC is about requirements and applications of TE over MPLS. The RFC is *not* about requirements for the IGP collecting TE metrics within an Autonomous System(AS). I was refering to the latter. draft-katz-yeung is *not* about collecting TE metrics. It's about providing a topological database that can be used for routing traffic trunks; the parameters that are carried in this database are those whose semantics and applicability are described in RFC 2702. ... The whole crux of my comments has been on scaling and applicability limitations. Large OSPF networks with multiple areas will not run this protocol. Crystal ball? I suggest you get a new one. READ - This protocol is restricted in scope to a single area. I beg to differ -- see above. In response to your comments, I will add the following statement at the end of the second para in the Introduction: This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. This is *not* what I stated in my comments and is *not* a characterization of my commnents. I gave backing for all the comments I made. I am sorry to say you did little on your part, other than come back with an attitude. Kireeti. regards, suresh
Re: DNSEXT WGLC Summary: AXFR clarify
I hope EVERYONE deeply involved in a WG documentation process has deep DEEP conflict of interest problems. seems a bit of a stretch. it's one thing to have an interest in producing a technically sound outcome; quite another to have an interest in producing a particular outcome even when it has technical problems. Keith
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 toProposed Standard
On Wed, 18 Dec 2002, Pyda Srisuresh wrote: Let me be more precise: draft-katz-yeung says how TE in a single OSPF area can be accomplished. It doesn't aim to address the multi-area case; *nor does it say that it cannot do so*; *nor should it do so*. There is work going on to address multi-area TE *that builds on this draft*. In spite of your recommendations, this multi-area work building on draft-katz-yeung has a lot of traction. I therefore have no intentions of putting in incorrect or incomplete limitations. ... Kireeti - You apparantly have an attitude and it shows. Outside of your attitude, you have not said anything in your defence. You clearly have an agenda. Those who have a background in this matter know this. Those who don't don't know how lucky they are. Let me repeat, using short words with few syllables: 1) draft-katz-yeung says how to do TE in a single OSPF area. 2) draft-katz-yeung does not address the multi-area case. 3) Given (2), it does not make sense to put in lim it ations that say it won't work in the multi-area case when at worst we don't know, and at best it may in fact work like a charm. All my comments including those on limitations remain unanswered. You confuse answered, but not to your satisfaction with unanswered. ... This document purposely does not say how the mechanisms described here can be used for traffic engineering across multiple OSPF areas; that task is left to future documents. This is *not* what I stated in my comments and is *not* a characterization of my commnents. I never said that that's what you stated. I just said that that was what I would insert. It's been fun, Kireeti.
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
... snip As for the comment from John Moy (circa July 2001) about the availability of an inter-area OSPF draft, I do recall responding that the inter-area draft was assuming additive properties to TE metrics to advertise summary info. It is a mistake to assume that all TE metrics can be additive. Below is a pointer to the response I sent. http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108L=ospf; T=0F=S= P=5937 Please look at draft-kompella-mpls-multiarea-te-03.txt, as at least some of the approaches described in that draft do *not* assume additive properties of TE metrics (and do not advertise summary info). Yakov. Yakov - You are right. The draft does talk about different mechanisms the MPLS signaling protocols could use to setup LSPs in an AS spanning multiple areas. However, the draft is not about inter-area OSPF TE. Clearly, there is interplay between signalling protocols and the extent of TE link state data base (TE-LSDB) a node has. I believe, scenario-3 is where the inter-area OSPF-TE is in place and all nodes in an area have the same information as their ABRs do. This scenario presents the signalling protocols with fast convergence in settign up an LSP, right. regards, suresh
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Kireeti Kompella Sent: Wednesday, December 18, 2002 5:16 PM To: Pyda Srisuresh Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard On Wed, 18 Dec 2002, Pyda Srisuresh wrote: Let me be more precise: draft-katz-yeung says how TE in a single OSPF area can be accomplished. It doesn't aim to address the multi-area case; *nor does it say that it cannot do so*; *nor should it do so*. There is work going on to address multi-area TE *that builds on this draft*. In spite of your recommendations, this multi-area work building on draft-katz-yeung has a lot of traction. I therefore have no intentions of putting in incorrect or incomplete limitations. ... Kireeti - You apparantly have an attitude and it shows. Outside of your attitude, you have not said anything in your defence. You clearly have an agenda. Those who have a background in this matter know this. Those who don't don't know how lucky they are. There is no secret or hidden agenda here. Stop making insinuations. It is no secret that I have a competing draft, titled, OSPF-TE: An experimental extension to OSPF for Traffic Engineering (filed as draft-srisuesh-ospf-te-04.txt). I sent messages in the past to the OSPF WG, comparing my draft to the katz-yeung draft. This is what Rohit Dube was alluding to in his last e-mail. Make no mistake. The comments I sent to the IETF were solely in response to the IETF last call on the katz-yeung draft; not in comparison with any specific draft. I mentioned this to Rohit in my last e-mail to him. It is part of the IETF process to let the wider community know of the concerns with the draft. I am doing my share. I backed all my comments with explanations. Let me repeat, using short words with few syllables: 1) draft-katz-yeung says how to do TE in a single OSPF area. 2) draft-katz-yeung does not address the multi-area case. 3) Given (2), it does not make sense to put in lim it ations that say it won't work in the multi-area case when at worst we don't know, and at best it may in fact work like a charm. No dispute here. My comment in this context was to fix the title. My remaining comments are to do with fixing confusing terminology and adding limitations of the model vis-a-vis mixed networks. All my comments including those on limitations remain unanswered. You confuse answered, but not to your satisfaction with unanswered. ... Your answers were either incomplete or riddled with attitude so as to sidestep the original comment. ... snip regards, suresh
RFC publish rate
Hi, Is it just me, or have RFC's been popping out lately like mushrooms in an autumn? Something seems to be working.. :-) -- Pekka Savola Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Re: RFC publish rate
do not confuse effort for progress vint cerf At 08:33 AM 12/19/2002 +0200, you wrote: Hi, Is it just me, or have RFC's been popping out lately like mushrooms in an autumn? Something seems to be working.. :-) Vint Cerf SVP Architecture Technology WorldCom 22001 Loudoun County Parkway, F2-4115 Ashburn, VA 20147 703 886 1690 (v806 1690) 703 886 0047 fax
