practical subnet sizes smaller than /26, /27, ...
I'm looking for research / surveys on how enterprises and service providers really use subnetting within their networks. In particular, I'm interested in the size of subnets that people are regularly using and I'm interested in both public and private addressed networks (which I'm assuming, perhaps incorrectly, to be different). Note that I'm not looking for best practice or what's possible - I'm interested in what people actually do. Any pointers appreciated. Please respond to me directly - if people are interested, I'll summarize any answers I get and repost to the list. Also, if you think there is a more appropriate place for this question, please let me know. Thanks, John --- Network Appliance Inc. Tel: +1 347 613 2259 230 Park Avenue, Suite 834 Voicemail: +1 408 822 8606 New York, NY 10169 USA ---
Re: recommendation against publication of draft-cerpa-necp-02.txt
I have held off commenting until I saw what the IETF community at large would have to say. Disclosure: I work for Network Appliance, was involved in the very early stages (though not latterly) of NECP and fully support its publication as an Informational RFC. I am also co-chair of WREC. As has happened when this document was previously discussed by the IESG, the discussion inevitably takes a turn towards a discussion of "transparent" caching (latterly renamed "interception proxies" by WREC). Let me be absolutely clear, NECP is about communication between server load-balancers (SLB) and the back-end servers they speak to. Nothing more, nothing less. The fact that one common use of these is for caching proxies, and that these are used as an example, does not mean that NECP in any way specifies how "transparent" or "redirection" takes place. [In fact, the most common deployment of these type of service load balancers is non-transparent (i.e. where the user configures their browser with a proxy IP address which is, in fact, a load-balancing element talking to a number of back-end servers). For a discussion of "transparent" versus "non-transparent" proxies, please refer to draft-ietf-wrec-taxonomy-03.txt.] However, that is by far not the only application. DNS, web servers and firewall load balancing are the three other main applications for SLBs. Now, let me address each of the original concerns in turn. Note that I have done this privately to Keith on many occasions as well as to the IESG, IAB and others on the WREC WG list. At 12:41 PM 06/04/00 -0400, Keith Moore wrote: >1. The document repeatedly, and misleadingly, refers to NECP as a >standard. I do not believe this is appropriate for a document >which is not on the IETF standards track. It also refers to >some features as "mandatory" even though it's not clear what >it means for a non-standard to have mandatory features. The document is not an IETF standard but it does describe a protocol. For protocols to work correctly, there must be certain "mandatory" minimal requirements on those implementing that protocol. I can see one or two places where the word "standard" might be misinterpreted by readers if used out of context. Section 5.2, 5.2.1, 5.2.2, 5.5.1 "The version number of the protocol defined by this standard is 1." "All implementations that adhere to the standard specified in this document MUST set the version number to 0x1." "This type of payload has no structure imposed by this standard." "For reasons explained in Section 6.11, this standard only defines a single performance query type that MUST be implemented by all NECP nodes:" I see no problem with changing these. In most cases, simply replacing the word "standard" with the word "protocol" would convey the correct meaning beyond any reasonable doubt. >2. A primary purpose of the NECP protocol appears to be to >facilitate the operation of so-called interception proxies. Wrong. The primary purpose of NECP is to facilitate a load-balancing between SLBs and the services to which they direct traffic. "so-called interception proxies" are just one such service. >Such proxies violate the Internet Protocol in several ways: This is not about those proxies - that is a different argument. I don't think it is appropriate to be drawn into an argument about the rights and wrongs of "interception proxies" when discussing NECP. I am more than happy to justify their existence - with hard facts, of course - in a separate thread. Regards, John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: prohibiting RFC publication
At 10:39 AM 10/04/00 -0400, Keith Moore wrote: > > The I-D in question has been referred to an existing IETF WG for review, > >that assertion was made, but not confirmed by the ADs. >is it really true? it seems odd because it really isn't in scope for wrec. Let me jog your memory: At 06:29 PM 30/12/99 +0100, Patrik Fältström wrote: >A request has arrived to publish the named document as informational RFC. >The IESG wants all documents in this area to explicitely pass the WREC >working group, ... I then sought clarification, re-sent the document to WREC (it had been sent before), to determine if there was a conflict - there wasn't. The authors re-submitted it. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: prohibiting RFC publication
At 02:21 PM 10/04/00 -0400, Keith Moore wrote: > > > > The I-D in question has been referred to an existing IETF WG for > review, > > > > > >that assertion was made, but not confirmed by the ADs. > > >is it really true? it seems odd because it really isn't in scope for > wrec. > > > > Let me jog your memory: > >yes, I remember that wrec said there wasn't a conflict with its work. >that's not the same thing as wrec discussing whether the approach >is technically sound or whether the document is worthy of publication. I appreciate that you cannot attend every working group meeting but the document, the approach and the implementation were discussed at all but one WREC face-to-face meeting and on the mailing list. We received comments and made changes as a result of discussions on WREC. Note: many of those who are / were active within WREC were / are also active in discussing NECP. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
interception proxies
There has been a lot of discussion about the problems associated with so-called "interception proxies". This discussion is very much within the charter of the WREC WG. In fact, we even have a current draft whose sole purpose is to document such problems. The known problems draft is at: draft-ietf-wrec-known-prob-01.txt This is the first of two very useful documents being produced by WREC; the first, a taxonomy of terminology is available as: draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. To join WREC, use the following: mailto:[EMAIL PROTECTED]?Subject=subscribe ...or send a note to [EMAIL PROTECTED] with "subscribe" in the subject. I suggest we move this particular discussion to WREC. Rgds, John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: interception proxies
Vernon, At 04:47 PM 11/04/00 -0600, Vernon Schryver wrote: >Call me a non-team playing scab, but I refuse to the honor the old guild >work rule that limits the questions I can consider. If sourcing >other-owned etc. or anything else is an architectural or other problem, >then professional pride ought to force one to raise the issue insetad of >waiting for the AD, IESG, IAB, or a plenary to redirect things. But I >realize that's a minority view, and not just in IETF working groups or >even the IETF. When WREC was originally proposed to the IESG, its scope was much broader. Since the area was, at the time, the subject of much confusion, our charter was changed by the IESG to begin with a taxonomy and a list of known problems with caching and replication as is done today. At the time, I disagreed but complied. With hindsight - and given recent discussions - I think that their decision was correct. (If for no other reason that we now know what to call these "interception proxy" things). Most of us who started WREC have indeed an interest in caching and replication but not necessarily "interceptions proxies". This type of proxy is only one way to do caching / replication - and certainly by no means the most common. (The most common - by far - are actually standard, run-of-the-mill proxies configured explicitly in users' browsers). Rgds, John (WREC co-chair) --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: interception proxies
Keith, At 07:59 PM 11/04/00 -0400, Keith Moore wrote: > > This was a choice - in some larger sense, if sourcing other-owned IP > > addresses or TCP connections is considered an architectural problem, > > needs to come down from above, rather than up from WREC. > >sounds like a convenient excuse to me... >where did the wrec folks get the idea that the IP specification was obsolete? I'm not sure what you are trying to say here but as co-chair of WREC, I can tell you that such a concept was never discussed. We stuck pretty rigidly to our charter, in fact. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: recommendation against publication of draft-cerpa-necp-02.txt
At 04:45 PM 11/04/00 -0700, Eliot Lear wrote: >I wonder if any of the authors has explored the risks of modifying data in >flight. How could this be abused by interlopers and evil doers? If I >could hack into a router implementing NECP, what damage could I do? Could >I start a nasty little JavaScript/Java/Shockwave/... applet in an >advertisement? >And who would know it was me? Do you mean the authors of NECP? If so, then I'm confused because NECP is not about "modifying data in flight" - it is about load balancing multiple services which sit behind e.g. a single IP address. (i.e. DNS server farms, firewalls, proxies). As I have said repeatedly, "interception proxies" is only one of these applications and by no means the most widely used. Are you confusing this with WCCP (which *only* works with "interception proxies"). >Quoth John Martin: > > [...] > > Let me be absolutely clear, NECP is about communication between server > > load-balancers (SLB) and the back-end servers they speak to. > >Were this so clear in your document my mailbox wouldn't be full of this >stuff. The very first sentance says: "This document describes "NECP", a lightweight protocol for signalling between servers and the network elements that forward traffic to them. It is intended for use in a wide variety of server applications, including for origin servers, proxies, and interception proxies." Despite the fact that "interception proxies" are listed last, they are the only service people are talking about. But, you are right in general: if this is how people read the document, we need to fix the document. >If it looks like a duck and quacks like a duck, but it's not supposed to be >a duck, the IESG ought to point out that it's a turkey by so indicating at >the top of the document. Also, I'd like to understand why you're not going >experimental, where it would be expected that you'll correct your mistakes. >Your choice of "informational" seems unfortunate at best and as >disingenuous marketing at worst. I can't tell which. We used "informational" because we saw that this is what was used for HTTP/0.9 with which there are parallels: NECP has existed for some time already in slightly differing implementations and this is a codification of existing practice. There was no magic of deceit intended. If the IESG thinks we should instead go for experimental, I'd be more than happy to pursue that instead and bring this into WREC. However, development is not within the current WREC charter so we are stuck, I think? >The fact that you mention interception proxies in the introduction has led >to this flame war. Having used the words, you've mentioned none of the >risks associated with such services both from the server side and the >client side. OK - we can fix that. It is not the goal of NECP to describe "interception proxies" or their deficiencies. There is, however, a working group which has a document aimed at exactly that (amongst other things) - WREC. >John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: recommendation against publication of draft-cerpa-necp-02.txt
At 10:49 AM 13/04/00 -0700, Eliot Lear wrote: >Part of the problem here is that a knife may be used as a food utensil or a >weapon. Safe handling, however, is always required, and should be >documented. Granted. >I would add two other comments. I tried to locate the RFC for HTTP/0.9, >but the best I could find was a reference to a CERN ftp site for the >protocol. Ooops. s/0.9/1.0 - rfc1945. > In any case, by the time HTTP got to the IETF it was deployed >over a vast number of end stations, and comparisons to it are probably not >apt. NECP is a super-set of various load-balancing technologies already deployed at thousands of sites. >Finally, rechartering is precisely what you ought to have done, and should >do, IMHO. For the record: this is exactly what we are doing. (We were waiting for the two starter documents to be published or at least start their path via the IESG). Rgds, John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: guidance (re: social event politeness)
...and speaking of bad manners, I noticed that there is a resurgence of people talking mobile-phone calls in meetings. I was only there for one day but it happened twice in three meetings. Another annoyance is those who allow it to ring and then cancel the call (presumably using CLI or something). This is not as bad but still pretty disruptive, particularly for the person speaking at the time. Please switch them off. You shouldn't need to be asked. John --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
Re: IETF logistics
Let me give you an example of where this didn't work recently. At San Diego, we had back-to-back meetings of WREC followed by OPES BoF and CDNP BoF. For the most part, there was a very large overlap in the attendance. If you did not forgoe the coffee break and - literally! - run between the rooms, you did not get a seat. If you were silly enough to engage in even a 1 minute conversation and walk slowly, you might not have gotten into the room at all. This is of course further exacerbated by those who do the IETF equivalent of spreading their towels out on the loungers by the pool before going for breakfast... Some folks who had contributed were excluded because the doors had to be closed in order to make the meeting audible. In one case, the door was opened to admit someone who was on the agenda as speaking. I don't believe that any of the solutions offered so far will work because they depend on the good manners of strangers which, frankly, is largely non-existent at IETF meetings. So, my only suggestion is that WG chairs strongly encourage work to be done on the mailing lists, a deference towards non-presentation formats and the strong enforcement of timelines in meetings which is, erm, what we're supposed to encourage anyway... John At 07:35 AM 20/12/00 -0800, Melinda Shore wrote: > > What happened to the proven and time-honored technique of >getting > > to a meeting early if you want a seat? I know the argument is >that > > we want to hang out in the hallways until the last minute and >still > > get a seat (because we are more "important" than a bunch of the >people > > that did get there early), but still... > >I think the problem could, in part, be alleviated >by physically ejecting from the room people either >playing games on their laptops or checking their >portfolios. > >Melinda >(and I'm not kidding) > > >- >This message was passed through [EMAIL PROTECTED], which >is a sublist of [EMAIL PROTECTED] Not all messages are passed. >Decisions on what to pass are made solely by Harald Alvestrand. --- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 ---
