2.4.5 Global Routing Operations (grow)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20


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
Done  Submit MED Considerations to IESG for Info


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

    Request For Comments:

    RFC4085 BCP Embedding Globally Routable Internet Addresses Considered Harmful

    Current Meeting Report

    GROW WG - IETF64

    Global Routing Operations WG (grow)

    Minutes of GROW WG Meeting at IETF64

    Monday, November 7 at 0900-1130


      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

      Active Drafts

        draft-ietf-grow-rfc1519bis-02.txt (Proposed Standard)

          AD Evaluation has been completed, and review comments have been passed back to WG chairs and document authors. The review comments are to be addressed in another revision of the draft.

          A request was made of the chairs to circulate the AD Evaluation review comments to the working group mailing list.

        draft-ietf-grow-collection-communities-08.txt (BCP)

          This is a longstanding work item intended to provide a common means of interpreting the communities that were being passed to route collection points. The document has been in the RFC Editor Queue awaiting the completion of the BGP Extended Communities draft in order to normalize the document's references. Yakov Rekhter has suggested these community values being recorded in an IANA registry as a means of allowing future extension of community values as an IANA registry transaction. The AD advice is that required document edits to effect this are relatively minor and can be made in-situ without re-passing the document back through the entire document review process.

        draft-ietf-grow-anycast-02.txt (BCP)

          In Working Group Last Call as a candidate BCP (Last Call ends on 19th November 2005).


          [presentation by Larry Blunk]

          Current consideration is related to the timestamp (first field in basic header) which uses a 32 bits (no microseconds). A further revision of the specification has added OSPF support for microseconds. Security Considerations also added.

          The -02 revision is proposed to include specification of an IANA Registry for Type/Subtype codes, and support for 4-byte AS numbers. The question was asked whether there was support for adding microseconds for RIP support. Regarding the proposed IANA Registry the document author will make suggestions to the Working Group on this.

        draft-ietf-grow-bgp-med-considerations-04.txt (Informational)

          Dave Kessens will either send AD Evaluation comments to the authors and Working Group co-chairs, or submit this for IESG review by week ending 18th November 2005.

      Proposed work items


          [presentation by Bill Fenner on behalf of the authors]

          This draft proposes adding a wrapper around BGP messages to allow these messages to be duplicated and forwarded from a BGP speaker to a monitoring station. There is a considerable volume of BGP monitoring being undertaken, but the predominate current method is by explicit BGP peering with a monitoring station. This would allow a monitor to receive updates as they are forwarded from BGP peers, rather than only collecting updates that are passed on the Adj-RIB-out.

          Working Group discussion noted that this would allow greater flexibility in terms of monitoring incoming BGP information from peers.

          The proposed message types to be flagged in the wrapper protocol include incremental BGP updates, peer up/down state transitions, and table dump (Adj-RIB-in if available, Loc-RIB if that's all you have). The proposal deliberately does not define data storage formats.

          There was a favourable response to the flexibility this offers on monitor report formats. A query was raised if this monitoring function be combined with what actually gets accepted by the router, comparing Adj-RIB-In with Loc-RIB changes.

          The question was asked as to adopt this as a working group document. Not enough people have read the draft (the people who had read it agree to adoption).

          It was decided to take it to the mailing list and request more working group members to review the draft.

          The question was raised that this has an element of protocol specification, and is this properly managed in an OPS Area Working Group.

          The matter would be raised with the OPs ADs.

          The question was raised about including flags for identifying 2-byte or 4-byte AS BGP sessions, so receivers don't have to work though any potential ambiguity cases. figure this out? It was noted by Bill Fenner that this would be a great addition to state the capabilities you've received at BGP Open even if you aren't monitoring at open time.

    4. Update from the NANOG IAB IPv6 multi-homing BOF

      Dave Meyer


      Some constituents in the operator community are evidently not in line with SHIM6 direction and some are feeling disenfranchised by IETF in general. The NANOG BOF was attempt to close this loop. Minutes and Real media video are available on NANOG website. Metagoals around IPv6, around operators at IETF.

      The BOF had explained the IAB's role. Geoff Huston had presented SHIM6, and then the operator perspectives were sought.

      Some operators were confused about current state of the spec. It was noted that there was the message that SHIM6 is not necessarily the complete answer in the multi-homing space, but neither was Provider Independent address allocation from the registries.

      This is one data point, not the only one about what operators think about SHIM6 and about IPv6.

      Service provider conclusions - SHIM6 doesn't address Traffic Engineering (TE) requirements (although injecting prefixes doesn't, either), and TE must be supported on day one - and SHIM6 may even be in conflict with TE requirements, There was the question regarding unicast RPF and firewalls, and about inbound TE with transit ASes. It was noted that PI for IPv6 gives a much larger swamp in the routing space, and additional complexity is not a good thing for implementers or for operations.

      Content provider conclusions - don't like state in servers, concerned about roundtrips before first content delivery, what about short-lived conversations?

      Geoff Huston - short-lived conversations implies SHIM6 is aware of transport sessions, but it's not - SHIM6 is at IP layer.

      Erik Nordmark - what was concern about state in servers that have TCP time-wait state anyway? SHIM6 state could be in the noise by comparison.

      Dave Meyer reported that Vijay Gill (at NANOG) expressed concern about complexity and cost constraints with support provisions for low-margin customers. E-mail from John Payne - do not put TE in hands of end users, it's at a site level (at least with overrides).

      First hit is of critical importance, don't hunt through DNS to find a locator that works. What other multi-homing work is going on?

      Dave will compile materials for IAB web site next week, and has volunteered to run the session at APRICOT 2006.

      Jordi Palet - we need white papers to get this resolved.

      Dave - response in the form of an up-to-date review of what GSE was and bring it back into the IETF, write a document that builds on the multi6 architecture document, and work though the final barriers to IPv6 deployment.

      Spencer Dawkins - one comment from NANOG was that providers are very concerned about host-based solutions when they have so little control and influence on individual host behaviours. If they override what hosts do, why are we using a host-based solution?

      Kurtis Lindqvist - look at what's happening in RIRs - there's a lot of pressure on RIRs to allocate PI now. And there's nothing providers can do to prevent customers from sending traffic any direction they choose now.

    5. BGP Status Report

      Geoff Huston


      IPv4 routing table size. We were seeing a lot of advertisement fragmentation around 2000, but this stabilized in late 2001, but we're now on another growth trend in terms of prefix size.

      Routing table now growing at 25,000 entries/year. Now announcing a total of 1.4 billion /32 IPv4 addresses. More-specific announcements (ignoring AS path differences) - seeing about 60,000 entries at most observation points. "Root prefix announcements" is growing at a faster rate than the total table. AS numbers growth is steady. We think this is multi-homing at the edge. Average AS path length is actually slightly falling, and the observed AS length radius of the network isn't growing, it's compressing (to about 3.6 ASes)."If you could aggregate IPv4 prefixes", could drop about 60,000 entries that aren't adding any additional reachability information to the routing table. About 10,000 routing entries are obviously trying to do TE, and a larger number is uncertain whether there is local TE. Also seeing "checker boarding" - people who don't advertise all of a prefix. Two thirds of entries in the path are about path differentiation, not about reachability.

      IPv6 routing table is still about 800 routes. Some address disaggregation coming out of Korea late 2004 / early 2005. Recent growth in advertisements probably attributable to recent workshop activity.

      Geoff did some numerology with the IPv4 address counts. Currently seeing 85 /8-equivalents in the routing table. Applied a smoothing function, then performed a first order differential. This yields a noisy wave-form, but on average we are growing in the routing table by 5-6 /8s per year. First-order differential of log function is flat right now. RIRs have given out another 40 /8s that we can't see in advertisements. The total size of this unadvertised address pool is still growing, but at a rate that is slowing. A projection exhaustion point of the IANA unallocated pool was predicted to be in 2012, and the first RIR exhausts into local address pool about a year later. But this is a "well-ordered" model, and we have to expect some form of rush in address allocations - which we can't model.

      Pekka Savola - would expect that the RIRs become more conservative when they are running out of space to allocate.

      Geoff reported that RIRs are responding to members needs. Its not entirely sure that the allocation policies would change in the time available. http://ipv4.potaroo.net shows allocated versus advertised space graph which has some interesting data for the current year in terms of allocated space and advertised address counts.

      Cengiz - Based on this, do we have to switch to IPv6 because we are running out of IPv4 addresses?

      Geoff reported that we are using unallocated addresses now as the basis of address distribution, and following the exhaustion of that pool, players would need to be more creative about finding addresses to meet their needs. A lot of current damping of the potential routing table growth is due to RIR policies relating to address allocation from the unallocated pool. When this pool exhausts, there is a likely switch in the address distribution model to forms of address trading. However, it's unlikely that we can aggregate the distributed addresses in the same way as we do now - one possible outcome is rapid unconstrained growth in the BGP table once again.

      Ron Bonica - old prefixes that are disappearing? If you reclaimed those prefixes, how much longer?

      Geoff - reclaim and issue at higher address compression point would give you up to 2026 in terms of total address lifetime, but that assumes an almost perfect model of bringing addresses back into the network.


    IAB BOF Report
    Routing Report