RE: IP adresss management verification
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of David Hubbard > Sent: Monday, November 13, 2006 11:42 AM > To: nanog@merit.edu > Subject: RE: IP adresss management verification > > What I meant was we require a technical justification to > give a dedicated IP to a customer but many hosts do not, > or they use it as a revenue add by charging for having > a dedicated IP when there's no technical reason for it. > Previously, or maybe still, there was no mandate that web > hosts only assign dedicated IP's when it can be justified. > > David This was the topic of one of the most interesting policies ARIN ever adopted. In 2000, there was a proposal to require web hosting organizations to use virtual hosting (roughly defined as many FQDNs on one IP address), unless indidivual IP addresses were required for documented technical reasons. This proposal predates the online proposal archive, but you can track it on its progression through the Board meetings. http://www.arin.net/meetings/minutes/bot/bot2000_0612.html http://www.arin.net/meetings/minutes/bot/bot2000_1002.html There was community support for the proposal, but strong debate. The Advisory Council found consensus, the Board adopted the proposal, then a few months later suspended the policy. I think this is the only time the Board used its emergency power to set or suspend a policy. http://www.arin.net/meetings/minutes/ARIN_VI/ppm_minutes.html#webhosting On the mailing list, and at the next public policy meeting there was extensive discussion. The Advisory Council took input from the community, and decided that the best policy would be to make it a recommendation. The current policy now reads: When an ISP submits a request for IP address space to be used for IP-based web hosting, it will supply (for informational purposed only) its technical justification for this practice. ARIN will analyze this data continuously, evaluating the need for future policy changes. http://www.arin.net/policy/nrpm.html#four25 To my mind, this is a good example of the ARIN process working well: the community favored a proposal, so it was adopted, but there were significant problems. The Board suspended the policy so the AC could get community feedback, and the policy was changed based on experience. If you have an opinion on this policy, you should say so on the Public Policy Mailing List. http://lists.arin.net/mailman/listinfo/ppml Lee
RE: Spam (un)blocking
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Daniel Senie > Sent: Wednesday, April 06, 2005 6:43 PM > To: JP Velders; Adam Jacob Muller > Cc: nanog@merit.edu > Subject: Re: Spam (un)blocking > > At 06:10 PM 4/6/2005, JP Velders wrote: > > >Over here in "RIPE land" so to speak, several ISP's (most > notably FIRST > >members) have put a lot of effort in getting 'IRT' objects in the > >RipeDB. > > And this is MUCH appreciated. When trying to figure out where > to send spam > complaints, a network that's taken the time to put their > abuse address in > their records certainly appears to at least care, and so gets > better treatment. "Better" != "good." In past experience, - Since the Abuse POC was "abuse@" instead of "Lee.Howard@" it wasn't acceptable. - Because "abuse@" went to a 24x7 team, with an auto-responder, and (on advice of counsel and for scalability reasons) we did not reply to every complaint with a description of the action taken, it was assumed no action was taken. There's no pleasing some people, and it's a shame that not everyone can take the time to understand what filtering policies they're importing. YMMV Lee
RE: BGP Anywhere - Global Redundancy
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Steve Gibbard > Sent: Wednesday, April 06, 2005 8:48 PM > To: Vandy Hamidi > Cc: nanog@merit.edu > Subject: Re: BGP Anywhere - Global Redundancy > > On Wed, 6 Apr 2005, Vandy Hamidi wrote: > > > Below is how I believe it should be done. > >> From PDC: > > -Advertise CIDR block to all peers w/good metric (0 hop count) > >> From BDC: > > -Advertise same CIDR block to all peers w/poor metric (+20 hop > > count) > > To clarify, you want no traffic coming into the backup site when the > primary site is up, right? > > Assuming a random set of peers and upstreams, this won't > actually do what > I think you're trying to do. Since local-preference > overrides MEDs and AS > path lengths, and since you don't have control over what goes > on in other > networks, you'll likely get some traffic coming into your > backup site even > when you don't intend it to. > > You could *maybe* get around this by having the same transit provider > (probably just one in this case, which is scary for other > reasons) in both locations. If you're paying somebody money, you have a much > better chance of getting them to follow your desired routing policy. > Still, it's really not good to be making a routing announcement somewhere where > you don't want to receive traffic. If you have the same ISPs at both data centers, this will work. All outsiders will route to one of your ISPs, who will send traffic to the best localpref. Until one of them loses their connection to your primary site; then it will route traffic to the backup site, even though, to you, the primary is online with the other ISPs. Convergence time across the Internet in case of complete failure could be 15 minutes, +/-5. Lee > -Steve >
RE: RFC 4041
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Fergie (Paul Ferguson) > Sent: Friday, April 01, 2005 9:22 AM > To: nanog@merit.edu > Subject: RFC 4041 > > > > > Requirements for Morality Sections in Routing Area Drafts > ftp://ftp.rfc-editor.org/in-notes/rfc4041.txt I realize comments would better be directed to the appropriate IETF work area, but this seems like a natural extension to RFC3514 ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt Lee > > Cheers, > > - ferg > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > [EMAIL PROTECTED] or [EMAIL PROTECTED] >
RE: Clearwire May Block VoIP Competitors
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jared Mauch > Sent: Wednesday, March 30, 2005 7:06 PM > To: Paul Vixie > Cc: nanog@merit.edu > Subject: Re: Clearwire May Block VoIP Competitors > > On Wed, Mar 30, 2005 at 11:32:33PM +, Paul Vixie wrote: > What i've done is rate-limit TCP inbound to be around > 75-80% of the link speed to force things to back-off and > leave space for my UDP packet streams. > > I think one of the major problems is that very few > people know how to, or are capable of sending larger g711 > frames (at increased delay, but more data per packet) because > they can't set these more granular settings on their > systems.. this means you have a lot higher pps rates which I > think is the problem with the radio gear, it's just not > designed for high pps rates.. That's interesting. . . where's the intersection of the packet size curve and the latency curve? I mean, where would you set it, and can you offset some of that with fragmentation and intervleaving? I'm outside of that "very few people," but I could imagine wanting dynamic control--one packet size (latency) for a certain calling plan (calls within the LAN, maybe even to anywhere on my network if I control end-to-end QoS, and local calls) but another for long distance. > - jared Lee
RE: Clearwire May Block VoIP Competitors
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Robert Bonomi > Sent: Monday, March 28, 2005 7:05 AM > To: nanog@merit.edu > Subject: Re: Clearwire May Block VoIP Competitors > > > Dunno where you got the 'more than 2 subscribers' bit as > defining over- subscribed. Unless you > mis-read/mis-interpreted my remark about "50% > utilization" for VoIP data. Active VoIP transmission is > about 80kbps. Depends on the codec. Yes, most people default to G.711, but my experience with G.729 and header compression has been good, and closer to 12Kbps. I definitely agree that it's much more symmetrical than web traffic, and could therefore mess with someone's capacity planning. Denying traffic that doesn't conform to your engineering is one response. Re-engineering is another. Do what you will with your network, I know what I'd do with mine. Lee
RE: outage/maintenance window opinion
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Luke Parrish > Sent: Wednesday, March 30, 2005 11:29 AM > To: Pete Templin > Cc: [EMAIL PROTECTED] > Subject: Re: outage/maintenance window opinion > > > > In this situation we were expecting to be done for the > majority of the > maintenance window, but yes I see your point. However I block > out a 3 hour > window for maintenance because the activities I am performing on the > network could easily cause a longer service outage than > planned as we all > know. So if I plan for a 4 hour window but only expect 20 minutes of > downtime that actually turns into 3 hours, as long as it is > inside the > maintenance window specified then it should not go against > outage minutes. > It was done in the window for a reason... > > ?? > Luke I'd agree that as long as it's back up before the end of the window, you're covered. However, if the outage extends beyond the end of the window, I would take the the position that made me look worst. That shows how seriously you take your maintenance window, and I think this kind of integrity gives you credibility later. Lee > > > At 02:05 PM 3/28/2005, Pete Templin wrote: > >Luke Parrish wrote: > >>Trying to get clarification on an issue. > >>Maintenance/outage window is 2:00AM to 5:00AM, during the window the > >>router we are working on fails and does not come back > online until 8:00AM. > >> From a outage reporting/documentation standpoint is the > outage start > >> time 2:00AM or 5:01AM since 5:01AM is when the maintenance > window and > >> planned outage was over... > > > >To a small degree, it depends on how long you anticipated > the outage to > >be. Were you expecting a three-hour tour^h^h^h^houtage, or > something > >shorter but opened a big window to give you flexibility on > when to do > >it? I would say that a fifteen-minute expected impact means > the outage > >started at 2:15AM (or fifteen minutes after your work > interrupted services). > > > >My $0.005, > > > >pt > > Luke Parrish > Centurytel Internet Operations > 318-330-6661 >
RE: Utilising upstream MED values
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Sam Stickland
> Sent: Friday, March 18, 2005 9:05 AM
> To: [EMAIL PROTECTED]
> Subject: Utilising upstream MED values
>
>
>
> Hi,
>
> We're looking at doing outbound traffic values based on
> upstream ("tier1")
> MED values. But, of course, there's no standard for MED
> values. Assuming I
> can get definations from the upstreams as to what their MED
> values mean, I
> have to rebase them into a common range.
You've answered the question right there. Since one provides uses
apples for its MEDs, and another uses oranges, comparing them to each
other. . .
> However, a route-map (cisco, foundry) only allows you to set, add or
> subtract to an MED value, so this doesn't seem possible.
Theoretically, if you can establish a conversion constant for however
you define "far" to however ISP Apple defines it and however ISP Orange
defines it, you just have to apply that value. Match all routes
learned from AS Orange and add or subtract the conversion value. Only
works if the range of values is pretty close, though.
You *could*, if the range is small enough, write route maps to match
metric and set metric.
> Is anyone doing this, and if so how?
Or you can hack a script to do traceroutes to various arbitrary
destinations, compare to the routes learned, and evaluate the Round Trip
Time (or number of hops, or whatever) to MED, establishing your own
locally-significant table. Sounds like a lot of trouble to me, but
YMMV.
>
> Sam
>
Lee
