Last Modified: 2003-09-10
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
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 |
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 |