1 / 13

IRTF RRG March 2008

IRTF RRG March 2008. draft-burness-locid-evaluate-00 Louise Burness, Philip Eardley louise.burness@bt.com ; philip.eardley@bt.com. ACKs. Louise Burness - main author of draft, hopefully in Dublin

harlow
Télécharger la présentation

IRTF RRG March 2008

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IRTF RRGMarch 2008 draft-burness-locid-evaluate-00 Louise Burness, Philip Eardley louise.burness@bt.com ; philip.eardley@bt.com

  2. ACKs • Louise Burness - main author of draft, hopefully in Dublin • Thanks to all who have had discussions on the mailing lists - they have inspired most of this material • Sheng Jiang & Xiaohu Xu, co-authors of preliminary version submitted to Chinacom08 • Colleagues on Trilogy project, especially Olivier Bonaventure & Simon Schuetz for very useful comments • Trilogy Project, EU Disclaimer: • The research results presented herein are partly funded by Trilogy, a research project supported by the European Community under its Seventh Framework Programme. The information in this document is provided 'as is', and no guarantee or warranty is given that the information is fit for any particular purpose. It reflects only the views of the author(s). The user makes use of the information at their sole risk and liability.

  3. Cautions • It is not The Truth • one perception that is hopefully useful /provocative in trying to improve the “convergence” process & the applicability of the eventual output • Not pushing any proposal • It analyses map & encap and translation schemes at quite a generic level – • standing back from the details, although they can be over-riding factor (esp security?) • Complements Robin Whittle’s detailed comparison within map & encap schemes • It doesn’t consider other approaches (eg Mark Handley’s “Are we solving the wrong problem?”; Node ID architecture, HRA; Paul Francis’s virtual prefix; Ran Atkinson’s ILNP)

  4. What’s in the draft • Intro • Design goals • Comments on draft-irtf-rrg-design-goals-01, eg some things we think not covered well • Related working options • NATs, DNS & mobile directory systems – what can we learn? • Map & encap schemes • Comments vs design goals • Translation schemes • Comments vs design goals • Mapping system design • Conclusions

  5. Personal perspective - Main point We believe it would be very useful to analyse approaches at a more generic level (cf analysis docs) • Balance of detailed protocol engineering & ‘generic’ analysis • Worthwhile to do some order of magnitude analysis • Eg move from saying “Scalable because promotes address aggregation” to saying “at least 50% of sites who today use PI would be able to use PA addresses using this scheme” or “average prefix length will decrease to 17” • What’s the 2+ orders of magnitude improvement? • Worthwhile to do some simple experiments? • Eg run some TCP and RTP applications and stall the first packets for different times to see how mid-flight delay would impact them • Can we learn anything from current systems or history • Eg NATs, cellular systems, IP-over-ATM • A new mapping system is common & a crunch point • Do the proposals all make the same demands on it? • Would anyone like to collaborate?

  6. Comments on Goals (draft-irtf-rrg-design-goals-01) • They’re Goals not Requirements • People have different views on which Goals critical & when? • Maybe not one protocol to solve all Goals => something simpler? • Deployable (migration) • What’s the minimum deployment where gain > pain for the migrating party? • Deployable – policy • Understand how approach changes policy mgt • What’s operator policy vs performance trade-off? • (add goal) Address shortage • If prolonging IPv4, must reduce addresses at day 1; • If must go to IPv6, want only one network overhaul • (add goal) Failure robustness • Minimising connectivity disruption critical (for some sites)

  7. Related current systems • Types of per-flow packet processing • NAT • Changing header values • Need to consider peak rate • limit to number of users behind NAT • 10,000 users ? (see draft) • many less ? (over beer gossip) • Say 300,000 end sites, 1*10^9 users worldwide -> 3,000 users per site. Now that surprised me! • ECMP • Just a normal read / forwarding action once state set • Barely noticeable impact (what does barely noticeable mean; when does it become noticeable?) • MPLS • Adding a label • No different to adding Ethernet framing data

  8. Areas to study for map & encap schemes • Changing provider is simple, but how to do efficient multihoming is not clear • Scaling & speed (for fast failover & frequent TE/policy changes) • Deployment – legacy interworking • Anycast (proxy) ITR motivation • What info does tunnel hide? • Fault tracing, ECMP, policy • And expose? (ITR-ETR comms for TE)

  9. Areas to study for translation schemes • Multihoming looks ok, but how to do efficient provider change? • Impact on functions in edge network like ACL etc • Deployment end goal is IPv6 and host changes • Deployment interim step – legacy interworking • Six/One Router motivation? Mapping system? ALG?, extension header? NAT.

  10. Areas to study for mapping • Does mapping reflect reachability (verified) or a ‘hint’ • Security implications? (is this end site allowed to use this ETR?) • Overall resilience? (another failure point) • Is size or churn of mapping system a concern?

  11. Example thought process – consider a push mapping system • If full mapping database is pushed to every ITR, is this scalable? • How many peerings are needed to exchange information and how are those peerings managed? • Current system, 248,227 prefixes in DFZ • Big enough to be causing concern • Lack of availability from convergence delay is an issue • is it size or churn?

  12. Mapping System size • Mapping system maps from end site to address • How many end sites are there? • 50,000 AS registered • say half of stubs use BGP peering – so 100,000? • System almost as big as DFZ already • probably under-estimate, may be many more small stubs using NAT today • Based on number of businesses with more than 10 customers (Marshall Eubanks) would lead eventually to 6 million stubs

  13. Churn • If we assume that mapping system is only updated for provider changes • With 300,000 end sites, 1 provider change per year, that’s 1 change every 2 minutes cf several hundred a minute for the routing system • 2 OM different is big enough to be important • If we have 2* 10^6 end sites, then just provider change is the same as the current routing system updates • If mapping system is updated for failure, multi-homing and mobility • Its virtually the same scale as current routing system, but with even less localisation of changes

More Related