Note taker - Chris Morrow (me)

First Presentation - Vince Fuller - 240/4 ops-area/grow implications
  draft-fuller-240space-01.txt
(slides: http://www.vaf.net/prezos/240-4.pdf)
 - 240 re-purpose discussion
  a) make 240/4 public
  b) make 240/4 private (draft-wilson-classe-01.txt)
  c) split 240/4 to pub/private
  d) none of the above

 - seems there's agreement to do 'something', change os/routing
 - running code exists (linux distros)
    linux
    macosx/freebsd
    solaris
    ! microsoft
    bug fixes filed for IOS. DCOS
    not sure about JunOS
 - possible issues in 6to4 code?
 - not a panacea, but would provide a little more length for v4 free-pool
 - THIS IS AN INT-AREA project, no current home, comments on
grow-list, int-area-list, ietf-list is required to find it's proper
home.
questions:
  danny mcpherson - future-use, what is the definition of that? Is
this in/out of future-use?
   lixia zhang - in GROW? or not? why not?
 poll for doc usage: most say doc would be good, not sure on home yet.

Dimitri - draft-dimitri-grow-rss-01.txt
(slides:  )
 - Better understand dynamics behind internet routing system
 - increase efficiency of BGP process(es)
 - current work outlines dependencies on routing system
   - peers
   - size of routing table
   - processing of lookups
 - Objective - Document and find root-cause of stability phenomenon
                      define stability criteria
                       document behaviour of routing protocol and
network behaviour
 - stability changes - under influence of internal and external events
 - Difficulty in defining high level definition/language for
stability measurement
   - convergence
   - stability
 - how does the above change depending upon size of table, # peers,
processing power
 - ouch.. math!
   - how to measure/define a routing stability metric
   - how to ... (missed this)
   - major point is stabiltiy metric of 0 == stable, 1 == unstable
     define a method to devise the above repeatably
     push this measurement back into IDR to metric changes in IDR for
better ops behaviour, not just adding bgp/routing features without
         assessing such impact
 - currently measuring timescale == 1 day, want to reach a point to
calculate/hour/min/second and per node/as/set-of-nodes
 - Looking for sources of routing table/update data, pointed to RIPE/RIS
poll for placement - work is useful, and relevant to GROW-WG (by
hand-vote in meeting)

LIxia - Research work - "understanding global Internet routing
stability using link weights"
 (slides: http://www.ietf.org/proceedings/08mar/slides/grow-0.pdf )
   research work from student at UCLA (from RIPE)
 - focus on identifing routing change WHERE not WHY.
    - identify repeated events
 - system is large with many players
  - many viewpoints
  - many different results from these views
- approach is to use 'link weights'
  - watching 'traffic' or routes over a link
  - note changes to that link, infer traffic/routing shifts
  - stack events by PCA (principal component analysis) find largest
events first
    - magnitude of change and number of change (by monitors) over time
    - include both for the metric
       (large event in one monitor different than one event seen everywhere)
    - also bin events in time buckets
   - blinky pictures ...
      - demo of PCA on a simple 10 AS system
   - discussion of changes and calculating changes
   - Using PCA to identify magnitude (local and global) of routing
system changes
   - Currently analyzing RouteViews and RIS data over time series
(Jan-Dec 2007)
     - limited to only full-table providers
     - 10 min bins
     - finding both large events 'everyone' sees and 'bad places'
(lots of repetitive changes)
     - documenting some of what ops already knows, some places are
worse than others for ongoing routing churn.
 - using LInkrank to dispay this output:
    http://linkrank.cs.ucla.edu/
    - monitoring changes to links as viewed by RouteViews monitors
    - bgpmon still being tested and perhaps installed into
rouetviews, include real-time event data from RouteViews into LinkRank
      (in use already at UCLA)
 - see pdf for link to more details
- questions -
  Susan Hares - data seems to be the same as 1990 data
                              main or backup path being viewed?
                  lixia - not watching individual paths, watching
global changes
   Susan Hares - important to watch backup paths - secondary paths -
routeviews data skewed on update rate and path calculation since it's
only the single view's primary path data.
                  lixia - only get primary path data at these monitoring points
  Geoff Huston - watching prefixes not what you want, depending on
interpretation?
                             can't link this data to topology nor update load?
                              what are we measuring?
                    lixia - can we move this off to list for discussion?
      (overall 'yes')
  danny mcpherson - ibgp update frequency/dynamics + external display of that