2.4.5 Global Routing Operations (grow)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-09-10

Chair(s):
David Meyer <dmm@1-4-5.net>
Vijay Gill <vijay@umbc.edu>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Randy Bush <randy@psg.com>
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 continue and expand on the original charter of the PTOMAINE WG. In particular, the purpose of the GROW is to consider and measure the problem of 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 whether it is addressing the relevant operational needs, and where appropriate, suggest course corrections. Finally, operational requirements developed in the GROW can also be used by any new working group charged with standardizing a next generation inter-domain routing protocol.

GOALS: -----

(i). To provide a clear definition of the problems facing Internet Routing Scaling today. This includes routing table size and route processing load (former PTOMAINE goal).

(ii). To collate measurements of routing table scaling data and publish a reference list (former PTOMAINE goal).

(iii). To discuss and document methods of filtering/aggregating prefix information and to discuss and document what support from protocols or vendor knobs that might be helpful in doing this. In addition, to suggest policy guidelines to RIRs, LIRs and/or ISPs for allocations and aggregations,etc. that may be useful (former PTOMAINE goal).

(iv). To determine the long and short term effects of filtering/aggregating prefixes to reduce router resource consumption.

(v). To develop methods of controlling policy information propagation in order to limit the need for propagation of prefix sub-aggregates.

(vi). To determine the effects of using BGP as a signaling mechanism on the scalability of BGP (e.g.,. draft-ietf-ppvpn-rfc2547bis-03.txt)

(vii). To determine the effects of interaction of new IGP techniques (e.g., ISIS-TE) on the stability of BGP and in particular, what techniques are required to isolate the global infrastructure from the any of the dynamic properties of such TE systems.

(viii). GROW will document operational aspects of routing security and will provide recommendations for protocol specific work to RPSEC, IDR, and other WGs in Routing area.

Some Relevant References: ------------------------- http://www.routeviews.org http://bgp.potaroo.net http://www.cidr-report.org http://www.pch.net/routing/BGP_table_size.html http://moat.nlanr.net/AS http://www.apnic.net/stats/bgp http://www.merit.edu/ipma http://www.caida.org/projects/routing/atoms

Goals and Milestones:
Jun 03  Submit Problem Statement Internet Draft
Jun 03  Submit References Internet Draft
Jul 03  Submit Filtering/Aggregation Methods Internet Draft
Aug 03  Submit Methods of Controlling Policy Internet Draft
Sep 03  Submit Effects of BGP Signaling Techniques Internet Draft
Oct 03  Submit Operational Aspects of Routing Security Draft
Internet-Drafts:
  • - draft-ietf-grow-bgp-redistribution-00.txt
  • - draft-grow-bounded-longest-match-00.txt
  • No Request For Comments

    Current Meeting Report

    GROW WG - IETF58 Mpls, 13 November 2003 - rev 4.
    ===========
    
    Administrivia:
    
    Dave moderates, Vijay not present.
    
    Agenda Bashing - none.
    
    ----
    Generalized TTL Security Mechanism - 
    draft-gill-gtsh-04.txt
    
    Dave reviewed the motivations for generalizing what was initially 
    intended as a security mechanism to protect BGP speakers - now it can be 
    used for BFD, MSDP, etc.  Language has been generalized to be IPv6 
    compliant, sanitized to meet marketeer's concerns about the word "hack", 
    etc.
    
    Dave called attention to the Security Considerations section, 
    especially the discussion of why TTL/hop limit spoofing is hard, and the 
    discussion of tunnelling, MPLS, and the like.  He solicited feedback 
    especially on these areas.
    
    No real discussion here, so comment on the list was encouraged.
    
    ----
    Danny McPherson: Med Considerations: 
    draft-mcpherson-grow-bgp-med-considerations-00.txt
    
    Danny isn't here.
    
    ----
    
    Dave Plonka:  Embedding Globally Routable Internet Addresses 
    Considered Harmful
    
    Dave summarized the draft, which he wants to move towards a BCP, as well as 
    the history at U. Wisc wherein a router vendor shipped thousands of boxes 
    with the IP of a U. Wisc ntp server.  The routers in question had to be on 
    the Internet to work right (couldn't run networks without an ntp server at 
    that globally routable address), couldn't use servers with different 
    addresses, and effectively blackmailed U.Wisc into providing a high 
    volume service, which, if isolated form the campus net, meant that an 
    entire class B couldn't be announced.  Pursuing this situation, Dave 
    discovered other cases where vendors have put globally unique IP 
    addresses in fixed configurations (e.g. firmware), and where 
    documentation examples use real (nonRFC1918) addresses that are then 
    configured inito lots of machines.
    
    This draft recommends that product designers not assume their product will be 
    used on The Internet rather than in private networks, that they use DNS 
    names rather than IP addresses, and that they use RFC1918 addresses for 
    defaults and for their documentation examples.  It recommends that 
    operators and service providers advertise suitable local services via DHCP 42 
    and that they stop listing IP addresses as identifiers in service 
    directories and indexes.
    
    In discussion it was observed that although it might seem obvious that use of 
    globally routable addresses in this way violates netiquette and the rules of 
    engagement for public services, and although the IETF has no actual power to 
    prevent poor implementations (didn't catch who), it isn't obvious to 
    everyone even within the IETF (Dave Meyer), and it is very valuable to be 
    able to tell vendors that they are violating RFCxxx (Perry Metzger).  
    There was a suggestion (who?) that IANA reserve more objects for private 
    use, a la RFC1918.  IPv6 private prefixes were brought up (Tom Petch) and 
    the common use of public IP addresses in educational examples  (Tom 
    Petch).
    
    Should GROW adopt this draft?  Resounding "yes" from the assembled group.
    
    ---------
    
    DMM: BGP communities for data collection.
    
    Dave summarized the draft and its motivation.  Route-views et. al. have 
    tons of archived data, full of a mismash of community values from 
    different providers.  A lot of information is encoded about the origin and 
    type of route, but that information is effectively unavailable because of 
    the lack of standardization.  Dave's draft defines BGP routes in terms of 
    whether they are advertised from "peers", "customers", "providers", etc., 
    and provides a scheme for coding their geographic origin.  If service 
    providers were to use this scheme the data at Route-views et. al. would be 
    much more meaningful.
    
    There were suggestions from the assembly (Randy Bush, Tony Tauber, Vince 
    Fuller, others) that Dave modify the language used for his taxonomy of 
    "peers", "customers", "providers", etc. to reflect the service provided or 
    received (transit or not, etc.) rather than the economic arrangement 
    between BGP neighbors.
    
    There was discussion (Sean McCreary, others) of whether one's own ASN 
    should be encoded in the community (as proposed) or whether a 
    well-known ASN sould be used instead.  4-octet ASNs were brought up (Tom 
    Petch) and a suggestion was made (Geoff Huston) about how to flip some bits 
    in the proposed encoding for extended communities and accomodate bigger 
    ASNs today.
    
    It is expected that these issues can be discussed further on the list.
    
    Should GROW adopt this draft?  Resounding "yes" from the assembled group.
    
    -------
    
    Dave Meyer: Routing Protocol Overload Draft.
    
    Dave Meyer reviewed the presentation from the Routing Group meeting, where it 
    proved to be a contentious issue.  There has not been much discussion on the 
    list.  This draft presents two models of BGP, each of which tends to be 
    tied to a different set of concerns about application fit, risk, and 
    interference.
    
       1. General Purpose Transport Infractructure Model
          carry lots of applications
             - already happened with multiprotocol BGP
          focuses on application fit questions
    
       2. Special Purpose Transport Model
          BGP was developed specifically for IPv4 IDR
          focuses on issues about interference and risk
    
    Dave said this is an early version of the draft and that he would very much 
    appreciate readers and on-list discussion.  He reiterated that this 
    document just attempts to frame the issue rather than taking a stand on one 
    model over the other.
    
    John Scudder plugged IDR meeting drafts on 
    Inform/Soft-Notify, Update-v2, and on multisession BGP, all of which 
    address application separation issues very relevant to the separation and 
    fate-sharing concerns discussed in this draft.
    
    Should this draft be taken up by GROW?  A fast and furious discussion 
    followed.  It was too rapid for this scribe to capture it all.  At issue 
    were at least the following:
    
       To what extent should software engineering issues be addressed in this 
    draft?  In IETF?
    
       Are these so-called software engineering issues really system 
    architecture issues?
    
       Does this draft actually address operational issues? (I believe that 
    Randy Bush, with AD Hat on, said an emphatic "yes, because poor system 
    architecture causes operational outages.")
    
       Is the business of IETF just protocol specification or the 
    architecture and design of the system that is The Internet?
    
       Whatever your answer to the above, is that a Good Thing or a Bad 
    Thing?
    
       If the IETF should be concerned with software architecture for the 
    Internet but has abdicated its responsibility, should that be 
    addressed in this group (bottom up), at ISOC (top down), or somewhere in 
    between?
    
       What is the role of the market, and what is the role of a central 
    planning/design body for the future of the Internet?
    
    Participants in the discussion included at least the following: Yakov 
    Rekhter, Sean McCreary, Tony Li, Tom Petch, Vince Fuller, Randy Bush, 
    Pekka Savola, Lixia Zhang, Ross Callon, Bill Fenner, Dino Farinacci, and 
    Geoff Huston.
    
    Somewhere in the course of the discussion Randy Bush resigned as Ops AD, 
    effective tomorrow (end of this IETF session).  The discussion was 
    sufficiently fast and furious that I was not able to record Randy's 
    explanation.
    
    The GROW meeting ended with Dave Meyer's observation that although it had 
    initially seemed that there was support for GROW adopting this draft, the 
    issues actually discussed in response to the draft are clearly beyond the 
    scope of the Global Routing Operations 

    Slides

    None received.