Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
RTG AD hat on Let me try to summarize this discussion. Part of the discussion was on draft-katz-yeung vs draft-srisuesh-ospf-te. Based on the following note from Suresh-- 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 will ignore the arguments related to this comparison. Further comments in this e-mail are based on the text of Suresh'es original message to the IESG: The draft is a solution to providing TE within an OSPF area. This does not seem to be an argumentive statement. In fact, the draft is supposed to do exactly this. Nothing's wrong here. The draft has serious scalability limitations in extending this to inter-area and mixed networks (with TE and non-TE nodes). Because a) inter-area TE is a non-goal for this draft, and b) the inter-area TE topic is still in the exploration stage, the draft is not required (nor should it be assumed) to deal with inter-area TE scenarios. Hence, I do not believe that inter-area TE properties should be considered when deciding whether the draft should be published as an RFC or not. Kireeti suggested adding the following text to further clarify the scope of the document: 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. Which I think is a fine idea. Wrt the mixed network scenarios, there doesn't appear to be consensus that behavior of the mechanism that the WG came up with and described in draft-katz-yueng is incorrect or dangerous for the network. On the contrary, my knowledge of the deployment experience suggests that the mechanism is adequate. 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. Design of the mechanisms for TE in inter-area scenarios is work in progress and subject to the IETF consensus rules. Suresh is welcome to participate in this process. 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. As Kireeti mentioned, RFC2702 describes some requirements for MPLS TE. Suresh argued though that it does not describe the requirements for the IGP extensions that would satisfy the MPLS TE requirements. I would like to note, however, that this document has been in the WG for a very long time, passed the WG last call, and there is a consensus that the described mechanism is adequate for the intra-area TE task. Below are my specific comments on the draft. 1. The draft basically describes link TLVs for area-wide flooding. OSPF is an AS-wide IGP, not just area-wide. So, I would suggest renaming the draft as TE extensions to an OSPFv2 area, instead of the current title, TE extensions to OSPFV2. As Kireeti replied, the abstract already spells this out. Though I do not believe this is a must, spelling this out in the title would also be fine. I'd leave this up to the authors of the document. Large OSPF networks with multiple areas will not run this protocol. See above for the multi-area related discussion. 2. It is confusing to refer an opaque LSA with with a specific sub-type as TE LSA. It makes it sound like a stand-alone OSPF LSA with a distinct LSA type - which is is not. OSPF LSAs define the flooding scope. TE LSA does not. One suggestion would be to refer Opaque LSAs with specific sub-type 1 as TE-type Opaque LSA. I believe that this is a question of editorial preferences. Changing this terminology wouldn't substantially increase clarity or readability of the document. Leaving this up to the authors. 3. The limitations section (section 1.2) should mention the following limiations with a mixed network containing TE and non-TE nodes. 1. When a network area is constituted of TE and native-nodes (supporting IP-only links), the opaque LSAs will flood all nodes in the area, thereby disrupting native OSPF nodes. As As a general rule, a TE network is likely to generate significantly more control traffic than a native OSPF network. The excess traffic is almost directly proportional to the rate at which TE circuits are set up and torn down within the TE network. The more frequent and wider the flooding frequency, the larger the number of retransmissions and Acks.
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the Multi-area MPLS Traffic Enginering draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. As I said in my previous e-mail quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. That is precisely while quite a few scenarios in the Multi-area MPLS Traffic Engineering draft do not require any additions to what is already defined in the katz-yeung draft. Yakov. Yakov, Yes, quite a few scenarios described in kompella-mpls-multiarea-te draft are supported with single-area TE extensions and do not require any additions. And, katz-yeung draft proposal will suffice for single-area TE extensions. Good. So we are in agreement that the katz-yeung draft can support both single area and multi-area TE. katz-yeung draft does not cover dissemination of inter-area TE info (which I was refering to as *inter-area OSPF-TE*). Neither does the draft claim to do so. That is correct too. Inter-area OSPF-TE is a scenario described in kompella-mpls-multiarea-te for faster convergence in LSP computation. I am not sure which scenario you are referring to. But anyway, this is outside the scope of the present discussion... In this context - my recommendation to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE was because of its scaling limitation. And my recommendation is exactly the opposite - start multi-area TE with what is already in the katz-yeung draft, gain some operational experience with it, and then improve this, *if necessary*, based on the experience. But anyway, this is outside the scope of the present discussion... Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed networks. katz-yeung draft has limitations with flooding disruption and topology isolation in a mixed network - both intra-area and inter-area. This was another reason why I recommended to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE. To avoid any confusion I would suggest to add the following to the katz-yeung draft: It is an explicit non-goal of the solution described in this document to address all possible (as well as impossible) requirements. Therefore, the solution described in this document is clearly not a perfect solution, and as such doesn't quality for being a LTSFGTC (Long Term Solution For Generations To Come). Work on the perfect solution (aka LTSFGTC) is in progress, and is expected to be published in RFC10. Yakov.
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Yakov, Are you saying inter-area OSPF TE is not required? Without the inter-area OSPF TE, the non-backbone areas of an OPPF AS boil down to being *stub areas* and the backbone area becomes the only area. The round-robin ABR based trial-and-error CSPF computations can take inordinate amounts of time for LSP convergence. As LSPs are setup, TE network reachability changes. Without the inter-area OSPF TE, nodes are blind to TE reachability outside the area. Not offering inter-area OSPF TE, I believe, is a disservice to customers who need predictability. Same goes with the flooding and other limitations imposed on mixed networks. Lack of a requirements document for OSPF TE is clearly the cause of this debate. It may not be too late to work on one. Borrowing Keith's words, it sounds like we have a group of people insisting on adopting the one solution without significant change - treating it as inviolate rather than as a proof of concept. regards, suresh -Original Message- From: Yakov Rekhter [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 22, 2002 6:29 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard Suresh, My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the Multi-area MPLS Traffic Enginering draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. As I said in my previous e-mail quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. That is precisely while quite a few scenarios in the Multi-area MPLS Traffic Engineering draft do not require any additions to what is already defined in the katz-yeung draft. Yakov. Yakov, Yes, quite a few scenarios described in kompella-mpls-multiarea-te draft are supported with single-area TE extensions and do not require any additions. And, katz-yeung draft proposal will suffice for single-area TE extensions. Good. So we are in agreement that the katz-yeung draft can support both single area and multi-area TE. katz-yeung draft does not cover dissemination of inter-area TE info (which I was refering to as *inter-area OSPF-TE*). Neither does the draft claim to do so. That is correct too. Inter-area OSPF-TE is a scenario described in kompella-mpls-multiarea-te for faster convergence in LSP computation. I am not sure which scenario you are referring to. But anyway, this is outside the scope of the present discussion... In this context - my recommendation to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE was because of its scaling limitation. And my recommendation is exactly the opposite - start multi-area TE with what is already in the katz-yeung draft, gain some operational experience with it, and then improve this, *if necessary*, based on the experience. But anyway, this is outside the scope of the present discussion... Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed networks. katz-yeung draft has limitations with flooding disruption and topology isolation in a mixed network - both intra-area and inter-area. This was another reason why I recommended to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE. To avoid any confusion I would suggest to add the following to the katz-yeung draft: It is an explicit non-goal of the solution described in this document to address all possible (as well as impossible) requirements. Therefore, the solution described in this document is clearly not a perfect solution, and as such doesn't quality for being a LTSFGTC (Long Term Solution For Generations To Come). Work on the perfect solution (aka LTSFGTC) is in progress, and is expected to be published in RFC10. Yakov.
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
... snip My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the Multi-area MPLS Traffic Enginering draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. As I said in my previous e-mail quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. That is precisely while quite a few scenarios in the Multi-area MPLS Traffic Engineering draft do not require any additions to what is already defined in the katz-yeung draft. Yakov. Yakov, Yes, quite a few scenarios described in kompella-mpls-multiarea-te draft are supported with single-area TE extensions and do not require any additions. And, katz-yeung draft proposal will suffice for single-area TE extensions. katz-yeung draft does not cover dissemination of inter-area TE info (which I was refering to as *inter-area OSPF-TE*). Neither does the draft claim to do so. Inter-area OSPF-TE is a scenario described in kompella-mpls-multiarea-te for faster convergence in LSP computation. In this context - my recommendation to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE was because of its scaling limitation. Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed networks. katz-yeung draft has limitations with flooding disruption and topology isolation in a mixed network - both intra-area and inter-area. This was another reason why I recommended to not use katz-yeung draft as the basis to extend to inter-area OSPF-TE. regards, suresh
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, 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. The draft is about multi-area TE, as it describes how to solve the problem of supporting TE in a multi-area environment. 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. Just to point out that quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. To repeat what Kireeti said already There is work going on to address multi-area TE *that builds on this draft*. Yakov.
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
... snip 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. The draft is about multi-area TE, as it describes how to solve the problem of supporting TE in a multi-area environment. OK. 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. Just to point out that quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. To repeat what Kireeti said already There is work going on to address multi-area TE *that builds on this draft*. Yakov - My comment on the katz-yeung draft concerning multi-area is that it supports TE in a single OSPF area; and hence to rename the draft as TE extensions to an OSPFv2 area. My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the Multi-area MPLS Traffic Enginering draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. Yakov. regards, suresh
Re: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
Suresh, 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. The draft is about multi-area TE, as it describes how to solve the problem of supporting TE in a multi-area environment. OK. 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. Just to point out that quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. To repeat what Kireeti said already There is work going on to address multi-area TE *that builds on this draft*. Yakov - My comment on the katz-yeung draft concerning multi-area is that it supports TE in a single OSPF area; and hence to rename the draft as TE extensions to an OSPFv2 area. Let's be precise. The katz-yeung draft defines certain TE-related information, and specifies how to distribute this information within a single area. That is it. My recommendation against using this draft as the basis for building further TE-extensions to inter-area and mixed networks was in the context of OSPF Autonomous System (AS). I also mentioned the draft has scalability limitations in extending this to inter-area and mixed networks - also in the context of OSPF AS. Without going into the details of the Multi-area MPLS Traffic Enginering draft - The work cited in this draft as going on to address multi-area TE is in the MPLS signalling context, not in the OSPF. As I said in my previous e-mail quite a few scenarios described in draft-kompella-mpls-multiarea-te-03.txt are supported with the TE extensions that are subject to this Last Call. That is precisely while quite a few scenarios in the Multi-area MPLS Traffic Engineering draft do not require any additions to what is already defined in the katz-yeung draft. Yakov.
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: 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: 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: 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: 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
RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard
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. 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=ospfT=0F=S=; P=5937 This goes right back to the comment I made below about using the draft-katz-yeung draft as the basis for inter-area TE. regards, suresh -Original Message- From: Rohit Dube [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 11:46 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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
Suresh, 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. 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=ospfT=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. This goes right back to the comment I made below about using the draft-katz-yeung draft as the basis for inter-area TE. regards, suresh -Original Message- From: Rohit Dube [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 11:46 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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
resending... My apologies, if you receive two copies of this. I believe, the orginal e-mail did reach the ietf list. Thanks. regards, suresh -Original Message- From: Pyda Srisuresh [mailto:[EMAIL PROTECTED]] Sent: Friday, December 13, 2002 11:13 AM To: [EMAIL PROTECTED] Cc: Pyda Srisuresh; [EMAIL PROTECTED] Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard 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. Below are my specific comments on the draft. 1. The draft basically describes link TLVs for area-wide flooding. OSPF is an AS-wide IGP, not just area-wide. So, I would suggest renaming the draft as TE extensions to an OSPFv2 area, instead of the current title, TE extensions to OSPFV2. Large OSPF networks with multiple areas will not run this protocol. 2. It is confusing to refer an opaque LSA with with a specific sub-type as TE LSA. It makes it sound like a stand-alone OSPF LSA with a distinct LSA type - which is is not. OSPF LSAs define the flooding scope. TE LSA does not. One suggestion would be to refer Opaque LSAs with specific sub-type 1 as TE-type Opaque LSA. 3. The limitations section (section 1.2) should mention the following limiations with a mixed network containing TE and non-TE nodes. 1. When a network area is constituted of TE and native-nodes (supporting IP-only links), the opaque LSAs will flood all nodes in the area, thereby disrupting native OSPF nodes. As As a general rule, a TE network is likely to generate significantly more control traffic than a native OSPF network. The excess traffic is almost directly proportional to the rate at which TE circuits are set up and torn down within the TE network. The more frequent and wider the flooding frequency, the larger the number of retransmissions and Acks. It is undesirable to flood non-TE nodes with TE TLVs. 2. A link cannot be reserved for TE-only use. All links must be subjectable to best-effort IP traffic first, before any of the links are permitted to carry TE traffic. In a mixed network, an OSPF router supporting TE-links and native IP-links could potentially select a TE link to be its least cost link and inundate the link with best-effort IP traffic, thereby rendering the link unusable for TE purposes. regards, suresh -Original Message- From: Mailing List [mailto:[EMAIL PROTECTED]]On Behalf Of The IESG Sent: Monday, November 25, 2002 3:47 PM To: [EMAIL PROTECTED] Subject: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard The IESG has received a request from the Open Shortest Path First IGP Working Group to consider Traffic Engineering Extensions to OSPF Version 2 draft-katz-yeung-ospf-traffic-09.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by December 26, 2002 Files can be obtained via http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt
