draft-manderson-grow-geomrt-00
     - Terry M presenting draft on geo mrt
     - extension to mrt format
     - 3 people read draft
     - introduce mrt type field and related sub fields
     - one suggestion to escalate collector gps coord. outside of the bgp format
     
     - table type number 65
       - okay or use different number?
       - suggestion to petition IANA for number
     
     - implementaion example presented
     - Demonstration of implementation with Zebra
     - code diffs will be made available at some point
    
     - suggestion made to be able to get geo location from dns

     - polled room...3 interested
     - Interest in this document - going to list

draft-jasinska-ix-bgp-route-server
     - Elisa presenting draft 
     - description of what an IXP is
     - n*(n-1)/2 bgp sessions where n is number of routers at exchange
     - proposing route-server system
       - multilateral interconnect with route-server
       - immediate dense interconnection
     - 3 open source implementation but no reference or documentation
     - 
     - operations considerations included in draft
     
     - RFC 1863 not mentioned in draft, should be
     - Danny commented rfc1863 should be referenced route server 
          - concern if people want to implement static configurations - filter peers plan to 
            implement sidr origin info.  issue with prefix filtering off irr's
     - Jeff ?  suggestion - dig up original route server drafts, don't even think about route reflector
         - contact merit, last operator of route servers rt config software mode specifically
           for building view base policies.
     - question: if i want to filter prefixes, how do i know what AS they 
                 connect to?  
     - suggestion made that 1863 is not relevant
     - rtconfig can be used for filtering
     - author thinks RPSL is out of scope
     - 
     - question:  how does one implement max prefix in this model?  do we trust
                  route-server
           - route-server implements max-prefix on the server side
           - can get statistics from route-server about number of prefixes announced
     - everyone agrees better protection on the bgp sessions would be great
     - currently informational draft, can talk about this further and will need to
       talk to IDR about updating bgp spec

     - Eduardo ?? - runs route service, going to double size in Brazil - is looking for other implementations
     

draft-ietf-grow-diverse-bgp-path-dist-02
     - RObert Raszuk presenting update on draft
     - intended to be informational, no changes to any protocols
     - fully backward compatible with current RR deployment
     - presented deployments models
       - today only get 1 best path
       - with diverse path you can get N paths 
       - model 1 - disable med check on best path selection
       - model 2 - add additional session to announce 2nd path
     - works in standard IP and MPLS networks
     - works with any AFI/SAFI
     - open issues:
         - memory concerns on clients
         - not unique to this technique...anything that sends more paths will have 
           this
     - question:  are they changing bgp path selection?
         - no, hacking existing system to forward non-best paths
     - wait till beijing for last call
     - John Scudder - asked in your closing remarks, prefer to last call after implemenation


VA
     - main drafts: (No IPR associated with them)
        - draft-ietf-grow-va-02
        - draft-ietf-grow-simple-va-00
     - auto-config draft
        - draft-ietf-grow-va-auto-01
     - no implementations at this point
     - should we move main drafts to information rfc? 
       - no comments, taking to the list
     - auto-config draft
        - draft-ietf-grow-va-auto-01
        - completely optional
        - move to informational? 
          - no comments


draft-uzmi-smalta-00
     - aggregation work introduced at ietf 76
     - presented outling of fib aggregation draft
     - level 1-4 aggregation
     - smalta has level 5 agg
       - better agg
       - no extra routable space
       - comparable update processing
     - presented comparative summary
       - 39% compression, 10% more than level 2
     - presented basic idea of fib aggregation
       - level 1 and level 2 are similar, level 1 drops specifics, level 2 combines         specifics
       - smalta exploits all methods
       - explanation how it works
       - 
     - how far aggregated after N updates
       - loses 1-6% of fully-aggregated state
     - how many rib-to-fib downloads per update
       - each update may result in ust one change in original table
       - rib-to-fib downloads exactly 1 with no agg, 0,1, or more with aggregation
     - Danny McPherson:  using live data or a snapshot of routing table
         - using snapshot and applying updates to do analysis
     - smalta one shot aggregation takes 300-400ms
     - 3-4x more processing than L1 and L2, applied very infrequently
     - smalta update same processing time as L1 and L2
       - fewer avg rib-to-fib downloads in smalta
     - question about analysis, do the numbers remain over longer periods?

     - Demetre - when you increase the period do you know how the deteriation of gain would be?
        - expect to lose more of aggregated state over a longer period

     - Comment - Longer time period could show different results.  Day to day patterns also change.  If you
          look at larger sample of routers compression could change.
     - lixia agrees different time periods could effect data
     - waiting for new combined draft before taking it further