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: DNSEXT WGLC Summary: AXFR clarify
This thread is finally getting interesting. 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. What if (as in this case) it was in the past, and Olafur had no current or prospective income riding on BIND9, but he did once work for a company who did some subcontract work related to BIND9? Would he still be tainted? What if (as in this case) BIND9 is always released with a BSD-style license, allowing unlimited derivative works without fee and no source code requirement so long as the copyright holder (ISC) is held harmless and given credit? Would someone who had derived, or might some day derive, income from such an open source work be tainted as much as someone whose equity or patent holdings stood to gain from their work or from a certain standards decision? (I'm thinking of the IBM printing thing a few years ago.) -- Paul Vixie
