Re: DNSEXT WGLC Summary: AXFR clarify
DNSEXT chair Olafur Gudmundsson, who has been paid for BIND work, writes: only you objecting to the document There have been public objections from Aaron Swartz, Felix von Leitner, Len Budney, Kenji Rikitake, Dean Anderson, Sam Trenholme (MaraDNS implementor), and of course me (djbdns implementor)---plus an unknown number of people whose messages to namedroppers have been silently discarded by Randy Bush. Meanwhile, axfr-clarify is being pushed primarily by people with financial interests in BIND. The Yokohama minutes say ``too bind specific'' with no hint of any dispute about that, and the Atlanta minutes don't indicate any further discussion. What's most damning, of course, is the simple fact that the objections are being ignored. http://cr.yp.to/djbdns/axfr-clarify.html explains in detail what's wrong with the BIND company's arguments; the BIND company responds by repeating the arguments and ignoring the objections. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago
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 toProposed Standard
Hi, On Mon, 16 Dec 2002, Pyda Srisuresh wrote: The draft is a solution to providing TE within an OSPF area. Yes. 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. Actually, inter-area TE is a hard problem -- however, the issue is not how you format the bits or what type of LSA you use, but what information should be carried, how it should be summarized (if at all that is a feasible approach), minimizing crankback, etc. I would not recommend using this draft as the basis for building further TE-extensions to inter-area and mixed networks. Your recommendation is noted. Of course, that is not the issue at hand -- the issue at hand is a proposal for *intra-area* TE. The draft apparently evolved over time with no requirements document to guide it. Perhaps you should read RFC 2702 before making comments. The vendors and implementors behind the draft may have been guided by different set of requirements and motivations, such as having some working code. Your point being that working code is a Bad Thing? 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. If you're going to comment on the title, please at least get it right: it's Traffic Engineering Extensions to OSPF Version 2. Your suggested title would be unnecessarily long; anyone who can read the very short (20 word) abstract will learn that this is for intra-area TE post haste. Large OSPF networks with multiple areas will not run this protocol. Crystal ball? I suggest you get a new one. 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. This is beyond nitpicking. Note that the Opaque LSA for Graceful Restart is called the Grace LSA; also that many many other documents besides this one call the TE-type Opaque LSA simply a TE 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. Do you know of any mixed networks? You're right, however, that if non-TE-capable nodes are present in the network, they will have to flood the LSAs carrying TE information as well. However, this is a natural characteristic of OSPF flooding and Opaque LSA mechanism not changed by the TE extensions, hence does not need to be explicitly explained. 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. This is patently false. There are two methods of reserving links for TE-only use, one of which is documented in LSP Hierarchy with Generalized MPLS TE, the other being the obvious 'advertise the link LSA with infinite SPF metric'. While I respect your right to comment (that is after all the point of an IETF Last Call), I would really suggest you do your homework before you comment. In summary, I have read and responded to the comments above; in my opinion, they do not warrant any changes to the document. However, if any one else feels otherwise, please do not hesitate to let me know, and I will reconsider my decision. Kireeti.
