1. Routing System Stability draft-dimitri-grow-rss-01.txt dimitri.papadimitriou@alcatel-lucent.be jim.lowe@alcatel-lucent.be IETF71 - Philadelphia

2. Motivation & Scope Understanding dynamics of the Internet routing system to i) ensure its robustness/stability ii) improve mechanisms of BGP routing protocol Scope: program of WG activity for identifying, documenting and analyzing the dynamic properties of the Internet and its routing system

3. Dependencies (1) Investigations on Internet RS dynamics => investigations on routing engine / system resource consumption (memory & CPU) System resource consumption depends on –size of the routing space: routing entries => memory routing entries => processing and searching (lookup) –number of peering adjacencies between routers: peering adj. => dynamics associated with routing information updates exchanged => increasing memory requirements

4. Dependencies (2) Current routing engines potentially support up to O(1M) routing table entries instabilities resulting i) from routing protocol behavior ii) routing protocol information exchanges iii) changes in network topology that may adversely affect the network's ability to remain in a useable state for extended periods of time

5. Objectives and Tasks Objective: identify root cause and document occurrences of Internet RS stability phenomena (using data from operational networks) Tasks 1. Methodology to process and interpret routing table data 2. Identification of set of stability criteria and development of methods for using them to provide a better understanding of the routing system's stability 3. Investigate how routing protocol behavior and network dynamics mutually influence each other

6. Stability Criteria Routing system (RS) stability: –characterized by its response (in terms of processing routing information) to inputs of finite amplitude Input classification –internal system events e.g. routing protocol config. changes, –external system events e.g. routing information updates –note: sometimes loosely referred to as routing instabilities Stable vs Unstable –Stable/marginally stable RS returns to its initial/new equilibrium state, when disturbed by external and/or internal event –Unstable RS remains in an unending condition of transition from one state to another when disturbed by external and/or internal event

7. Stability Criteria Definition of stability implies Define system being examined –Routing system and associated events, such as input events, outputs, and related arrival rates Convergence metric –Metric to define the convergence characteristics of the system Stability metric: –Degree of system stability that indicates how close the system is to being unstable

8. Stability Criteria Convergence and stability metrics dependency –Number of routing entries each entry R toward prefix D has associated attribute set A consisting of AS-Path, MED, and Local Preference, etc. –Number of CPU cycles, C, required to process a routing entry, and its associated memory space, M –Input events and their arrival rates –Output events associated with the processing of each input event.

9. Formulation RT(n) routing table at some time n At time n+1, RT(n+1) = RTo(n) + deltaRT(n+1) –RTo(n): set of routes that experience no change between n and n+1 –deltaRT(n+1) accounts for all route changes (additions, deletions, and changes to previously existing routes) between n and n+1 At time n+1, deltaRT(n+1) = RTc(n+1) + RTn(n+1) –RTc(n+1): set of routes at time n that experience some change at time n+1 –Rtn(n+1): set of new routes observed at time n+1 that were not present at time n

10. Derivation of Stability Metric Algorithm for calculating a stability metric Stability, marginal stability, and unstability quantification in the context of RT |deltaRT(n+1)| = magnitude of RT change at time n+1 –Stability condition: |deltaRT(n+1)| = infinity a is small, positive number –Marginal stability condition: a infinity b is small, positive number, b greater than a –Unstability condition: |deltaRT(n+1)| > beta as t -> infinity. Note –no distinctions for new routes or changed routes, or for the source of system disturbances –a and b to be set based on some sort of operational criteria (a.o. dependent on the observation sampling frequency)

11. RT Stability Metric To compute |deltaRT(n+1)| => compute stability metric for an individual route –single route, rti(n+1), component of RT(n+1) –rti(n+1) = {destination, path attributes} –|deltarti(n+1)| = change in rti stability metric, from t=n to t=n+1 fi = stability metric associated with route rti fi initial value = 0 At time n+1 if rti(n+1) != rti(n) /* the route has changed */ then fi(n+1) = fi(n) + 1 else /* the route did not change */ if fi(n) = 0 then fi(n+1) = 0 else fi(n+1) = f(n) - 1

12. RT Stability Metric Using stability metric definition for individual route, compute stability metric for entire routing table (RT) Stability metric of RT, at time t=n+1: |deltaRT(n+1)| |deltaRT(n+1)| is normalized –Perfect stability: |deltaRT(n+1)| = 0 (minimum value) –Complete instability: |deltaRT(n+1)| = 1 (maximum value)

13. RT Stability Metric for i = 1 to number of routes in RT(n+1) if rti(n+1) is a new route then |deltarti(n+1)|=0 else /* rti(n+1) is an existing route */ if fi(n)=0 and fi(n+1)=0 then |deltarti(n+1)|=0 else /* a change occurred to the route */ if fi(n+1)>fi(n) then |deltarti(n+1)|=fi(n)/fi(n+1) else |deltarti(n+1)|=fi(n+1)/fi(n) end if end i loop |deltaRT(n+1)| = Sum(deltarti(n+1)) total number of routes in RT(n+1)

14. Examples Example 1: –fi(n) = {0, 1, 2, 1, 0, 0} and fi(n+1) = {1, 2, 1, 0, 0, 0} –|deltaRT(n+1)| = (0/1 + 1/2 + 1/2 + 0/1 + 0 + 0) / 6 = 0.1667 (rather stable) Example 2: –fi(n) = {0, 0, 0, 0, 0, 0} and fi(n+1) = {1, 1, 1, 1, 1, 1} –|deltaRT(n+1)| = (0/1 + 0/1 + 0/1 + 0/1 + 0/1 + 0/1) / 6 = 0 (still stable, too early to judge) Example 3: – fi(n) = {56, 20, 63, 64, 0, 5} and fi(n+1) = {57, 19, 64, 65, 0, 4} –|deltaRT(n+1)| = (56/57 + 19/20 + 63/64 + 64/65 + 0 + 4/5) / 6 = 0.783 (very unstable)

15. Relevance to GROW BGP operational issues related to routing table growth rates and the dynamic properties of the routing system. Advisory role to the IDR working group to provide commentary on whether BGP is addressing relevant operational needs and, where appropriate, suggest course corrections => Effort positioned at central place in the BGP investigation process (beneficial for other WGs) Note: effort goes together with obtaining routing table data from the field

16. Concluding remarks We think interesting topic for investigation in GROW and beneficial to other WGs –Analysis/measurement of Internet RS/RT stability –Unified approach to cross-validation of techniques looking at improving path exploration effects on RS Validation of the metric with real data on its way –Several data repositories available but only daily variation (ideally, smaller sampling time) Ex. daily report on BGP activity for AS #65000 –Additional operational data (routing entries) would be appreciated … need to capture variety of timescales Reason: different dynamic behaviour will be observable on different timescales