Draft Status:
* filtering-threats is now in last call.
* refreshed error-handling document.
* route-leak problem definition, talked about today.

* expired: bgp-shut - discussion with the chairs.

A new bgpdump tool:
* new tool to read the MRT dumps - aiming to add new features.
* bgpdump2 - found at https://github.com/yasuhiro-ohara-ntt/bgpdump2
* compatibility with libbgpdump partially implemented.
* add new features, to show e.g., display per-peer stats, and routing table.
* speed advantages over zebra and libbgpdump.
* diff mode between peer RIBs implemented - along with the ability to look up
 the longest match for a particular address, combined to compare reachability
 between two peers.
* can be used to check reachability to certain prefixes, and understand any
 holes in routing.
* analysis of multiple files for e.g., prefix count, possible to provide analysis
 of statistics across multiple files, at multiple times.
* looking at the output of the tool raises a number of queries as to how the data
 can be parsed to determine quality.
* some features to be added:
* regexp on AS_PATH and NEXT_HOP.
* regexp matches for AS_PATH and COMMUNITY.
* name resolution for ASNs using the Team Cymru DNS interface.
* Questions:
* Colin Petrie (RIPE NCC): the ordering of the peers in the quagga output is
 affected when a new peer is configured and/or one transitions up. did the
 number of peers change?
* (A) yes, they did.

draft-ietf-ops-grow-for-error-handling:
AD comments: we'll get re-review with ADs on this document.
Chair comments: we'll need some reviews during WGLC.

bgp timestamping:
* also presented in idr
* timestamping within BGP messages to allow analysis.
* critical to understand where BGP message propagation is important for services
 to work. important to be able to monitor:
  * more services using BGP & mixed on the same devices.
  * some more critical than others, understanding which impacts each is important.
* aim to have a simple mechanism - aim to have a single point of listening, rather
 than monitoring multiple points - to avoid complexity of having correlation,
 especially inter-AS.
* proposing a solution (in idr) - new BGP attribute, BGP-TS (timestamp), vector that
 is added to on each hop for the send+receive operations.
* aiming to do the timestamping on a small number of prefixes (real, or beacons) - not
 on all.
* Q (Doug Montgomery): where do you set this attribute, on send or on receive? since
 a route may sit in the RIB-IN for days before being selected as a bestpath?
* A: set on both, after discussion in Toronto. we aim to use this for probe prefixes
 so that they are automatically selected as bestpath.
* Q (Doug): does this work for more than just probe prefixes?
* A: yes, it can be set for *any* prefix, but may not measure convergence.
* Q (Rudiger): actually expect that we are more interested in how old the real prefixes
 are, we do not want these flapping and showing how good the convergence of the network
 is!

route-leaks:
* two new types of route-leaks added - type 6 and 7.
* 6 is a leak of provider prefixes to a peer.
* 7 is a leak of peer prefixes to a provider.
* detection mitigation draft has also been revised to have solutions for 6 and 7 (see the
 idr draft)
* Q (Jen Linkova): reading the draft, I am surprised that you do not mention that the
 more specifics can be leaked with ASes on the path to the victim are inserted, so
 that they do not see this route.
* A: (missed comment)
* Chris Morrow: In the Iceland example, the routes were leaked with the AS_PATH unmodified
 and re-originated.
* Q ( ): I think that you say that you are not intending to classify all the types of
 route leaks.
* A: yes, we are trying to cover those that regularly happened.
* Q: it would be better to classify all different types of route leaks in the draft.
* A: we didn't intentionally exclude anything, but rather cover what is being thought of
 as route leaks.
* (Doug Montgomery): Trying to look at all leaks would mean that we re-present each time.
  if there are other cases, then we can try and cover them. think that there is some use
  in having a taxonomy that is non-exhaustive.
* Please let authors know if there are classifications that should be included that are
 not.

Chairs: see you in Prague!