1 / 14

Interface to The Internet Routing System (IRS) Framework documents

Interface to The Internet Routing System (IRS) Framework documents. Joel Halpern. IETF 84 – Routing Area Open Meeting. Drafts included draft-atlas-irs-problem-statement-00 draft-ward-irs-framework-00 draft-atlas-irs-policy-framework-00 draft-dimitri-irs-arch-frame-00.

althea
Download Presentation

Interface to The Internet Routing System (IRS) Framework documents

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. Interface to The Internet Routing System (IRS)Framework documents Joel Halpern IETF 84 – Routing Area Open Meeting

  2. Drafts includeddraft-atlas-irs-problem-statement-00draft-ward-irs-framework-00draft-atlas-irs-policy-framework-00draft-dimitri-irs-arch-frame-00 Draft authors: Alia Atlas, Thomas Nadeau, David Ward Susan Hares, Joel Halpern Dimitri Papadimitriou Martin Vogoureux Wounter Taverneir, Didier Cole IETF 84 – Routing Area Open Meeting

  3. What’s the Problem? • Applications Need To Dynamically • And Knowledgeably, based on: • Topology (active & potential) • Events • Traffic Measurements • Etc. • Augment Routing, based on: • Policy • Flow & Application Awareness • Time & External Changes Network Application Feedback Loop: Control & Information

  4. What’s Needed for the Routing System? • Data Models for Routing & Signaling State • RIB Layer: unicast RIBs, mcast RIBs, LFIB, etc. • Protocols: ISIS, OSPF, BGP, RSVP-TE, LDP, PIM, mLDP, etc. • Related: Policy-Based Routing, QoS, OAM, etc. • Framework of Integratingof External Data into Routing • Indirection, Policy, Loop-Detection • Filtered Events for Triggers, Verification & Learning Changed Router State • Data Models for State • Topology model, interface, Measurements, etc. • Device-Level and Network-Level Interface & Protocol(s)

  5. Main Concerns • Standard data-models • clear self-describing semantics • Sufficient coverage for use-cases needing feedback • Applications aren’t routers – so can’t need to implement a list of routing/signaling protocols • Good security, authorization, & identity mechanisms • Scaling and responsiveness: • Multiple applications • Many operations per second • Significant data to export, even when filtered

  6. IRS Framework at IETF 84 Application Application Application IRS Client IRS Client IRS Protocol Router Policy Database Routing and Signaling Protocols IRS Agent D Topology Database RIB Manager Subscription to Events and Configuration Templates for Measurement, Events, QoS, OAM, etc… FIB Manager and Data Plane

  7. 3 Key aspects - P.A.L. • Programmatic interface – asynchronous and fast • Access to information – IRS gives access to information and state that is not usually configured or modeled. • Learn additional filtered Events

  8. IRS Interface Key Aspects • Multiple Simultaneous Asynchronous Operations • Configuration - is not reprocessed • Duplex Communication • Asynchronous, Filtered Events • Topologic Information (IGP, BGP, VPN, active/potential) • High-Throughput • Highly Responsive • Multi-Channel (readers/writers) • Capabilities Negotiation/Advertisement (self-describing)

  9. What IRS is not IRS is NOT: • the only configuration mechanism a router will ever need, • a direct replacement for existing routing/signaling protocols, • the only way to read topology and router data that will ever be needed, • solely limited to a single network device.

  10. IRS: Focused Scope • Start with a defined scope: • Small set of data-models (RIB layer) for control • Set of events to support related use-cases • Data-model for topology • Investigate protocol options for the interface • Consider application-friendly paradigms • Consider extensions as well as new definitions • Define set of motivating use-cases to drive this scope.

  11. IRS Policy Framework Application Application ID 123 a Application IRS Commissioner IRS Client IRS client b IRS Commissioner ID: 222 ID: 555 Policy Database IRS Agent Policy Database IRS Agent ID: 666 Topology Database Topology Database Routing & Signaling Protocols Routing & Signaling Protocols RIB Manager RIB Manager Events & OAM Events & OAM FIB Manager & Data Plane FIB Manager & Data Plane

  12. Policy Framework 101 Policy Definitions Policy Actions Connectivity No need for active connection State Tied to Actions such as get this topology; Priority Commissioner gives 3 tasks: pull routes, status on interface 2, turn on interface 3 What’s the order Precedence Decisions Assume configured a route 192.165.2/24 Multiple people use IR to move traffic for 192.165.2/24 short term Who gets to install what happens when they get done What happens on a reboot • Identity • Not tied to a single channel • One per commissioner • One per agent • Role • Each commission has a security role • Scope - what I can read • Influence – what I can write • Resources • what agent can consume • Example: # of installs, # of events, # operations • Policy – explicit and implicit • Explicit: what you configure • Implicit: What’s implied in protocols or “doing the right thing” in configuration

  13. Q&A

  14. Why Policy Framework • Help to take Use cases  Data Models • What is the scope and influence policy specified for a data model? • How does implicit policy in associated routing system effect what IRS can do? • AKA - Don’t break implied policy • What explicit policy does model need? • Why: KISS approach (Keep it simple stupid) • Best default – because complexity costs • Some IRS may require • 3 phase commit or Time related commits

More Related