Trouble with the rtsp vlc feed?

[mpetach at netflight.com (Matthew Petach)]

On Mon, Oct 19, 2009 at 6:57 AM, Will Hargrave <will at 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 at 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 at 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.