On Mon, Oct 19, 2009 at 6:57 AM, Will Hargrave <will@harg.net> wrote:

Joe Maimon wrote:

...

Anyone else having trouble with that?

Not had any luck on either the unicast or multicast RTSP feeds. Flash works fine, though.

For those who had trouble with the feed, I took some notes this morning from the first half of today's talks. Lunch break now, rest of the talks will be captured in separate mail at the end of the day. Matt 2009.10.19 NANOG notes, Monday Dave Meyer welcomes everyone to NANOG 47 at 0932 hours Eastern time. Everyone please take note of the hosts of NANOG 47, Arbor and Merit--thanks for coming out and supporting it! And next up, Betty Burke with some brief comments. Betty thanks the Merit president for allowing them to host NANOG again--this is the traditional thank you award given to the host. Lisa Quimby from Arbor has done a lot of work putting together the rest of the conference, so a big thank you to them as well! If you'd like to see the home base for Merit to see the datacenter and some facilities, contact Betty, she'll make arrangements, it's about 30 minutes from here. Don Welch from Merit has a few words now to talk about what Merit is. Formed in 1966 by 3 universities in Michigan In 80s and 90s worked with IBM and MCI to run the NSFnet June 3-4, 1994, NANOG 1 was held in Ann Arbor. Non-profit, serve research and education networks; provide a neutral ground for otherwise competitive companies to come together. Provide networking to libraries, universities, and research organizations. Mostly fiber based, provide layer 1, 2, and 3 services. Awaiting AARA grants to build out more services. Also providing additional services up the stack. ATT is providing a 50Mb circuit to Ann Arbor, and there out to the rest of the world via 10G. Farnam Jahanian co-founder of Arbor, welcome to NANOG47, and thanks to the co-hosts. Much of the work behind Arbor came from work and research done under Merit in the early days. Exciting new era of innovation from 1988 to 2009, from communication focusing on voice to a massive explosion of different communication systems and styles. Information technology is integrating more deeply into society, we have new ways to communicate, collaborate, and share information. Networking will continue to be at the center of this societal transformation. Traffic growing rapidly on fixed and mobile networks. IP traffic will double every 2 years through 2011 Video Internet drives much of the growth Google serving more than a billion videos a day now. Security threats clog bandwidth and increase costs Pricing for data is fixed or dropping Yesterday: the era of "look at me" attacks primary motivation of hackers was bragging rights worms and viruses were intended to simply wreak havoc on the infrastructure These were availablity attacks: impacting network access and services, and often, reputations. Today: Botnets, Mobility, Clouds, and Social Media Profit motives and new opportunities malware takes control of targets, enable C&C infrastructure, and enable malware deployment Coordinate attacks Political and Financial gains. Tomorrow: 2009 and beyond Future security challenges will follow internet adoption patterns Profit motives here to stay Politically motivated attacks are 21st century form of street protest. Protecting cloud infrastructure is key to long term adoption. Collaboration is more important than ever NANOG itself is example of collaborative nature of our work Cooperation and information sharing between private and public sector will be critical Cyber will grow to be ever more important to our economic security and prosperity. Craig Labovitz is up next, was one in a long line of program chairs for NANOG ATLAS Internet Observatory, 2009 annual report This was a 2 year effort, Arbor, UMich, and Merit working together. Largest internet monitoring infrastructure in thew orld Global deployment across 110+ ISPs/Content Providers near realtime traffic and routing statistics -- 14Tbps leverages commercial security/traffic engineering infrastructure Participation voluntary and all data sources anonymous ATLAS observatory report Few observations are completely unique/new growth of video, flatter internet, Google, etc. by press, academic papers, analysts, and NANOG may be first to quantitatively measure these trends First global traffic engineering study of Internet evolution There's been other work as well Akamai Bill Norton others Observatory Data Details Within a given ISP, commercial probe infrastructure Monitors Netflow/Jflow/etc and routing across possible hundreds of routers Probes topology aware of ISP, backbone, and customer boundries There's nothing in the files that shows which customer it comes from. No fine-grained data--not the NSA! What it observes Relative inter-domain traffic between ISPs based on small sample of ASNs and weighted towards core roughly matches analyst ISP market data/distribution data representative of global inter-domain traffic focus on "market share" as opposed to absolute data Inter-domain traffic volumes and ratios provide important design/engineering metric negotiation/business strategy Doesn't measure web hits, tweets, transactions, customers, etc. no internal traffic ISP success nor profitability Major Findings Consolidation of Content Contributors content migrated out of enterprise/edge to aggregators consolidation of large Internet properties Now only 150 origin ASNs now contribute 50% of traffic Consolidation of Applications Browser increasingly application front end (eg mail, vid) Applications migrate to HTTP of Flash ports/protocols All other ports/app groups decline (except games and VPN) Evolution of Internet Core and Economic Innovation Majority of traffic direct between consumer and Market shifts focus to higher value services (MSSP, VPN, CDN) Experimentation with paid transit Experimentation with paid content End-to-end internet battle has been fought and lost; even XBox 360 has moved to all port 80. BGP hop count gone from average of 4 to 3.5 to 3, and still down. ISPs moving from transport/transit to higher value services Evolution of the Internet Core 1995 to 2007, picture of the hierarchical network core from the end of the NSFnet era, still taught, was somewhat true into early to mid 2000s. ATLAS 10 in 2007: Level3, GX, ATT, Sprint, NTT, Cogent, Verizon, TeliaSonera, Savvis, AboveNet based on analysis of anonymous ASN origin/transit data. But between 2005 and 2010, the world started to change. collapse of wholesale transit grwoth of advertisement supported content collapse of price of cloud hosting and CDN (panther) Scarcity of datacenter capacity cooling/power/virtualization made old datacenters less useful; bar raised for new facilities. Market Forces in new Internet Price of IP wholesale transit is dropping towards zero Revenue from Internet Advertisement is going up. DrPeering site has these graphs. Key macro level trends shaping how ISPs approach their business. ATLAS 10 today: Level3, GX, Google (5.2%), XXX,XXX, Comcast, rest ommitted. Comcast and Google have joined the top 10, weren't even in top 20 in 2007. These are non-tier 1 companies according to Wikipedia, but Google is one of the fastest growing origin ASNs, and is now #3; and Comcast is climbing as well. Tier1s are still large, and are still somewhat profitable, and are carrying significant volumes of traffic. Consolidation of Content 2007, thousands of ASNs contributed 50% of content in 2009, 150 ASNs contribute 50% of all Internet traffic Approximates a power law distribution. The knee of the curve has changed. This is the most dramatic change that has occurred in the Internet. Hypergiants--big ASNs at far left side. Limelinght Akamai Panther BitGravity Highwinds Top five pure-play CDN origin ASN groups increasingly blurred lines between ISP and CDN significant competition and new entrants Only includes Akamai inter-domain traffic (likely 1/4 or less of all traffic) As category, CDNs represent close to 10% of all Internet traffic What's Happening Commoditization of IP and hosting/CDN drop price of wholesale transit drop price of video/CDN economics and scale drive enterprise to 'cloud' Consolidation Bigger get bigger Google, Yahoo, MSFT acquisitions Success of bundling / Higher Value Services Triple and quad play New economic models Paid content (ESPN 360), paid peering, etc. difficult to quantify due to NDA/commercial privacy Disintermediation direct interconnection of content and consumer driven by both cost and increasingly, performance Direct peering is driving traffic distance closer to zero Google, Akamai, others looking both at cost and performance, as SLA-based metrics start to push content closer to consumer The new Internet is a densely meshed cloud of ISPs, tier1/tier2s, global backbones, and HyperGiants--large content, consumer, and CDN providers. Google's weighted percentage average traffic vs YouTube Over time, Google absorbs YouTube traffic, Google now accounts for 6% of all Internet traffic globally Google one of the fastest growing origin ASNs Comcast In 2007, Comcast looked like a traditional MSO Lacked a nationwide network backbone Focused on residential services depended on upstream transit 2009, Comcast is different Net contributor of internet traffic 6th largest origin/transit group by volume Evidence of new business models triple play transit/wholesale service Traffic ratio shifted from inbound, to outbound; more content then eyeball network Increasingly blurred lines between content and consumer networks. Application consolidation Top ATLAS Global applications 2007-2009 Web, Video, VPN, Email, News, P2P, Games, SSH, DNS, FtP, Other, Unclassificed see the slide for exact numbers. Some like P2P is hard to categorize as it keeps moving, and some like Video don't necessarily catch it all, as much of it moves to Flash video over HTTP. P2P is fastest shrinking; most moving to flash or port 80 now. Global P2P trends Ports 6346, 6882, 6881, 4662 Global media cast P2P as the boogeyman, the driver around network neutrality, etc. back in 2007. By 2009, the great evil boogeyman of the internet is falling, and falling fast; losing market share, and turns out to have been mostly FUD. Asia is slower to decline in P2P than other parts of the world. P2P still has significant volumes slower growth, and some absolute decline why? provider traffic management (rate shaping, port limiting, etc.) improved P2P clients/algorithms (smarter clients localize traffic, etc.) migration to other content sources (peer to peer is a pain; is it shaky camera rip, or true HD movie? Now, direct download, direct CDN, hulu, iPlayer, etc. are taking over) P2P replaced by direct download Carpathia Hosting now represents 0.5% of all internet traffic MegaUpload MegaErotica, etc. Conclusion Internet is at an inflection point Transition from focus on connectivity to content old global internet models are evolving new entrants are reshaping definition/value of connectivity New technologies are reshaping definition of network "web" desktop apps, "cloud", CDN changes mean significant new commercial, security, and engineering challenges this is just the beginning Rate of change is accelerating!! QA. Bill Norton: video is a much larger amount of traffic for a given interaction; lots of MB vs reading an email, twitter, etc. Does that skew the analysis? Anyone carrying video traffic will show up very high on the list; this would discount anyone not carrying video, right? A: Yes, this shows very much that Video has dominated the internet now, even if it's t Q: Akamai asks if measurements do backbone to eyeball edge, external traffic, etc.? A: they try to capture as close to the edge S: Akamai's edge traffic less than 20% now. Q: When you rank networks by traffic, does it ignore the vector of the traffic, and just look at number of bits? A: It was ranking in+out; though in comcast, you see some of the in vs out delta. The tech report has some in vs out breakdown. Q: Are numbers peak, average, 95th? A: Mostly average. Many thanks Intenet Operations and ARIN Policy--is there convergence? Panel Mark Kosters starts off the panel (ARIN CTO) The oncoming runout of v4 addresses is really driving a lot of these discussions. Policy issues that affect you 4 byte ASNs ARIN using 4 byte ASN; scary how many people can't peer with them yet because of that. Whois cleanup old cruft in records; many people don't really know about looming events coming on the horizon; the easy landing period is getting shorter and shorter. ARIN is membership based org, we as members make the policies. Stay for the meeting, or at least join the Tuesday night session! IPv6 Policies Relaxed Transfer Policies etc. Focus on two policies 2 30 minute sessions First session: focus on relaxed transfer policy second, focus on IPv6 policy Tom Daly, Igor Gashinsky, Kevin Epperson, Aaron Hughes, RFC2050 doesn't mention purchasing space NRPM section 8.3 added based on policy proposal 2009.1 8.3 allows the transfer (outside merger or acquisition) of internet number resource registration rights to an operator who can justify it. Slippery slope to a market-based economy for address space? Tom Daly Dynamic Network Services ARIN relaxed transfer policy Removes M&A requirements on address transfers, permits "arbitrary" transfer continues to require justification of need Keeps ARIN as transfer agent Does this create a grey market for address space? "I'll trade your tainted, RBL-ed IPs for some clean ones" Concerns about deaggregation upon exchange --RIB size Does ARIN become a title agency for IP address space? new business opportunity for ARIN Does his create new precedent for policies Igor--Relaxed IP transfer policy is a good thing. allows businesses to continue growing even after v4 run out point. This could be a profit center for some companies Can also help companies who cannot afford to migrate to IPv6 quickly stay functioning. Concerns? Why is the policy written in such a way that it takes legal counsel to really understand what it means! Can we have simple english policy? Who will handle the market? when will it be set up? what's the impact on the routing system? should ARIN care? Do the benefits outweigh the tradeoffs? For us, most definitely! It may make it more expensive, but very possible. Oh. Maximizing slides would be good! Aaron Hughes is up next, 6connect.net transfers are happening, regardless of LIR or RIR support. There are companies which will need IPv4 resources to survive post IANA and RIR run-out Operational impacts with or without policy in place. Closing a sale now involves IPv4 resources Justification process harder on our customers and on staff Neither SBGP nor signing authorities in place There are bad people trying to make money from: resources they are assigned resources they are NOT assigned LIRs are not very good at tracking resource assignments today (LOAs, IRR, whois checks) most of these updates are easy to spoof. We don't check LOAs very carefully when customers show up and ask space to be routed. IRRs mostly are mail-from, so adding new records, or updating them, are far too easy. M&A will be much harder to determine net worth of asset (more work for legal and due diligence) Company officers all over the world now know they need more space (intent to educate about IPv6) fiduciary responsibility to not run out their staff objecting to IPv6 higher potential for fraudulent resource utilization reporting higher potential to waste IPv4 resources now to justify space long before need (NAT flips) Contact information is more likely to be accurate with a system that updates upon transfer. Clean transfers will have higher value than black market transfers Stay inb Force better tools and policy to verify assignment SBGP/SoBGP, Routing table growth will force cleanup of de-aggregated prefixes that do not *need* to be Potentially force conditional route-maps/routing policies to be enforced to reduce announcements except when needed Actions: validate current process prepare for some flavour of signing inform your sales staff and modify process as needed. inform your abuse staff going to get harder to manage spammers If you haven't already, start using IPv6 to reduce the impact of transfers! Dan Alexander, Comcast Cable Transfer policy--enables new entrants to obtain IPv4 space during the transition Primary goal of the transfer policy is NOT to extend or perpetuate the use of IPv4; we're still supposed to be focusing on the migration to IPv6. Transfers likely to be of little use to large ISPs This would at most cover about 6 months coverage at the current global use. Long term, IPv6 is the long term solution IPv4 resources don't scale, given the number of new devices joining the Internet. Kevin Oberman speaking for himself It's already happening; if you have a commodity or anything that has some value, someone will be interested in buying it, legally or otherwise. If the supply is limited, price will rise to the point where someone will sell Prohibition does not work! How badly it works is proportional to the level of demand (not volume) History shows how badly prohibition fails. Choice: black-market: ad-hoc no controls white-market transparent controlled Summary when a /18 stands between you and the continued existence of your business, would you buy an address block on the black market? Q: Heather Schiller, Verizon Business -- black market will exist for 2 reasons; one for shady purposes, and one if they don't have justification requirements. A: No, the idea is to make sure that you don't force a significant portion of the consumer base to create a black market. Q: do you support the current justification levels in the transfer policy? A: Yes, the current justification requirement is reasonable; the current market is small; that's what keeps it workable; if the black market gets larger, the system starts to break down. Q: Martin Hannigan; when you talk about markets, recognize that it happens now; people will do what they can to get around ARIN if they can make some money off this. We need to wake up a bit and realize it's not a tiny market. A: Yes, we need to figure out how the operational people will play in this space; right now, there's some amount of registry involvement; but we need to have some way to validate the authenticity of transfers. Q: Jason Schiller, Verizon; ARIN does *not* make it more difficult to get IP space as we get near depletion; if you want to see rationing, get involved in the conversations; at the moment, the current plan of record is to have same level of justification we've always had. Q: Sandra Murphy, Sparta--how will this affect the RPKICIDR work? This should work within that framework without issue, so long as ARIN is part of process. A: Yes, if ARIN is no longer the transfer agent, it becomes quite a challenge. Q: RPKI system allows an entity to transfer all its resources; but to ensure that the resources can't be pulled back could be a challenge. Q: Manish--this doesn't take into consideration growth in the size of the global routing table. In the past, ARIN has been uninvolved in this; but as time goes on, this will cause the global table to grow. A: Table growth will occur, period; this is about keeping the contact information up to date. And you'll just need to keep growing your router gear to keep up, that's part and parcel of doing business on the internet today. Q: Dave Meyer--second half of panel at 11:30. Second part of policy panel Mark Kosters: IPv6 polices--not a lot of operational experience to back up policy Big discussion on assignment sizes Route Filtering /32s or /48s? Should routing policy affect ARIN assignment/allocation policies? --should route filtering be based around ARIN assignments? vice versa? Are v6 policies hindering v6 rollouts? Igor is up first IPv6 policy If you're an established ISP, getting IPv6 space is really easy can take less than 20 minutes The bad: The "must announce a single aggregate" policy is causing some people to delay deployment Not everyone is willing to put all their eggs in a single /32 announcement hijacking traffic engineering anycast multiple discreet networks what about multiple non-connected datacenters? how about branch offices? There is hope! 2009-5: IPv6 Multiple discrete networks should help somewhat 2009-7: open access to IPv6 removes the "single aggregate requirements" please discuss and vote! these policy changes help shape v6 rollout. Dan Alexander He's not saying IPv6 is easy and doesn't need policy support. ARIN policies and IPv6 mandates Some have suggested ARIN policies should mandate IPv6 deployment upon future requests for iPv4 resources ARIN should strive for consistent RIR policies that facilitate it Frustration...a matter of priorities It does require significant resources to make it happen. timing--v6 deployments increasing even before we hit the run-out point. IPv6 is being deployed. Comcast is connecting to other networks using IPv6 Trials will continue in to 2010 If you're not already working on IPv6, you need to start now; it'll be too late if you wait until we hit the IPv4 runout point. Kevin Oberman: Should ARIN make routing policy? ARIN staff and the AC often say that ARIN does not do routing policy BUT the policy stating that a single /32 announcement is all you shall make, is indeed routing policy. Announcing a single prefix to everyone at every location breaks all current models of traffic engineering. Mainly an issue for those with a geographically large footprint. if all your stuff is in one location, not a problem. But enterprises have similar issues with load balancing; a single address doesn't allow for load balancing easily. ES.net advertises two /17s with specific metrics, with a /16 covering. They move huge single-streams, where latency changes have a massive impact. So, with no way to localize traffic, with no way to balance traffic, with no way send metrics for closest exit, traffic doesn't do the right things; ARIN doesn't know how to run our networks, and shouldn't be telling us how to route things. Tom Daly is up next. IPv6--all eggs in one basket. huge risks hijacking flap dampening Deaggs filtered in some operator networks limit techniques for TE moves, adds, deletes, changes less flexibility in overall routing policy by operators not every network is a subscriber access network. MicroAllocations for critical infrastructure doesn't work for enterprises. NPRM 4.10 Allocations up to /28? That policy will do more to hurt the routing table size than v6 PI space. BCP 16 cannot be satisfied to maximum level; separate LAN segments internally, single external announcement No multiple networks supported. Aaron, last speaker IPv6 policy vs operations same slides as everyone else, so he just talks. ARIN vs NANOG; why do we seem to come from different sides of the issue? Some people want a v6 internet that looks just like the v4 internet, with NAT and RFC1918. Others want the old central backbone back again, going back 20 years ago. If you're not in giving your vote, you're not being heard! You need to vote, and show up! Why is it VERSUS instead of AND? Why do we have two different meetings? The policy breaks multihoming, yes. But people aren't following that. Some providers will take your /48 and will announce it. Others in the room follow the policy, and block the advertisement. We're lying to our registry; there are policies that we've agreed to that we don't follow. There's 2100 prefixes in v6, and half of them are for TE. Why can't we write a document that makes sense, that follows what we'll actually do? Oh. And you have to be a "known ISP" to get v6 space; he had to justify a need for v4 IP space and ASN before he could get v6 space. This will continue to be a headache as we go forward! Five minutes for questions. Cathy Aaronson--ARIN advisory council. They really need everyone to participate. This is a very old policy, from when Kim Hubbard ran ARIN. It doesn't meet our needs, so there's a proposal written by Aaron's wife to change this. They really do need people to stick around and join the ARIN meeting, and help write and pass more reasonable policies! A: Tuesday night there will be a session to read about the new policies. Q: Owen DeLong, HE.net and ARIN advisory council. Having policy at ARIN level reflect routing is a very bad place to do control of routing policy. There's talk of more policy to control route table growth; it would be good for operator community to get more involved in the ARIN process. A: Aaron notes that today we don't have a place to document best network operations practices. There is no document repository for operator policies genereally speaking. Tom notes that he's in a relatively new organization, which doesn't have a strong institutional knowledge background; there's no place to look up to see why /24 was a boundry line, and why /32 and /48 were picked for IPv6, etc. Cathy is back up again. The reason there is routing policy in ARIN, when the policy was writtin, everyone on the AC worked in routing, and was concerned about table bloat. They were trying to bring operator input at the time, because at the time, that seemed to be the right thing to do. Q: Alain, speaking for himself. Allocation policy and routing policy is the same thing. If we have transfers happening, there will be pressure for smaller and smaller blocks to be announced and accepted. It doesn't mean that ARIN has to do the routing, it just means that if ARIN has agreed to allocate the space to you, there's a need for it to be reachable! Lee Howard, ARIN board of trustees, TWTC. Thanks to ARIN for writing a best practices policy document! ARIN will do the words we send them that get discussed by the community; you need to send better words to the community!! Jason Schiller, Verizon; Why do we route /24s across the board? Because we created a swamp by allocating /24s to individual companies. We're about to create the same thing in IPv6 by allowing /48's from PI holders. Soon each v4 ASN announces on average 9 prefixes; if we do similar in v6, we'll see similar breakups in /32s, and then soon in PI /48s doing /52s or /56s. The routing table will definitely get big if we do that. It's not clear when, but at some point in the forseeable future, there will be a significant number of the v4 ASNs also doing v6, and when that happens, you will need to be looking at doing swapouts of your entire network routing infrastructure to handle it. Once we create a swamp, there's no way to drain it, and there won't be a chance to implement a different solution. Igor responds: perhaps the answer to some of that is that the refresh cycle needs to be shrunk down, and the cost of business needs to reflect that. Responding to Igor, he looks at the impact of lost customers if they don't route the space vs if they do make the upgrades. Kevin notes that most of us are business providers; we will make a business decision as to whether or not we can make the decision to route a million prefixes or not. It will not be driven by what ARIN decides, or by what NANOG decides, it'll be driven by Marla Azingera--what we do is what goes; one of our two charters needs to be that one of the organizations writes routing policy. So, do we modify NANOG charter, do we modify ARIN charter to write routing policy, do we create a third entity to do that? Randy has last question? How did we come up with the /19? It used to be /19 for registries, then /20, then /21; it was a bunch of operators and registry people who got together, and came to some level of agreement. And at some point, the limitations of silicon kick in. RAS is up next. Scripting on Routers On-box automation with JunOS Phil Shafer phil@juniper.net Problem statement configuration is increasingly complex network operators have custom design rules no enforcement mechanism cost of failure increasing Off-nework managemnet Database of Record push the config from central system. Goals for Scripting tighter integration promote high-level concepts and views XML API JunoScript XML API NetCONF standard XML to text rendering happens at CLI Commit scripts: automatic part of commit process Op scripts add new commands Event scripts trigger on specific events. Commit scripts Internals in XLST internally, actions are in XML example--you can have constraints that require certain conditions to hold true, like all LDP enabled interfaces must have IGP running on them. apply-macro statement "apply-macro no-ldp" for example can appear anywhere, takes a name as an argument you can also repair/change configs around it. you can fix problems before they occur. transient config config that is published to software components, but not seen by the user "show | display commit-scripts" ex-iso.slax example enforces constraints on ISO and MPLS use the "jcs:emit-change" helper template. can warn you about what it is fixing. it inspects configuration in XML uses XPath expresssions to local interesting nodes call jcs:emit-change pass in required arguments $content $dot There's a 1:1 mapping between config and XML representation. XML config as tree, XPath allows you to find things in the tree. Macro Expansion example Three common threads get better information display to user diagnose issues standard operating procedures codify best practices in a script testing Configuration example may appear in configuration may appear in the script itself dead-peers example op dead-peers shows last dead reason, can try to bring it back up, etc. Remote RPCs network issues are seldom one sided diagnose scripts need access to remote device compare config to ensure both sides are consistent inspect remote state to see where problem lies access to intermediate devices as well "intelligent" traceroute shows information about each hop by RPC'ing to it. Interactive scripts op scripts can ask the user for input var $response = jcs:get-input var $password = jcs:get-secret simple questions, or complex interactions New "wizard" framework Single point of configuration run an op script in one location to deploy a service in multiple locations Event overview up-down syslog events time-based events pic-restart triggered events pic-restart.slax script to restart pic after issue Event script possiblities change config jcs:dampen SNMP generate traps More examples: http://tinyurl.com/ykb9x07 RAS why script on routers? get benefits of automation without blocking people from logging into the router. Anything you can automate makes the network run better and run cheaper. Automated BGP policy generation Automated BGP prefix-limit management Support case data gathering scripts example of building BGP policy generation script builds per-ASN communities/policies for prepend AS-PATH 1x prepend AS-PATH 2x Automated BGP policy generation Also useful for building AS-PATH leak filters define a list of major ASNs you only want to hear "directly" block any route with one of these reserved ASNs in in the AS-PATH if the route didn't come directly from one of those ASNs Useful for preventing leaks and suboptimal routing If I peer directly with 701, I don't ever want to accept their route from someone else. Also useful for building policy frameworks script can scan for the existence of a policy with a standard name for each BGP neighbor script automatically generates and maintains 44 lines of new router configuration for every configured BGP peer Automated BGP prefix-limit management. operators use BGP prefix-limits as policy safety nets if a BGP neighbor sends more prefixes than we believe is normal, drop the BGP session for a certain period of time. Somewhat effective at protecting against leaks But difficult to maintain over time. concept of "normal" is always modifying. prefix limit based on current prefixes sent plus an overhead factor, like (PfxCnt*1.25)+500 Uses a time-weighted average Run the script once a night allow manual runs if needed. Automated support cases opening vendor support cases gather most common log files and support components, and automatically upload them to vendor via FTP How effective is this? router configs are 62% smaller than if the commit scripts aren't used. questions to ras@nlayer.net Q: Aaron Hughes--good talk; would be nice to check peeringDB and set max prefix based on that. While this is nice, companies are afraid to deploy scripts; handing off control to scripts causes a lot of consternation. A: should be possible for script to pull information from an external source like peeringDB, yes. Lorenzo: As far as fear of scripts goes...human make mistakes slowly. Scripts make mistakes...really fast. RAS notes that you shouldn't do your scripting ad-hoc. Do it in the lab, test carefully, and then deploy the script carefully. Jared notes that some vendors don't have commit or rollback in their portfolio. We need to explain to our vendors that they are losing business by not having that support. They push automated config to their startup-config instead. ^_^; It would be nice if the vendor could support some of these scripts, or provide them with the software so they could be used more widely. Chris Morrow--people get most scared of breaking the entire network; it's usually tactical stuff that breaks that way. Well planned, well tested, staged, there's no reason not to do it. Another person states that they've seen ISPs that have "coders" who write horrible code; we have a lack of competent talent backing up our scripts on routers and support scripts. Any coder who writes something has to have a good understanding of the platform they're coding on; the people who have that intersection of skillsets is very, *very* small! More training in coding for routers would be a really good thing. Having a repository that those few, really good people could contribute to would be nice. http://juniper.cluepon.net/ has good repository of scripts Randy Bush--it's not a 'coder', it's a software engineer; it's easier to teach a software engineer about networking than coding. Informal BOFs after lunch! Return to the room by 2:30.