Re: 365x24x7
My guys work 12 hour shifts. 2 days on, 2 days off, 3 days on, 2 days off, 2 on 3 off. The three days on is always friday-sunday so every other weekend they either have a 3 day weekend or 3 days of work. In a pay period, with 30 minute lunch per shift it comes to 80.5 hours. I keep my guys on the same shifts for consistancy. Aaron Sent via DROID on Verizon Wireless -Original message- From: Steven Bellovin s...@cs.columbia.edu To: frnk...@iname.com Cc: NANOG nanog@nanog.org, dcroc...@bbiw.net Sent: Mon, Apr 18, 2011 04:12:04 GMT+00:00 Subject: Re: 365x24x7 On Apr 17, 2011, at 11:47 20PM, Frank Bulk wrote: Timely article on the FAA's involvement with sleep schedules: http://www.ajc.com/news/air-traffic-controller-scheduling-913244.html Union spokesman Doug Church said up to now, 25 percent of the nation's air traffic controllers work what he called a 2-2-1″ schedule, working afternoon to night the first two days, followed by a mandatory minimum of eight hours for rest before starting two morning-to-afternoon shifts, another eight or more hours for sleep, then a final shift starting between 10 p.m. to midnight. Maybe we need to work in more time for rest, Church said. You’re forcing yourself to work at a time when the body is used to sleeping. Also see http://www.google.com/hostednews/ap/article/ALeqM5hstTegGafIYTakRavF4WEEPblz-Q?docId=f174db27ddb44dadbcad8419dfe138a7 People who change shifts every few days are going to have all kinds of problems related to memory and learning, Fishbein said. This kind of schedule especially affects what he called relational memories, which involve the ability to understand how one thing is related to another. ... Controllers are often scheduled for a week of midnight shifts followed by a week of morning shifts and then a week on swing shifts. This pattern, sleep scientists say, interrupts the body's natural sleep cycles. --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: 365x24x7
\On Apr 18, 2011, at 7:59 AM, Aaron Wendel wrote: My guys work 12 hour shifts. 2 days on, 2 days off, 3 days on, 2 days off, 2 on 3 off. The three days on is always friday-sunday so every other weekend they either have a 3 day weekend or 3 days of work. In a pay period, with 30 minute lunch per shift it comes to 80.5 hours. I keep my guys on the same shifts for consistancy. Aaron My wife is a nurse working second shift, 12-hour shifts, 7p-7a (actually 6:45p to 7:15a to allow for a little overlap). Her hospital has it worked out on a 6-week schedule, with Wednesdays being the new pay week. Nurses there work 3 days a week, for 36 hours. Here's how they do it (these are calendar weeks) Week 1 - Su M T F Sa Su Week 2 - W Week 3 - M T W Week 4 - M T F Sa Su Week 5 - Th Week 6 - M T I know this is also a decades-long struggle in the railroad industry too (My business does a lot of contract work with that industry). In particular locomotive engineers and conductors. 100 percent on-call, maximum 12-hours on duty with 10 off (recently changed from 8). Fatigue is quite critical there too, you don't want an engineer falling asleep pulling a train full of HazMat. For datacenter work, I'd think a schedule like the above would be doable. You end up working every third weekend, and yes, weeks 1 and 4 aren't pleasant, it's followed by a 1-day week so you've got plenty of time to recover. -Andy
Re: 365x24x7
In my previous life at a large backbone provider's managed security services SOC/NOC we had the following: Shifts where divided into front and back half with 10 hour days. Front and back half segments of the shift where also split with half working Sun-Wed and half working Mon-Thur alternating. That had them alternating weekend coverage but also alternating 4 day and 2 day 'weekends'.One shift lead did M-F 8 hour days and was primary escalation for their reports during off hours/weekends, with the lead having to fill any emergency schedule holes. This provided shift overlap to cover issue hand offs and had everyone in the office Tue-Thur to cover meetings, training, any large projects, etc.At min the shifts where 9 staff (4 front half, 4 back half, and the team lead).So 27 min staffing.We normally had some additional folks per shift and they would do M-F 8 hours like the lead or fill a gap on weekends and flex the overages during the week during the mid week overlap. We did do the 30 day rotation of changing to the next shift (ie Morning - Days - Midnight - Morning) but once we got beyond staffing with 20 year old single guys it was basically impossible to keep someone very long who was willing to do that as it kills any outside activities like taking classes, kids schedules, etc.) -- --- James M Keller
Re: 365x24x7
The best schedule I ever worked for this was divided into essentially 2 teams: SMTW and WTFS There were 3 shifts on each team, though, that could be load adjusted by creating additional time slots. The nice thing about the SMTW/WTFS structure was that we always had overlap on Wednesday which we would take advantage of for training, maintenance, or other crew-heavy things that occasionally needed to get done. Training would take 2 weeks with the A-shfit one week and the B shift the following week (or vice versa). We ran 10-hour shifts (there's a provision for 4 10 hour shifts not involving overtime pay if agreed ahead of time). Shifts ran 9p-8a, 6a-5p, and 11a-10p with the crews staggering their lunches. Owen
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
On 2011-04-13 21:13, Jeff Wheeler wrote: Plain and simple, it does not scale up any better than injecting more routes into the DFZ, unless you 1) accept macro-flow-based routing; or 2) scale up the size of your FIB along with the much larger number of prefixes which would be introduced by lowering the barrier-to-entry for multi-homing and provider-independent addressing. LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants do drag around the world and advertise in a number of places, specially with IPv6. And that's exactly what LISP had in mind - to prevent massive explosion of FIB for IPv6. For IPv4 the battle was lost somewhat already - and even for that, with LISP you can actually reverse the trend, by moving back with the allocations. As the control plane of the whole system is moved off the edge routers into potentially very capable servers, you also have the extra potential of actually shaping the policies for traffic engineering dynamically without affecting routing nodes. We may of course argue that the current routers are pretty capable in terms of processing power for control-plane, but the convergence times for exchanging and calculating prefixes for VPNs in a large (1-2-3-5M+) L3VPN deployments are counted in tens of minutes, not in seconds. Calculating them offsite and just dumping per-router-calculated table would be more efficient and faster. However, LISP does have non-Internet applications which are interesting. You can potentially have multi-homed connectivity between your own branch offices. If the LISP is deployed by commercial entities, just as Google and Facebook are experimenting right now, LISP would also mean multihoming, load-balancing and trafic engineering options that are today not available with BGP or highly limited in the accuracy. Beyond non-Internet applications such as this, I think LISP is useful largely as a case study for what happens when a bunch of engineers get together and solve some problems they do not understand -- DFZ size/growth being chief among them. Can't comment on that. I personally find Vince Fuller, Dino Farinacci, Dave Meyer and Darrel Lewis quite knowledgeable in routing and proficient in explaining why the LISP was created in the first place, but you of course may know better. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net
Re: Easily confused...
--- na...@jima.tk wrote: From: Jima na...@jima.tk On 2011-04-16 20:06, Michael Painter wrote: Brielle Bruns wrote: I'm assuming your provider's network engineers (stupidly) assumed 123.x.x.x was a good idea for use in a private setup because it hadn't been assigned from the global pool (yet). Wouldn't be the first provider or service to not use proper RFC assigned private IP space for their internal networking setup. Apologies...missed operative word 'internal'.s I was about to reply pointing that out. FWIW, they're not announcing that space, so I definitely agree with the poorly-thought-out private infrastructure theory. http://bgp.he.net/AS36149#_prefixes FWIW. --- When I was last there there was a definite lack of folks with hands-on experience managing that size of address space: a /15 and two /16s plus some swamp. Further there're a lot of companies that contract to them that suggest these things and the contractor's advice is always faithfully followed, so any blame will go to the vendor if trouble happens due to design flaws. Making waves by saying this or that is wrong definitely gets one into hot water... ;-) --- They are testing IPTV on Oahu in preperation for roll-out, so maybe they renumbered in order to more easily identify the segments.(?) Really, I'd have hoped they'd use their two-year-old 2607:f9a0::/32 for anything that ambitious...but I might be wishing for too much. (Also, that 123 block seems to have been allocated in 2006, so it'd be even more unprofessional to start projects with that space since then.) I'm the one that got this space for them, but allocation of folks to IPv6 roll out was minimal due the the upcoming IPTV roll out. I was the lone IPv6 voice in the company for a long time, but when I left there was gaining interest in IPv6 strategies. Not enough netgeeks and too many projects rolling out. scott
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
2011/4/18 Lukasz Bromirski luk...@bromirski.net: LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants I strongly disagree with the assumption that the number of locations/sites would remain static. This is the basic issue that many folks gloss over: dramatically decreasing the barrier-to-entry for multi-homing or provider-independent addressing will, without question, dramatically increase the number of multi-homed or provider-independent sites. LISP solves this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR. In addition, the current negative mapping cache scheme is far from ideal. I've written a couple of folks with a provably superior scheme (compared to existing work), and have received zero feedback. This is not good. We may of course argue that the current routers are pretty capable in terms of processing power for control-plane, but We agree that the ability to move tasks from the router to an external control plane is good. BGP may get better at this as time goes on, too. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
On 2011-04-18 21:18, Jeff Wheeler wrote: I strongly disagree with the assumption that the number of locations/sites would remain static. It would grow, nobody said it would remain static. But still - it will grow slower than the number of new full allocations - covering both location *and* id. LISP solves this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR. Scalability is one of the points traditionally left for the end, but that's hardly different from any protocol that was designed and then put into mainstream use. Second - you actually don't know that for sure - the mix of from LISP and from normal IP traffic would change in time, and the natural grow of the capabilities with the higher adoption would propably also affect ITR/ETR scalability numbers. In addition, the current negative mapping cache scheme is far from ideal. I've written a couple of folks with a provably superior scheme (compared to existing work), and have received zero feedback. This is not good. You mean LISP authors? -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
In a message written on Mon, Apr 18, 2011 at 08:44:03PM +0200, Lukasz Bromirski wrote: LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants do drag around the world and advertise in a number of places, specially with IPv6. And that's exactly what LISP had in mind - to prevent massive explosion of FIB for IPv6. I would agree with this statement if and only if you qualified it with for the default free zone (DFZ). LISP reduces the number of routes in the DFZ by making each route represent a location. However, like the proverbal balloon, when squeezed on one end the other side gets larger. LISP does this by introducing an entirely new infrastructure, the mapping servers. These must now scale to meet the demands that will be placed on them. LISP also does this by making the edge box responsible for looking up and caching information on the flows going through it. In this way LISP, on a worldwide basis, very closely resembles a Cisco 7500 Chassis circa 1996 with flow caching. The mapping servers are the RP, the DFZ is the backplane, and the edge boxes are the linecards. In both designs when the first packet comes in a lookup is made to the central authority, and a cache entry is placed down at the entry processor. The backplane is dumb and fast. Anyone familar with then enviornments where a 7500 performed poorly should be able to immediately detect where a LISP architecture will perform poorly. Any events which invalidate the cache will result in a period of extremely high usage on the mapping servers likely with extremely high packet loss until all entries are resolved. Any edges which talk to a significant number of other networks will have to cache a significant portion of the Internet, which will actually lead to edge boxes having to be larger than they are now. It is the last point I find most interesting about LISP. Today someone who wants to route their own address space at 10G can buy any number of cheap L3 devices with enough RAM and CPU to hold the internal routes and a default pointed at their provider. The provider's boxes keep the full table and move the packets to where they need to go. In a LISP world that edge box would be set up to do map/encap, and thus would need to keep cache entries for all active addresses, which for a busy site is potentially the entire table. The service provider box now no longer needs to know about all destinations, and thus can have a smaller table or be upgraded less often. [Note, while I describe the edge here as customer owned, it's entirely possible it may be ISP owned and managed for the customer, a cost of which I'm sure they would fully pass on.] To my mind then, LISP moves these tables from a few thousand DFZ routers managed (generally) by well staffed engineering teams to tens or hundreds of thousands of edge boxes, in many cases managed by the clueless. Many edge proponents will say it's easier to upgrade the edge than the core, so this is a win. Vendors may like the idea of 100,000 boxes needing the resources to hold most of a table, rather than 1,000. If the Internet had started out with a LISP design from scratch I'm not sure it would be any better, or worse than our current configuration. Back to the balloon, it trades cost and complexity in one area for cost and complexity in another area. In that sense I am neither against it nor for it, it's just 'different'. The problem is we don't live in a LISP world. To go there now would be a wholesale conversion from what we are doing. Granted, the LISP folks have designed something that is relatively easy to convert to, so they are making an effort. Still, to justify a conversion and the engineering time and business risk it would have to be significantly better. Like 2x-4x better, and preferably an order of magnitude. That's where I'm just not seeing it with LISP, yet. I hope the LISP guys keep working on this, they are at the moment the only credible alternative I've seen to our current system in my lifetime. It's just not good enough to justify a switch based on the current world conditions and state of the solution; at least to me. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp39zySXoAYi.pgp Description: PGP signature
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
On Apr 18, 2011, at 12:18 PM, Jeff Wheeler wrote: 2011/4/18 Lukasz Bromirski luk...@bromirski.net: LISP scales better, because with introduction of *location* prefix, you're at the same time (or ideally you would) withdraw the original aggregate prefix. And as no matter how you count it, the number of *locations* will be somewhat limited vs number of *PI* address spaces that everyone wants I strongly disagree with the assumption that the number of locations/sites would remain static. This is the basic issue that many folks gloss over: dramatically decreasing the barrier-to-entry for multi-homing or provider-independent addressing will, without question, dramatically increase the number of multi-homed or provider-independent sites. Done properly, a multi-homed end-site does not need to have its own locator ID, but, could, instead, use the locator IDs of all directly proximate Transit ASNs. I don't know if LISP particularly facilitates this, but, I think it would be possible generically in a Locator/ID based system. LISP solves this problem by using the router's FIB as a macro-flow-cache. That's good except that a site with a large number of outgoing macro-flows (either because it's a busy site, responding to an external DoS attack, or actually originating a DoS attack from a compromised host) will cripple that site's ITR. The closer you move the ITRs to the edge, the less of an issue this becomes. Owen
eigrp set next hop
Hi nanog I need to advertise EIGRP route with a different next-hop value than self Due to how the connections are setup, I have to run BGP between two peers that are 3 hops away from each other. router1--router2--firewall--router3 I'm running EBGP between router1 and router3 router1 is redistributing into EIGRP that's running with router2 The problem is that now router2 thinks that router3 routes are reachable via router1 so I have myself a route loop. Is there a way to advertise an EIGRP route with next hop of router3 (or firewall for that matter) rather than router1 which is what EIGRP does by default Thank you in advance for advice. -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
On 2011-04-18 21:50, Leo Bicknell wrote: To my mind then, LISP moves these tables from a few thousand DFZ routers managed (generally) by well staffed engineering teams to tens or hundreds of thousands of edge boxes, in many cases managed by the clueless. This is something out of practical world that would have to be considered obviously. OTOH it is the prefix originating site that controls who and how will see the prefixes, not the traffic source site. Having control over what and to whom you advertise, you have the capability to not being announced to the clueless. The problem is we don't live in a LISP world. To go there now would be a wholesale conversion from what we are doing. Granted, the LISP folks have designed something that is relatively easy to convert to, so they are making an effort. The LISP adventure is not as simple as go from A to Z - it may end up today if the test network decides to disband with no hurt to anyone. It may decide to go on and convert only the sites willing, which is actually what happens right now - giving benefits to users, and normal service for anyone else. -- There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about. John von Neumann |http://lukasz.bromirski.net
IPv4 address exchange
Has this been discussed here? I did a quickie search and saw nothing. Other than spam to a technical mailing list, do you guys care, or is it a non-issue? scott --- Begin forwarded message: From: Martin v. Löwis mar...@v.loewis.de To: apnic-t...@lists.apnic.net Subject: [apnic-talk] IPv4 address exchange Date: Mon, 18 Apr 2011 22:07:59 +0200 With the address pool exhausted in APNIC for regular allocations, service providers will need a way to acquire additional address blocks for deployment; by discovering resources that are currently unused (or can be released by the current user with sufficient effort). In order to promote such address transfers, we are offering the Asia-Pacific region a platform, at http://tradeipv4.com/ While this platform is designed to ultimately allow transfer of addresses within and across all regions of the world, we expect that interest within the APNIC community will be largest, hence this announcement. Kind regards, Martin v. Löwis ___ apnic-talk mailing list apnic-t...@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk
Re: IPv4 address exchange
Yes... See ARIN NRPM 8.3 and Simplified Transfer Listing Service (STLS). http://www.arin.net If you want to see changes to these, suggest submitting policy via ARIN PPML or suggestions via the ARIN Consultation and Suggestion Process (ACSP). Both are documented at the above web site. Owen On Apr 18, 2011, at 3:57 PM, Scott Weeks wrote: Has this been discussed here? I did a quickie search and saw nothing. Other than spam to a technical mailing list, do you guys care, or is it a non-issue? scott --- Begin forwarded message: From: Martin v. Löwis mar...@v.loewis.de To: apnic-t...@lists.apnic.net Subject: [apnic-talk] IPv4 address exchange Date: Mon, 18 Apr 2011 22:07:59 +0200 With the address pool exhausted in APNIC for regular allocations, service providers will need a way to acquire additional address blocks for deployment; by discovering resources that are currently unused (or can be released by the current user with sufficient effort). In order to promote such address transfers, we are offering the Asia-Pacific region a platform, at http://tradeipv4.com/ While this platform is designed to ultimately allow transfer of addresses within and across all regions of the world, we expect that interest within the APNIC community will be largest, hence this announcement. Kind regards, Martin v. Löwis ___ apnic-talk mailing list apnic-t...@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/apnic-talk
Re: IPv4 address exchange
On Apr 18, 2011, at 3:57 PM, Scott Weeks wrote: Has this been discussed here? Not yet for this particular instance. I did a quickie search and saw nothing. Other than spam to a technical mailing list, do you guys care, or is it a non-issue? Unfortunately, it's an issue. It's a painfully obvious outcome of the laws of supply and demand and the inability of the RIRs to effectively evolve to meet the changing environment. As with any disruptive event (which the exhaustion of the IPv4 free pool clearly is), there will be a bit of chaos as things settle down into new patterns. On the positive side, I figure it means it will be more likely that allocated-but-unused IPv4 address space will be put back into play (since there is now a financial incentive to do so). An explicit cost for obtaining IPv4 should also help justify IPv6 deployment (since the (fixed) cost of IPv6 deployment will be able to be compared against the unpredictable but likely increasing cost of obtaining IPv4 addresses). Operationally, there are concerns, specifically how ISPs determine whether the addresses presented to them are owned by the presenter (if they care), but I understand that's already a problem (as demonstrated by Ron's postings). Interesting times. Regards, -drc
Re: IPv4 address exchange
On Apr 18, 2011, at 4:10 PM, Owen DeLong wrote: Yes... See ARIN NRPM 8.3 and Simplified Transfer Listing Service (STLS). ARIN allows the listing of non-ARIN blocks on their listing service? Also, doesn't the Microsoft-Nortel transaction violate NPRM 8.3 in that according to the court documents I've seen, Microsoft appears to have signed an LRSA (not an RSA as would seem to be required by the NPRM and as mentioned on ARIN's press release) and there doesn't appear to be anything suggesting Nortel entered into any agreement with ARIN (RSA or LRSA, however I will admit I haven't looked too closely)? If you want to see changes to these, suggest submitting policy via ARIN PPML or suggestions via the ARIN Consultation and Suggestion Process (ACSP). As far as I can tell, the participants in ARIN's processes are more interested in trying to be a regulator than in being a registry. Given ARIN is not a government body and it does not have full buy-in from those who they would try to regulate, I suspect this will directly result in a proliferation of folks like tradeipv4.com, depository.net, etc. Unfortunately, I figure this will have negative repercussions for network operations (unless someone steps in and provides a definitive address titles registry). Regards, -drc
Re: IPv4 address exchange
On Apr 18, 2011, at 6:33 PM, David Conrad wrote: Also, doesn't the Microsoft-Nortel transaction violate NPRM 8.3 in that according to the court documents I've seen, John Curran has stated unambiguously (on the ARIN PPML mailing list) that NRPM policy *was* followed. While I may disagree, at present I'm rather focused on understanding how he interprets and implements this policy. Here are my understandings at this time: Microsoft appears to have signed an LRSA (not an RSA as would seem to be required by the NPRM and as mentioned on ARIN's press release) Court documents show that a LRSA has been agreed rather than the RSA. As you point out, the actual text of NRPM requires RSA. Thus I assume that ARIN staff procedure will accept any form of RSA as satisfying this requirement, including the standard LRSA or a negotiated LRSA. (This latter possibility makes me wonder about what MSFT actually agreed to, in their version of the LRSA, and whether it will be fairly offered to all parties...) and there doesn't appear to be anything suggesting Nortel entered into any agreement with ARIN (RSA or LRSA, however I will admit I haven't looked too closely)? The court documents do not indicate that Nortel has agreed anything with ARIN. This brings to question, how were the blocks released to ARIN for transfer? In answer, John Curran has stated that the court filings satisfy this requirement without any further agreement with Nortel. Thus I assume that ARIN will accept any legal document confirming ownership and the desire to transfer. There is another aspect of NRPM 8.3 (specified transfer policy) that appears, to an outside observer, to have been ignored by this Nortel/Microsoft transfer: needs justification. However, John Curran has stated that it did occur. Somehow, according to him, Microsoft has demonstrated a need for 666,624 IPv4 addresses in the form of the exact block(s) that are being transferred. (For what it's worth, I think needs justification is bad policy for a market. My only concern here is whether ARIN follows community developed policy, as John says they have.) Cheers, -Benson
Re: IPv4 address exchange
On Apr 18, 2011, at 6:33 PM, David Conrad wrote: As far as I can tell, the participants in ARIN's processes are more interested in trying to be a regulator than in being a registry. Given ARIN is not a government body and it does not have full buy-in from those who they would try to regulate, I suspect this will directly result in a proliferation of folks like tradeipv4.com, depository.net, etc. Unfortunately, I figure this will have negative repercussions for network operations (unless someone steps in and provides a definitive address titles registry). I agree completely with this concern. Against good advice of friends (who said I would be wasting my time), I tried to do something about it: I introduced several policy proposals to ARIN that deal with the question of authority and ownership. At John Curran's advice, the ARIN Advisory Council abandoned my proposals. Two of them are now in petition for further discussion, including ARIN-prop-134 which outlines how to identify a legitimate address holder and ARIN-prop-136 which allows a Legacy holder to opt-out of ARIN's services. The idea is to make it possible for legacy holders (who don't have a contract with ARIN) to disarm ARIN's whois weapon. If anybody on NANOG supports these concepts, please express your support to PPML so that the proposals can move forward. Please see these links for more info: http://lists.arin.net/pipermail/arin-ppml/2011-April/020604.html http://lists.arin.net/pipermail/arin-ppml/2011-April/020605.html Cheers, -Benson
Re: IPv4 address exchange
On Apr 18, 2011, at 4:33 PM, David Conrad wrote: On Apr 18, 2011, at 4:10 PM, Owen DeLong wrote: Yes... See ARIN NRPM 8.3 and Simplified Transfer Listing Service (STLS). ARIN allows the listing of non-ARIN blocks on their listing service? No. If you're talking about inter-RIR transfers, then, that would be subject to draft policy 2011-1 which was reviewed at the recent Public Policy meeting in San Juan, PR and will be discussed by the AC again in May. Also, doesn't the Microsoft-Nortel transaction violate NPRM 8.3 in that according to the court documents I've seen, Microsoft appears to have signed an LRSA (not an RSA as would seem to be required by the NPRM and as mentioned on ARIN's press release) and there doesn't appear to be anything suggesting Nortel entered into any agreement with ARIN (RSA or LRSA, however I will admit I haven't looked too closely)? At the request of counsel, I am not going to comment on this. I do not have enough data available to me at this time to make any such judgment one way or the other. If you want to see changes to these, suggest submitting policy via ARIN PPML or suggestions via the ARIN Consultation and Suggestion Process (ACSP). As far as I can tell, the participants in ARIN's processes are more interested in trying to be a regulator than in being a registry. Given ARIN is not a government body and it does not have full buy-in from those who they would try to regulate, I suspect this will directly result in a proliferation of folks like tradeipv4.com, depository.net, etc. Unfortunately, I figure this will have negative repercussions for network operations (unless someone steps in and provides a definitive address titles registry). We have, on multiple occasions agreed to disagree about this, so, it should not come as a surprise that I continue to disagree with you. Owen
Re: IPv4 address exchange
At John Curran's advice, the ARIN Advisory Council abandoned my proposals. Two of them are now in petition for further discussion, including ARIN-prop-134 which outlines how to identify a legitimate address holder and ARIN-prop-136 which allows a Legacy holder to opt-out of ARIN's services. The idea is to make it possible for legacy holders (who don't have a contract with ARIN) to disarm ARIN's whois weapon. I don't agree with this characterization of our actions. I did not feel that John Curran advised us to act in any particular direction. Yes, he did raise some concerns about the outcome of the policy proposals being adopted, but, many of us already had those concerns in mind before John said anything. I believe that if the AC felt that your proposals were in the best interests of the community and/or had the broad support of the community, we would have placed them on the docket with or without the concerns expressed by Mr. Curran. I am speaking here only of my own personal perspective, but, I can assure you that my vote in favor of abandoning your proposals was based entirely on the lack of community support for the proposals and the nature of the proposals themselves being contrary to what I believed was the good of the community. Owen
Re: IPv4 address exchange
On Mon, Apr 18, 2011 at 7:33 PM, David Conrad d...@virtualized.org wrote: [ARIN] does not have full buy-in from those who they would try to regulate ARIN has all the buy-in they need: No transit network will (except by act of omission/mistake) allow you to announce IPs that aren't registered to you in an RIR database, or delegated to you by the registrant of those IPs. I am unapologetic when it comes to ARIN. They are very bad at a lot of things, and they allow themselves to be railroaded by organizations that have out-sized budgets / influence (see my post a few years ago regarding Verizon Wireless.) My list of ARIN gripes is as long as the day, but I'll spare you the details. If we didn't have ARIN, we would probably have one of two things: 1) no regulator at all, thus BGP anarchy (we came surprisingly close to that in the 1990s at least once) 2) a worse regulator who is totally uninterested in the small ISP / hosting shop / Fortune 50,000, as opposed to the Fortune 500 If ARIN's primary benefit to us is to protect us from these two unarguably worse evils, they are doing a fine job. Even from my outsider's perspective, I understand that ARIN is sometimes forced to make significant compromises, which we may find objectionable, to prevent us from being truly thrown to the wolves. Would I like ARIN to function better? Sure, in plenty of ways. I do not think it would function better if it were just a WHOIS database. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: eigrp set next hop
What's the real goal behind this? What your describing sounds like a horrible band-aid David. On Mon, Apr 18, 2011 at 5:08 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: Hi nanog I need to advertise EIGRP route with a different next-hop value than self Due to how the connections are setup, I have to run BGP between two peers that are 3 hops away from each other. router1--router2--firewall--router3 I'm running EBGP between router1 and router3 router1 is redistributing into EIGRP that's running with router2 The problem is that now router2 thinks that router3 routes are reachable via router1 so I have myself a route loop. Is there a way to advertise an EIGRP route with next hop of router3 (or firewall for that matter) rather than router1 which is what EIGRP does by default Thank you in advance for advice. -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Re: IPv4 address exchange
I introduced several policy proposals to ARIN that deal with the question of authority and ownership. ... If anybody on NANOG supports these concepts, please express your support to PPML so that the proposals can move forward. perhaps, if you are seeking support for commercial activity, you should make your employment more clear and declare any conflicts of interest. randy
Re: IPv4 address exchange
Jeff, On Apr 18, 2011, at 6:15 PM, Jeff Wheeler wrote: ARIN has all the buy-in they need: No transit network will (except by act of omission/mistake) allow you to announce IPs that aren't registered to you in an RIR database, or delegated to you by the registrant of those IPs. And yet, Ron has recently raged on this list about hijacked prefixes used for spamming, so clearly no transit network is inaccurate. Regardless, for sake of argument, let's assume ARIN refused to recognize the Microsoft/Nortel sale and Microsoft deploys a few prefixes of those 666K addresses for (say) new MSN services. Do you think ISPs, particularly the larger ones, all over the world would refuse to accept those announcements (especially when their call centers start getting calls from irate customers who aren't able to gain access to MSN services)? If we didn't have ARIN, we would probably have one of two things: Just to be clear, I don't believe the suggestion is that ARIN goes away, rather that post allocation services (e.g., reverse DNS, registration maintenance, etc.) for IPv4 no longer be a geographical monopoly. However, taking the bait: 1) no regulator at all, thus BGP anarchy (we came surprisingly close to that in the 1990s at least once) And the solution to that BGP anarchy (by which I assume you mean a flood of long prefixes) in the 1990s was some ISPs deploying prefix length filters to protect their own infrastructures. Been there, got several t-shirts. Yes, over time, the sales/marketing folks will force the network engineers to remove the filters once hardware has been upgraded, but once established, minimum prefix lengths (at least the perception of them) seem to have a long half-life. It's also true that ARIN (at least currently, before RPKI is deployed) has no control over routing policy so suggesting that they regulate BGP anarchy may not be accurate. 2) a worse regulator who is totally uninterested in the small ISP / hosting shop / Fortune 50,000, as opposed to the Fortune 500 We're talking about IPv4 addresses which will (soon) be unavailable from the RIRs because the free pool has been exhausted. The small ISP/hosting shop/Fortune 50,000 who have not already taken steps to adjust to this new reality will simply be screwed regardless of what ARIN or the other RIRs do. Even if alternative post allocation services providers didn't exist, the Fortune 500 are going to be able to pay more to the folks with allocated-but-unused addresses than the 'all but Fortune 500' and I have no doubt that the Fortune 500 will be able to justify need (to any level of detail) just as well as the 'all but Fortune 500'. Or do you believe ARIN et al. will be establishing price caps and establishing who among the various requesters for the same block deserves to get the SLS seller's blocks? What a bunch of folks seem to have gotten their panties in a bunch about is the idea that without our Benevolent RIR Overlords, Enron-wannabes are going to go around and buy up all the unused IPv4 address space and make a killing selling it to the highest bidder. I'm afraid I haven't been able to get worked up about this: the only difference between the world with the BRO and without I can see is who gets the money (and this is ignoring the debate as to whether speculators can encourage bringing more addresses into play since their sitting on lost opportunity cost of they simply hoard IPv4 addresses). I find the whole discussion quite odd: laws of economics are pretty clear about situations with limited supply and increased demand and the reality is that ARIN is not a regulator and has essentially no enforcement mechanisms outside of contractual relationships. It is a 501(c)(6) consisting of 3865 members, of which a couple of hundred technical folks participate in policy definition processes that affect tens of millions of people, the vast majority of which have never heard of ARIN. As long as the policies ARIN defined by the technical folk don't affect folks with money/power in negative ways, everything is fine. That time is just about over. People really need to adjust. I do not think it would function better if it were just a WHOIS database. To try to bring this back to NANOG (instead of PPML-light), the issue is that since at least two alternative registries have apparently been established, how are network operators going to deal with the fact that the currently execrable whois database is almost certainly going to get worse? Regards, -drc
Re: IPv4 address exchange
Hi, Randy. On Apr 18, 2011, at 9:20 PM, Randy Bush wrote: I introduced several policy proposals to ARIN that deal with the question of authority and ownership. ... If anybody on NANOG supports these concepts, please express your support to PPML so that the proposals can move forward. perhaps, if you are seeking support for commercial activity, you should make your employment more clear and declare any conflicts of interest. Fair enough. I am employed by Cisco Systems, but all of my statements are my own and I do not represent my employer. I believe that my employer may benefit from any policy that makes IP addresses more available to more of our customers - we can perhaps sell more routers if more people have addresses - but nobody from Cisco has encouraged me to work in this topic. Otherwise, I have no commercial interest in the outcome of the policy proposals that I've made. The proposals that I've put forward are an honest attempt to motivate conversation. If anybody has any doubts and/or I can clarify anything about my interests, let me know. Cheers, -Benson
Re: eigrp set next hop
How many bgp prefixes do you have? Can you just put statics on router 2? On Apr 18, 2011, at 8:26 PM, David Swafford da...@davidswafford.com wrote: What's the real goal behind this? What your describing sounds like a horrible band-aid David. On Mon, Apr 18, 2011 at 5:08 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: Hi nanog I need to advertise EIGRP route with a different next-hop value than self Due to how the connections are setup, I have to run BGP between two peers that are 3 hops away from each other. router1--router2--firewall--router3 I'm running EBGP between router1 and router3 router1 is redistributing into EIGRP that's running with router2 The problem is that now router2 thinks that router3 routes are reachable via router1 so I have myself a route loop. Is there a way to advertise an EIGRP route with next hop of router3 (or firewall for that matter) rather than router1 which is what EIGRP does by default Thank you in advance for advice. -- Andrey Khomyakov [khomyakov.and...@gmail.com] Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
Re: eigrp set next hop
The goal is to withdraw the prefixes should any part of the connection go down. Unfortunately router1--router2--firewall is part of a production setup and not easily changed. The idea is really to have something like this (ideally without router2): router1-router2-firewall-router3 | | router4-firewall-router5 I just wanted to check if I'm missing some knowledge about redistributing BGP into EIGRP. It appears that there is really no way to manipulate next-hop value. (no ip next-hop-self eigrp 1 is not really an option because there are many more prefixes coming from other routers that are being redistributed to router2 from router1) I will see if the network will allow BGP on router2. That seems to be the only clean solution for this. On Mon, Apr 18, 2011 at 9:25 PM, David Swafford da...@davidswafford.comwrote: What's the real goal behind this? What your describing sounds like a horrible band-aid David. On Mon, Apr 18, 2011 at 5:08 PM, Andrey Khomyakov khomyakov.and...@gmail.com wrote: Hi nanog I need to advertise EIGRP route with a different next-hop value than self Due to how the connections are setup, I have to run BGP between two peers that are 3 hops away from each other. router1--router2--firewall--router3 I'm running EBGP between router1 and router3 router1 is redistributing into EIGRP that's running with router2 The problem is that now router2 thinks that router3 routes are reachable via router1 so I have myself a route loop. Is there a way to advertise an EIGRP route with next hop of router3 (or firewall for that matter) rather than router1 which is what EIGRP does by default Thank you in advance for advice. -- Andrey Khomyakov [khomyakov.and...@gmail.com] -- Andrey Khomyakov [khomyakov.and...@gmail.com]
Re: IPv4 address exchange
perhaps, if you are seeking support for commercial activity, you should make your employment more clear and declare any conflicts of interest. Fair enough. I am employed by Cisco Systems, but all of my statements are my own and I do not represent my employer. I believe that my employer may benefit from any policy that makes IP addresses more available to more of our customers - we can perhaps sell more routers if more people have addresses - but nobody from Cisco has encouraged me to work in this topic. Otherwise, I have no commercial interest in the outcome of the policy proposals that I've made. The proposals that I've put forward are an honest attempt to motivate conversation. On the contrary, I believe router vendors including but not limited to Cisco benefits more from IPv4 address exhaustion, as it's an opportunity to sell new gear that can do hardware forwarding of IPv6 packets, or sell software upgrades to CPU-based platforms (either due to lack of IPv6 altogether or lack of support of newer IPv6 features). That doesn't mean that router vendors are promoting address exhaustion chaos to get new business. That would be a nice conspiracy theory, though... Rubens
Re: IPv4 address exchange
If anybody has any doubts and/or I can clarify anything about my interests, let me know. could you please clarify your relationship to depository.com? randy
Re: IPv4 address exchange
On Mon, Apr 18, 2011 at 10:35 PM, David Conrad d...@virtualized.org wrote: And yet, Ron has recently raged on this list about hijacked prefixes used for spamming, so clearly no transit network is inaccurate. I try to qualify my remarks when necessary. In this case, I wrote except by act of omission/mistake, and you evidently did not read that carefully, or have construed transit network to mean any two-bit ISP with one BGP customer (or shell company downstream of them), rather than serious, global networks. Regardless, for sake of argument, let's assume ARIN refused to recognize the Microsoft/Nortel sale and Microsoft deploys a few prefixes of those 666K addresses for (say) new MSN services. Do you think ISPs, particularly the larger ones, all over the world would refuse to accept those announcements (especially when their call centers start getting calls from irate customers who aren't able to gain access to MSN services)? ARIN has very carefully allowed our industry to largely avoid this choice, as InterNIC did before. Their methods have sometimes been objectionable, but the devil we know is better than the devil we don't. 1) no regulator at all, thus BGP anarchy (we came surprisingly close to that in the 1990s at least once) And the solution to that BGP anarchy (by which I assume you mean a flood of long prefixes) No, I mean if ARIN had lost its perceived or actual legitimacy, and networks really were able to permanently hijack whatever IPs they decided to claim for themselves, we would have had anarchy at worst, or more likely, transit-free ISPs with commercial interest in customers not having portable address space controlling all allocations of portable addresses. This almost happened. We're talking about IPv4 addresses which will (soon) be unavailable I'm not confused about that. If it were up to me, I would simply freeze all IPv4 allocations immediately. I do not think the current sale-and-transfer scheme is good. I also don't *care* that much, because the more screwed up the legacy IPv4 Internet becomes, and the faster it gets there, the better it is for my business. I'm pretty sure I am not alone in this thinking. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts
Re: IPv4 address exchange
On Mon, Apr 18, 2011 at 18:59, Owen DeLong o...@delong.com wrote: At John Curran's advice, the ARIN Advisory Council abandoned my proposals. Two of them are now in petition for further discussion, including ARIN-prop-134 which outlines how to identify a legitimate address holder and ARIN-prop-136 which allows a Legacy holder to opt-out of ARIN's services. The idea is to make it possible for legacy holders (who don't have a contract with ARIN) to disarm ARIN's whois weapon. I don't agree with this characterization of our actions. Nor do I. Those that wish to understand the ARIN Advisory Council's actions in earnest can find the results of the AC meeting in question here: [http://lists.arin.net/pipermail/arin-ppml/2011-March/020373.html] and the minutes from that meeting, here: [https://www.arin.net/about_us/ac/ac2011_0317.html]. You are also welcome to ping me off-list (or on arin-ppml) if you are interested in a further explanation of my own reasons for voting to abandon the proposals in question. Cheers, ~Chris I did not feel that John Curran advised us to act in any particular direction. Yes, he did raise some concerns about the outcome of the policy proposals being adopted, but, many of us already had those concerns in mind before John said anything. I believe that if the AC felt that your proposals were in the best interests of the community and/or had the broad support of the community, we would have placed them on the docket with or without the concerns expressed by Mr. Curran. I am speaking here only of my own personal perspective, but, I can assure you that my vote in favor of abandoning your proposals was based entirely on the lack of community support for the proposals and the nature of the proposals themselves being contrary to what I believed was the good of the community. Owen -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
Re: 365x24x7
On 15/04/11 6:14 AM, harbor235 wrote: If I were going to provide a 365x24x7 NOC, how many teams of personnel do I need to fully cover operations? I assume minimally you need 3 teams to cover the required 24 hr coverage, but there is off time and schedule rotation? thoughts, experience? There have been a lot of comments that talk about the operational issues, and about how well it works or doesn't work to rotate schedules. In my experience, the most important thing to do is to decide how you are going to setup the schedules BEFORE you hire. Then advertise for the exact work schedule(s) you need to fill, and pay an appropriate shift differential so that you get people who are happy to work the worst shifts for slightly better pay. People don't like being treated like slaves, expected to just shut up and work a crappy schedule. You will have a much more reliable team if you treat the staff like valued members of your company, don't try to trick them or over work them, or expect them to disrupt their lives over and over as your shifts change. Some people are naturally night-owls - find them and hire THEM for the swing and night shifts. Also, don't forget that your 24x7x365 staff will have to work holidays, and be sure to work in an appropriate holiday bonus pay schedule as well. Otherwise expect to eventually have a bad case of the blue flu someday and end up having to call managers (directors/ VPs, YOU) away from their holiday with their family to keep your NOC staffed. jc
Re: 365x24x7
On Sun, Apr 17, 2011 at 8:00 AM, Jay Ashworth j...@baylink.com wrote: The TV master control facility in which I'm working presently does it by doing overlapping 10 hour shifts; it takes 10 people to have 2 on-shift at all times. You work 6 hours with one person, and 4 with the other. My brother-in-law once had a job tending a TV relay station; the shift was drive up the mountain, work 48 hours, drive back, but unless something was broken he only had to read meters every three hours and could nap in between. Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
