2.4.4 Global Routing Operations (grow)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27


Geoff Huston <gih@telstra.net>
Dave Meyer <dmm@1-4-5.net>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Technical Advisor(s):

Bill Fenner <fenner@research.att.com>
Vijay Gill <vijay@umbc.edu>

Mailing Lists:

General Discussion: grow@lists.uoregon.edu
To Subscribe: majordomo@lists.uoregon.edu
Archive: http://darkwing.uoregon.edu/~llynch/grow/

Description of Working Group:

The Border Gateway Protocol (BGP) is fundamental to the operation
of the Internet. In recent years, occurrences of BGP related
operational issues have increased, and while overall
understanding of the default-free routing system has improved,
there is still a long and growing list of concerns. Among these
are routing table growth rates, interaction of interior and
exterior routing protocols, dynamic properties of the routing
system, and the effects of routing policy on both the size and
dynamic nature of the routing table. In addition, new and
innovative uses of BGP, such as the use of BGP as a signaling
protocol for some types of Virtual Private Networks, have created
new and unexpected operational issues.

The purpose of the GROW is to consider the operational problems
associated with the IPv4 and IPv6 global routing systems,
including but not limited to routing table growth, the effects of
the interactions between interior and exterior routing protocols,
and the effect of address allocation policies and practices on
the global routing system. Finally, where appropriate, the GROW
documents the operational aspects of measurement, policy,
security, and VPN infrastructures.

GROW will also advise various working groups, including the IDR
and RPSEC working groups, with respect to whether it is
addressing the relevant operational needs, and where appropriate,
suggest course corrections. Finally, operational requirements
developed in GROW can also be used by any new working group
charged with standardizing a next generation inter-domain routing


(i). Evaluate and develop various methodologies of controlling
                policy information in order to reduce the effect of
                prefix sub-aggregates beyond the necessary diameter, so
                as to reduce the Network Layer Reachability Information
                (or NLRI; see e.g.,draft-ietf-idr-bgp4-23.txt) load on
                network infrastructure.

(ii). Document and suggest operational solutions to problematic
                aspects of the currently deployed routing
                system. Examples include instability caused by
                oscillation of MULTI_EXIT_DISC (or MED; see RFC 3345)

(iii). Analyze aspects of supporting new applications, including
                extending existing routing protocols and creating new
                ones. This includes risk, interference and application

(iv). Determine the effect of IGP extensions on the stability of
                the Internet routing system.

(v). Document the operational aspects of securing the Internet
                routing system, and provide recommendations to

Some Relevant References:

Goals and Milestones:

Done  Publish Risk, Interference and Fit (RIFT) document as WG I-D
Done  Publish Embedding Globally ...Considered Harmful as WG I-D
Done  Publish MED Considerations Draft as WG I-D
Done  Publish Collection Communities as WG I-D
Done  Submit Collection Communities to IESG for BCP
Done  Submit Embedding Globally ...Considered Harmful to IESG for Info
Dec 04  Submit the RIFT document to IESG for Info
Feb 05  Submit MED Considerations to IESG for Info


  • draft-ietf-grow-collection-communities-06.txt
  • draft-ietf-grow-bgp-med-considerations-04.txt
  • draft-ietf-grow-bgp-wedgies-03.txt
  • draft-ietf-grow-anycast-01.txt
  • draft-ietf-grow-rfc1519bis-02.txt
  • draft-ietf-grow-mrt-00.txt

    Request For Comments:

    RFC4085 BCP Embedding Globally Routable Internet Addresses Considered Harmful

    Current Meeting Report

    GROW WG - IETF63

    Global Routing Operations WG (grow)

    Minutes of GROW WG Meeting at IETF63

    Monday, August 1 at 1815-1945


      Geoff Huston <gih (a) apnic.net>
      David Meyer <dmm (a) 1-4-5.net>


      Spencer Dawkins <spencer (a) csr-labs.org>


    1. Administrivia

    • Mailing list: majordomo@lists.uoregon.edu "subscribe grow"

    2. Agenda Bashing

    • no changes to the agenda

    3. Review and status of work items


            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?

            David Kessens - The Operations and Management Area working groups don't usually do protocol work. David indicated that it is no problem to document running code and get a document published quickly but that we don't want to do extensive protocol development in the OPS area. If there is a need, it would always be possible to do a new version but we will need to discuss then whether that will need a working group or that we use some other approach.

    4. 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?

    5. 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!

        • 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...

    6. 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.

    7. 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.

    8. 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.


    Req’t for planned maintenance
    Securing Routing
    SHIM6 Overview
    Quantifying BGP Path Exploration
    BGP Status Report