Transcript Slides - TERENA> Events> tnc2006

Routing integrity
in a world of
Bandwidth on Demand
Dave Wilson
DW238-RIPE
[email protected]
Agenda
• The
• The
• The
• The
• The
quick introduction
60 second JRA3 summary
90 second campus networking guide
problem statement
run-down of the solutions
– (and their own problems)
Introduction
• There's no thrilling new technology here
– Afrodite's in another room describing JRA3
– I'm speaking for myself, not any other project
• Some fairly simple IP routing
– Emphasis on observed use over best practice
• Users might not see this coming, however
60 second guide
to the JRA3 project
60 second JRA3 summary
• NRENs everywhere are working on
providing layer 2 services
• These meet up with GEANT2, which
provides its own
• JRA3 plans to tie these all together
60 second JRA3 summary
• So the NREN will be able to create layer 2
paths between arbitrary locations
• JRA3's system will process requests and
arrage setup of end-to-end paths
• Users will have the possibility to connect
to "anywhere" in Europe - on layer 2...
60 second JRA3 summary
• Benefits? Gets the high-demand users off
the routed IP network...
• Tune the IP network toward less
conflicting goals....
• Gives the user more control...
90 second guide
to campus networking
90 second campus networking
•Every campus is different
– Security needs
– Regular web/email needs
– Research networking needs
–"Home" user (campus accommodation)
•These are conflicting requirements
– Ask any CERT
•Each IT dept reaches its own conclusions
90 second campus networking
•Then there's the link to "the internet"
•Often in the past been a single link,
with routing policy specified by the NREN
–e.g. static routing, BGP, OSPF, RIP, ...?
•Depends on the requirements of the IT
dept, and the service spec of the NREN
90 second campus networking
•Routing policy consists of
–list of IP prefixes assigned
–info on how those prefixes are routed
•Some hierarchy is assumed
–RIR gives addresses to LIR, LIR to customer
•Network is built around that hierarchy
Hierarchy is assumed
90 second campus networking
•Not been the case before that users create
arbitrary layer 2 connections
•Successful Bandwidth on Demand service
would change this assumption
These two worlds meet
Conflict of interest
•The technology exists to connect arbitrary
LANs across Europe. Great!
•The addressing assumes the old hierarchy
•Addressing isn't as flexible as GE circuits
Fragmentation -> Hierarchy
•We tried fragmented address allocation
– Class A, Class B, Class C, ...
•Doesn't work on a grand scale
– Led to setting up of RIPE and the other RIRs
•You can still get fragmented space
– Provider Independent vs. Provider Allocated
Fragmentation -> Hierarchy
•ISPs (NRENs included) become LIRs
•Take stewardship of a block of addr space
•Connectivity for those PA addresses
is dependent upon the NREN
"All assignments are valid as long as the original
criteria on which the assignment was based are still
valid" -- RIPE-368
Who is working on this?
•BoD people are working on the BoD service
–Not just in Dante/JRA3, in NREN as well
•Customers may not have routing expertise
–Multidomain routing is a specialist subject
•RIPE policies are already in place
–Not clear if any change there could help
•That leaves the service providers...
The solutions
The tradeoffs
•Follows the rules
•Easy for user to deploy
•Easy for operator to support
•Flexible to existing networks
Solution #1
•Get an AS number and PI space
–Renumber the networks
–Run BGP within the campus, and to the NREN
Solution #1
•Get an AS number and PI


space

Follows rules
Easy deploy
Easy support
Flexible
–Doesn't fit with the on-demand idea
–Requires complex IP and BGP expertise
–Doesn't exist for IPv6 (at the moment anyway,
interesting implications from RIPE meetings)
–Everyone hates renumbering
Solution #2
•Use RFC1918 space
–Renumber the networks
–Proxies/NATs for outside access
Solution #2
•Use RFC1918 space




Follows rules
Easy deploy
Easy support
Flexible
–Networks might not be fully connected
–Removes any hope of connecting directly to
rest of the internet
–Everyone hates renumbering
Solution #3
•Use existing numbers and hope it works
–Directly connect the networks
–Static more-specific route on the hosts
toward the remote site
Solution #3
•Use existing numbers and
hope it works




Follows rules
Easy deploy
Easy support
Flexible
–May bridge campus networks,
and all the security hilarity that that entails
–Difficult to manage, traffic could go the
"wrong" way and be blocked or cause trouble
–Breaks conditions for IP allocation, so there
may be unexpected side effects
Solution #4
•Subnet, route the subnet
–Renumber networks if necessary
–Configure routing (not necessarily dynamic)
within the campus
–Route the more-specific subnet to the remote
site over the BoD connection
Solution #4
•Subnet, route the subnet
 Follows rules
 Easy deploy
 Easy support
 Flexible
– Breaks conditions for IP allocation, so there
may be unexpected side effects
– Still requires some routing knowledge
– Difficult to enforce backup via regular IP
network
Other possibilities
•IPv6 gives us a much freer hand
–Multiple addresses per interface
–Source Address Selection based on application
•Combine with .1q VLANs
–Host chooses which LAN to send traffic one
–Requires host to have intelligent routing
–Could in principle work for IPv4
To try to reach a common
solution...
•Is this really how we expect BoD to be
used?
–or is it ok to expect that some routing
complexity will have to be dealt with?
•Tools are there to handle this, but have
not been necessary at this scale before
•For the first time, the network will be more
dynamic than the addressing
Thank you!
[email protected]
DW238-RIPE