2.4.5 Global Routing Operations (grow)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-07


Geoff Huston <gih@telstra.net>
David 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-embed-addr-05.txt
  • draft-ietf-grow-bgp-wedgies-00.txt
  • draft-ietf-grow-anycast-00.txt

    No Request For Comments

    Current Meeting Report

    GROW WG Minutes - IETF 62

    GROW Minutes

    IETF 62
    Chairs: Dave Meyer, Geoff Huston
    Thursday 10th March
    9:00 - 11:30 am
    Note Taker: George Michaelson
    1. Agenda Bashing

      no changes to the agenda

    2. Review of Work Items

      Active Drafts

      • draft-ietf-grow-bgp-med-considerations-02.txt
          McPherson/Gill (expired)

        The draft will be re-submitted to the drafts editor. The document is ready for WG last call, which will be made once the draft is published

        Next steps:

        Following submission of revised draft conduct WG last call on the document.

      • draft-ietf-grow-anycast-00.txt


        The WG has adopted this as a WG document. The document includes a summarized deployment history of anycast including intra-AS deployment. The motivation for the document was the observed lack of a reference document on anycast, no ontology or taxonomy, and the scaling issues for anycast appeared to be not well understood. The draft covers goals, protocols, physical and routing considerations for anycast.

        Draft discusses data synchronization issues, node autonomy, multi- service nodes. It may also be useful to clarify in the draft when the provider wishes to publish inconsistent services: present a constant IP address across the anycast set, but deliver different content from different anycast instances.

        Operations - monitoring issues, harder to check nodes are up, routing is stable.


        draft covers about multi-service issues, (tunnel risks) - but many people do this. This should be added to the document.

        V6 anycast problems, scoping issues.

        may be DNS-centric.

        WG Discussion:

        Pekka Savola: not clear to me what you mean by anycast node in taxonomy?

        Joe Abley : The draft uses this term to refer to nodes in multiple locations, globally distributed service in Internet. Nodes may be collection of services anycast over IGP, and may look like single instance to general Internet

        Pekka: You may need to define 'whole' anycast architecture.

        Joe: May need more work on that

        Dave Meyer: When you said IGP related bunch of things. eg IGP overlay of tunnels, global with respect to Internet topology, is that the same?

        Joe: Yes. IGP can be contained to one location or global via tunnels but the external routing visibility is the same

        Kitamura: It appears that there is a need to clarify taxonomy, functionality. I propose anycast BoF for further discussion.

        Dave: V6 anycast needs to note, nothing stops injection of V6 unicast prefix into routing cloud in the same fashion as V4. This constructs same kind of anycast service as V4. Its not the same as V6 anycast a defined in the V6 spec, and they have to be disambiguated. I think deprecate the V6 standard anycast specification may be the way to go.

        Pekka: don't think this draft is DNS centric. Multi-service nodes are a distraction. The main focus of document should be single- service nodes.

        Pekka: MTU issues for the tunnels. need to document.

        Geoff: The appropriate action is to take the V6 Anycast specification to V6 WG, and don't do anything to this draft. Its an open issue, and the standard V6 anycast specification that noone can or does use, and its operationally irrelevant. This appears to be a topic for the V6 WG to grapple. This anycast use draft is adequate as an operational document.

        Next steps:

        refine for WG last call, publish as BCP.

      • draft-ietf-grow-bgp-wedgies-00.txt

        This draft is ready for WG last call. No further comments on Mailing List. Draft describes BGP state when preferences used. There are circumstances where you can receive traffic on non- preffered link, and only coordinated action across multiple ASs can flip the BGP state back to its intended state.

        WG Discussion:

        Pekka: commented 1/2 year ago. comments recorded/addressed?

        Geoff: will do at last call.

      • draft-ietf-grow-rift-01.txt

        Dave Meyer reported that no further work had happened on this draft since IETF61. Some progress is expewcted by IETF63.

    3. WG Review: Tunnel end-point discovery using anycast
        Pekka Savola


      This material has been presented at the Tunnel Config BOF, and it looks at a way to discover a local viable 6/4 tunnel endpoint. The information needs to be NAT viable. May need Well Known Service (WKS) address for anycast discovery using one-packet to an anycast address, and a response with a source address of a local unicast tunnel endpoint. This allows the tunnel to then be constructed. This is a stateless transaction.

      comparable to rootserver anycast.

      issues: works. needs good prefix filtering. weak security.

      whats left: WKS address. DNS population.

      WG Discussion :

      Kurtis: posted to ML that anycast for forwarding plane discovery is bad idea. untrustable. ISP is clueful enough to filter etc. don't like this.

      Pekka: only tunnel discovery. not forwarding plane. fix in tunnel establishment

      Geoff: GROW went through embedded address draft, noting that identifying services by address is really bad idea. manufacturers embedding addresses etc. If the objective is attempting to identify generic type of service, then proposing an address that is used to look into service discovery has the same disadvantage as the embedded address critique. Why not do real service discovery? SLP work. i.e. identify a service by name, attributes. I don't understand why you think its better done down a level by a well known unicast address. This is the same as 6to4 reverse-DNS issue, where Keith Moore explored 'distinguished address' and discounted as weak approach. Not sure you have added it here.

      Pekka: fundamental difference embedding addresses in RFCs for unicast purposes. this is WKS anycast address. does not belong in any operators prefix. outside of unicast allocation space.

      Dave: suppose scheme came into reality. how large prefix needed? scalable? eg /16 for protocol. [pekka /24 ok] not globally routed? [pekka same as 6to4 endpoint anycast] -so its meant to be within service provider only.

      Joe: consider non-routable prefix deliberately to avoid hijacking.

      No WG action proposed

    4. Preliminary measurement results on the current AS level topology


      Lixia still working on highly active prefixes, but this time looking at AS topology changes. public BGP sources, updates from RouteViews/RIPE, IRR

      Previous models always taking dumps. From ripe or routeviews.

      graphs of new AS, rate of new AS visibility in 2004. graph of visibility of links.

      ranking methodology based on topology map, inferred relationships.

      slides of ranking/tier behavior breakdowns for links, new AS, change

      WG Discussion

      Geoff: measures that paths seen in updates are 'real' as distinct from BGP explorations during convergeance.

      Lixia: during slow convergeance, exposes alternate paths, AS links do exist, just should not be used. as opposed to no peering session existing.

      Geoff: so you assume updates expose reality.

      Lixia: depends how you define reality. defined as stable path, no. slow convergeance shows backups. but if reality is existence of AS peering, then yes.

      Gengis: agree with Geoff. True growth or apparent?

      Lixia: do not think this is just transient thing. measured over 3 months accumulated links, nodes over period.

      Gengis: don't quantify here, see all new links, lifetime? eg 2hr transients what if seen twice.

      Lixia: will be considered as existing link. volume of change doesn't count

      Lixia: not measuring stable links only, used for traffic, measuring all existing links, known links.

      Jeff Haas: was data corrected for non-bogus AS paths [no]

      Lixia: additions is in tier2 for links, tier5 for nodes.

      Joe: inter-domain t-e technique. prepending non-local paths, to poison paths. in your data would imply connectivity not there.

      Lixia: no filtering for prepends. But we think exceptions to norm

      Impact on BGP operations:

      convergence time for lower tier AS is longer than tier-1. during slow lower tiers see customer route changes, tier-1 don't do transit so don't see these, only peer(1) changes.

      denser connectivity increases alternate path visibility. makes slow convergence worse.

      WG Discussion

      Jeff: did you see correlation between number of explored paths and convergence time?

      Lixia: definitely. Still looking at topology impact on convergeance.

    5. A mechanism to enable fast routing table recovery after BGP session reset
        Nischal Piratla.


      inefficient recovery from transient session resets

      propose bloom filter to encode routing table. exchange digests

      compact size, low b/w cost to share. low false positive rate

      false positives can be filtered by hash functions in digests. 0.003% left

      WG Discussion:

      Pekka: trading off b/w for processing cost. compute matches cost against sending the BGP

      Tony: what do you see as the constraint on convergeance?

      Nischal: table sending time. time to reach convergeance is long

      Tony: time for convergeance has interesting things, its more than the bit size on the wire. time is dominated by processing not transfer of data. this minimizes b/w. inconsistency detected is only the presence of routes. even with exchanged hash, but path attributes may need to be exchanged. eg session reset then requires the full set of updates anyway. they will all disagree

      Lixia: digest is not calculated on every update. more periodic. do not have to instantly re-calc. secondly, after session reset try to avoid huge prefix swap, by just examining which entries have changed, only exchange updates as incrementals

      Tony: BGP already does incremental updates. don't understand where this is going.

      Joe: confused as to the goals. few routes different, session gets reset and entire table is sent. this model has to do almost the same amount of work apparently

      Nischal: not entire entry, just prefix

      Chandra: think issue here is that even one blackhole route is not good. fixing false positives is good, but if has known error rate

      Jeff: even if have perfect way to keep tables in sync, session reset will require invalidation, regardless of overhead, processing etc cost is significantly less than route selection on entries.

      Vila: exchange network b/w for router memory. use graceful restart doesn't matter how long takes, traffic flows. whats the point

      Jeff: doesn't preserve forwarding table

      Yakov: why use graceful restart. flaps. spend bit more effort trying to reduce BGP flood, help other things anyway

      Tony: cannot stop the backhoe. using this to schedule updates is good, accelerate convergeance, schedule deltas ahead of full table but still have to send full table. simpler mechanism for all of this. put the work on sender side with its incremental updates using re-sync procedure, schedules, floods first, then trickle older updates later. can do that no problem. This is a wonderful technique, but it is more applicable to ISIS,

      Henk: calc/processing overhead. measured? against eg stable situation adding one route inconsistency, measure time, effort compared to classical?

      Nischal: do normal BGP costs more: digest exchange costs max 760k, full table costs 5+Mb.

      Chandra: status? intention?

      Nischal: grow, or other places, have to sit and decide.

      Dave: not appropriate for operations group

    6. BGP Status Report


      WG Disussion:

      Dave: how many more specifics relate to rational strategy (TE) as opposed to badness.

      Geoff: tracking that.

      Yakov: AS runout or IPs first?

      Geoff: AS by about 2 years.

      more instability coming because of convergeance on AS paths M&A, more tier3/4 coming up the food chain

      V6 routing, flat BGP announce, 2x covered address space. 500 participants

      still overlay network (only 9 v6 only instances, no transit)

      10% aggregation possibility


    Operation of Anycast Services
    Tunnel End-point Discovery (anycast perspective)
    AS Level Topology Growth: A Preliminary Measurement
    FRTR: A Scalable Mechanism for Global Routing Consistency
    Routing Table Status Report