grow: draft minutes of the GROW WG

[David Meyer <[e-mail]>]

	Thanks to Spencer for serving as scribe.

	Dave & Geoff


Global Routing Operations WG (grow)

Monday, August 1 at 1815-1945
=============================

CHAIRS: Geoff Huston <[e-mail]>
        David Meyer <[e-mail]>

Notes: Spencer Dawkins <[e-mail]>

AGENDA:

o Administrivia

   - Mailing list: [e-mail]
                   subscribe grow

o Agenda Bashing

   - no changes to the agenda

o Review and status of work items

   Published
   ---------
   draft-ietf-grow-embed-addr
      Published BCP105 (RFC4085), June 2005


   RFC Editor Queue
   ----------------
   draft-ietf-grow-bgp-wedgies (Informational)
   draft-ietf-grow-collection-communities (BCP)

   AD Evaluation
   -------------
   draft-ietf-grow-bgp-med-considerations (Informational)
   draft-ietf-grow-rfc1519bis (Proposed Standard)

   Active Drafts
   -------------
   draft-ietf-grow-anycast-00.txt - Abley/Lindqvist

     - Some text edits from comments on the list - removal of host-based
       anycast prohibitions, etc.

     - Has this rev addressed all comments?

     - DNSOPS has lots of DNS-specific considerations - probably can't do
       this level of specification in a general-service document.

   draft-ietf-grow-mrt-00.txt - Blunk

     - Simple timestamps, used with BGP4 (but would work with other routing
        protocols).

     - Additions (IS-IS, microsecond resolutions).

     - Several implementations, several deployed (Packet Design and
       ArborText are using it).

     - Don't specify transport at this time. People tend to use local
       storage - is this a problem? Current format isn't storage-efficient.

     - Any interest from router vendors? Are microsecond time resolutions
       needed for OSPF or RIP?

         Dave Kessens - this draft is the charter, but in the Operations
         and Management Area working groups don't usually do protocol work.
         Advice to get it out quickly, and maybe do a second pass later.

o Potential New Work
------------------
   draft-dubois-bgp-pm-reqs-01.txt - Dubois

     - Would like to have "make before break" BGP4 behavior. Currently BGP4
       loses packets while peers look for alternate paths during shutdowns,
       etc.

     - What are the interactions with other new BGP4 capabilities?

         David Meyer - Not enough people in this room expressing opinions
         to get a sense of the room on bringing this into the working
         group.

         Geoff - is this a proposal for an internal mechanism for a router,
         and not a protocol activity?

o BGP Operational Security
--------------------------

   Geoff Huston

   Need to understand the goals - protect router protocols and
   infrastructure? Protecting the protocol payload?

   How do you know the routes you are getting are authentic and accurate?
   The system we have today is relatively insecure, vulnerable to
   corruption and to subversion.

   Rough trust and datamining through WHOIS records isn't nearly sufficient
   for security. Basic data isn't good data, so you can't go anywhere based
   on it.

   BGP4 should still be a "black box" protocol, and should still be "near
   real time".

   Start doing the work now, don't wait for the protocol to catch up.
   Signing routing requests would be good. Authorization of advertisements
   would be good.

   Next steps? PKI for IP addresses and AS numbers, certificate repository
   infrastructure, operational tools, signature information of BGP Update
   attribute.

   Is there interest in GROW in working on specifications and descriptions
   of tools?

   WG Commments:

   - can't help with the specification, but this is interesting.

   - is this PGP for BGP? depends on where the trust anchors are... rings
     of trust would be hard!

    - something to improve this mess is different. Details still need to be
      worked out. A routing registry that runs an authentication /
      authorization scheme gets you partially there, and not all the
      routing registries are totally devoid of data quality.

    - who would pay for the PKI? Who would pay for it? IANA, RIRs, ISPs,
      further allocations... people at each level pay for their part?

    - why not S-BGP? You need the certificate infrastructure no matter
      what, maybe we don't need to wait for the protocol.

    - We are at such a sad state that it doesn't matter what we do - we
      couldn't make things worse! <multiple groans>

    - There are existing groups with some congruence here - SO-BGP looked
      at rings of trust, but you're never sure if the ring is really
      trustable!

    - The problem is political, not technical (not JUST technical). That's
      the obstacle. If operators say "we need this", that would help a lot.
      Although RIRs cooperate, they tend to be independent and want to
      remain that way. A ring of trust might be easier to start with.

    - Problem is worse than you think - anyone who was involved with RPS
      has seen this movie. What has changed in five/ten years? Big players
      wouldn't buy in then, and if they don't, it's not worth doing. Maybe
      doing the least that is still useful is a good part.

    - If all parties don't have keys on day 1, we still have to handle
      this...

    - These problems seem to be solved in all of the BGP proposals. Once
      you know what you want to carry in BGP, carrying it is trivial.

   Will follow up on the mailing list and get more views.

   Lots of interest in the topic expressed in the room...

o SHIM6 update
--------------

   Kurtis Lindqvist

   Meeting at this IETF for the first time (this is a continuation of
   MULTI6, producing protocol specifications). Eight documents resubmitted
   as SHIM6 drafts.

   A lot of questions remain - state management, identifier
   characteristics, locator pair detection, etc.

o Routing Convergence: An Update
--------------------------------

   Lixia Zhang

   Reporting measurements on BGP slow convergence... controlled experiments
   and simulations say this can be really bad, but we need real data.

   Measured the routing changes of ALL prefixes visible from one of 28
   routeview collectors in Oregon - will add more later, plus RIPE data.

   Methodology - group events, classify based on before/after AS paths,
   calculate update count and duration of different types of events.

   Categories - same path, path disturbed during the event (but not after),
   and path changed after event.

   Sometimes "slow convergence" is no convergence - policies point to one
   path, unless you have multiple providers.

   The further you are down in the hierarchy, the more paths you see over
   time.

   Tier-1 to Tier-1 convergence is pretty quick. Tier-5  to Tier-5 is NOT!

   90-95%  converge in 2.5 minutes, but there's a long tail (15 minutes,
   even longer in extreme cases).

   False flap dampening also more likely to happen at lower tiers.

o BGP Status Report
-------------------

   Geoff Huston

   Back to 160,000 entries, back to accelerating growth just like the 1999
   - 2001 period. But this isn't just fragmenting prefixes this time, it's
   announcing new address spaces. Number of more-specifics isn't
   accelerating - this isn't the source of the problem.

   Linear growth in AS numbers - we'll run out of two-byte numbers in 2010,
   ask your vendors when they are implementing four-byte numbers.

   IPv6 addresses is slowing leaving the 6Bone, RIR allocations have
   significant step functions in announced address spaces.

   10 ASes that originate ONLY IPv6 prefixes.

     Geoff Huston - Is 4-byte draft stable? It's only getting new dates on
     the last three revisions.

     Bill Fenner - we need implementations to move this forward

     Geoff Huston - but I am lead to understand that there will be no
     implementations from vendors until customers demand it, customers
     don't demand it until it's obviously a current problem and there's an
     RFC to quote, so no code is released before the time when we have
     already run out - a looming problem for 2010!

     Sue Hares - we can help with numbers for implementors...

     Bill Fenner - we may change the RFC publication rules so we don't hang
     indefinitely waiting for implementations.