2.4.5 Global Routing Operations (grow)

Last Modified: 2003-05-02

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

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

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


(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:
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
  • - draft-ietf-grow-bgp-redistribution-00.txt
  • - draft-grow-bounded-longest-match-00.txt
  • No Request For Comments

    Current Meeting Report

    Vijay is not present in the room
    Dave present
    Agenda bashing
    Dmitri volunteers to take notes
    Longest match draft
    David Meyer:
    Has anyone read it?
    Any comments?
    Very little response on the mailing list, comment now.
    Geoff Huston:
    This method seems to be a pretty major hack. Cannot see it 
    universally deployed on a flag day, there is not a lot of attraction to 
    this solution.
    Would want something more explicit rather than implicit.
    Best way to control prefix distribution is to have some explicit method.
    Generally it's a nice piece of work but not sure of 
    David Meyer:
    Authors of the draft have been rather silent, what do others think?
    Geoff Huston:
    Pretty much yes
    Dave Meyer:
    Mature draft.
    Any comments?
    Is GROW taking all IDR work items now?
    Dave Meyer:
    Should this document go to informational?
    Scott Bradner:
    Don't take now, lack of opposition does not indicate no support.
    Dave Meyer:
    We need more consensus
    Scott Bradner:
    This is a generic problem, passiveness of a WG.
    Dave Meyer:
    [missed that]
    Yakov Rekhter:
    Do you gave any operational experience with this draft?
    Dave Meyer:
    Yakov Rekhter:
    So don't progress this document now.
    Randy Bush with AD hat on:
    No need of having code for experimental.
    Dave Meyer:
    Should be individual submission then.
    Geoff Huston:
    I would support that.
    Randy Bush
    When author resubmits, it comes to IESG, we would know from wg whether we 
    should take it with care.
    Dave Meyer:
    Ok, enough for now.
    Dave Meyer:
    Next item - BGP TTL.
    Why not to use it generally, first for MSDP.
    Generalize it and make TTL draft.
    What feedback is on TTL usage based verifications?
    Geoff Huston:
    There's element of topology in this, in generalized way setting TTL may not 
    be so good for other non-topology related usages.
    Dave Meyer:
    This is for multi-hop scenarios mainly
    Dave Ward:
    It's simple, it works, is implemented in number of protocols already, 
    almost no effort,
    Non adjacent peers' support should be optional.
    Dave Meyer:
    Any multi-hop scenario should be made optional.
    Scott Bradner:
    Why not just to remove multi-hop support?
    TTL of 255 is particularly dangerous.
    Scott Bradner:
    ADs are always right.
    Dave Meyer:
    No comment on that.
    Dave Meyer:
    What do you want to see happening after IETF?
    Geoff Huston:
    Isn't this recycled from PTOMAINE?
    Dave Meyer:
    Geoff Huston:
    It is trying to explicitly nominate all the walls beyond that the prefix 
    cannot cross
    If you get it wrong it will leak out.
    It is lots of effort to enumerate 90 % of a wall.
    Need to specify some characteristic that stops propagation.
    Route filtering in general could be unsafe.
    Dave Meyer:
    Please hum on support of this draft.
    Don't like.
    WG does not seem to have investment into those 3 drafts. Any comments?
    Bidirectional Forwarding Detection draft.
    Dave Ward presents.
    Dead rat on slide, laughter in a room.
    The problem - fast forwarding plane inactivity detection.
    Fast hellos problem - the faster you hello, the higher the load.
    Need specific protocol implementations.
    Unidirectional links are tricky.
    Some history - PLP, protocol hello mechanism.
    TLV structure is processing expensive.
    Kireeti has abandoned PLP, works on BFD now.
    MARP, for L2 switching space.
    BFD is low overhead, not only for link test, tests next hops in a 
    forwarding plane.
    BFD runs on any data protocol, IPv4, IPv6, L2.
    Unicast point to point.
    Timer parameter change should not reset sessions - learned from ISIS and 
    Separate sessions for data and control links.
    No TLVs.
    Some small changes will make into -01 version.
    Any questions?
    Dave Meyer:
    A few questions:
    How hard it is to guess the discriminator and spoof it?
    Dave Ward:
    No encryption support.
    One can read the packet, decompose and lookup.
    Spoofing is possible
    Dave meyer:
    How is discriminator formed?
    Dave Ward:
    Any numeric value.
    David Meyer:
    Dave Ward:
    Just pick any method.
    When someone sends you something that makes you think it is down, it is 
    worse than TCP spoof.
    Dave Ward:
    TTL hack draft is the solution.
    What for not directly connected?
    Dave Ward:
    Someone jams the link between peers, I don't see the packet and assume you 
    are down.
    This solution can handle transient conditions.
    David Meyer:
    What do you see happening to this draft?
    Dave Ward:
    Individual informational?
    Individual standard?
    Relocate for some other WG?
    David Meyer:
    The reason for asking is security aspects.
    Anyone from IESG has something to say on security?
    Dave Ward:
    Any hello based protocol can be taken down.
    David Meyer:
    Stewart Bryant:
    In echo mode, what happens when you get what you do not expect?
    Dave Ward:
    Could be encrypted?
    Alex Zinin:
    Regarding security, solution should have usable security mechanism.
    [Question: what if echo mode does not work?]
    Dave Ward:
    For nonadjacent peers TTL is unspecified.
    Between directly adjacent peers you send from yourself to yourself.
    Only spoof seems like some sending you more packets than you receive, 
    implementation should detect receiving more packets than sending.
    Detection time is short.
    Alex Zinin:
    If someone is spoofing, should you check TTL value for echo mode?
    Dave Ward:
    If the source and destination are spoofed, should we drop the packet? 
    Seems like yes.
    Randy Bush:
    Security is important.
    If it is on a wire how it is that different?
    Dave Ward:
    I could barely understand your question.
    Randy Bush:
    Lets take offline.
    If it is multi-hop, 10msecs is hardly achievable - multiple gigabit 
    interfaces feeding into one peer.
    Secure multi-hop failure detection does not fit into tens of 
    Dave Ward:
    Stewart Bryant:
    You have 80 msecs of packets in a pipe, you can't do much more.
    [you send a packet from Vienna, and a stream after]
    Yakov Rekhter:
    Worst case scenario is when you have 80 msec RTT and fiber cut in a 
    40msecs is a speed of light, no draft would make that faster.
    David Meyer:
    What do you want further?
    Dave Ward:
    Going to individual submission.
    Randy Bush:
    It makes no difference which WG individual submission goes.
    Pedro Marques:
    Distributed Traffic Filtering
    Explore a mechanism to distribute traffic filtering rules through a 
    DDos resistance.
    Manual configuration.
    Community based traffic attraction to a sink.
    Manual drop.
    Filtering granularity - ideally /32.
    Routing information and filtering information interdependence.
    Need diagnostic capabilities, not always available when just dropping.
    Inter-provider issues make things more complex.
    Bits and encoding are easy, operational model is interesting.
    Example of a customer advertising /24
    Filter advertisement: dst=prefix, src=*, port=80
    Filter accepted because matches routing best path
    Dave Ward:
    Transferring bits is easy because of using BGP?
    Pedro Marques:
    BGP is used for database transfer.
    Dave Ward:
    If we pass this thing via BGP, you can pass routes that are 
    considered not a feasible route. Use a separate attribute to avoid 
    decision process.
    Pedro Marques:
    Reason for BGP is a long administrative relationship between SPs. It is 
    based on BGP. By using BGP we try to fit into that existing 
    operational model.
    The second part is that it is different address family, different 
    database, it has the same route selection rules as far as BGP is 
    concerned but when you install them in LocRIB, those routes have 
    different semantics.
    It is the same as unicast routing, not sure whether you understand.
    David Meyer:
    Work items for GROW WG - I wanted to talk later, but now it is good 
    opportunity. One of work item questions is using BGP as a universal 
    Pedro Marques:
    We have been doing this for 5 years - RFC2547.
    David Meyer:
    It would be good to know what effect happens while continuing to load BGP 
    with separate features?
    Pedro Marques:
    Let's talk on operational issues first.
    Dave Ward:
    We can craft BGP UTP (Universal Transport Protocol).
    Pedro Marques:
    It is implicit. You can only accept filter if your routing accepts the 
    You cannot accept a filter if you have no route, is that correct?
    Pedro Marques:
    If you receive more specific, would it match?
    Pedro Marques:
    Yes, it is best match, if it is a subset of a destination.
    Ron Bonica:
    I think it is a useful mechanism.
    One comment - I would spend a lot of time before deployment thinking about 
    possible security threats.
    Alex Zinin:
    Usefulness discussion may be distracted by BGP UTP.
    Do you have plans to take this work to IDR WG?
    Pedro Marques:
    Draft has -idr- in name.
    If people are interested, I would take it to IDR WG.
    Alex Zinin:
    Two parts of question:
    1. Whether it is a good idea to signal filters?
    2. Doing question 1 over BGP?
    Let's take second question to RTG meeting.
    Pedro Marques:
    [Comments on operational model.]
    Alex Zinin:
    [ no ]
    Randy Bush:
    I am not here to discuss BGP as a car wash protocol.
    Push back deals with routers that don't speak BGP, need to affect flows on 
    that routers.
    Filtering is needed not only on a route level, port, etc.
    Need separate protocol for passing filters.
    David Meyer:
    take this to mailing list.
    Enke Chen:
    1. Route reflector and confederation role in this scheme?
    2. Customer uses BGP in an example, but most real customers don't. How 
    about that case, impacts, etc?
    Pedro Marques:
    1. RR and confederations work fine - the same model as for unicast.
    2. Your NOC can configure this on BGP speaking router that has customer 
    routes. No need to have this mechanism on a direct customer link.
    Enke Chen:
    1. BGP is complex but scales well.
    [someone from mci]
    Typically customers are routed statically.
    [have no default]
    [slammer example]
    Pedro Marques:
    Just to clarify - routes originated from inside don't get validated.
    Pedro Marques:
    Let's take this offline.
    Felix Wu:
    To make this mechanism useful someone must do good analysis of what to 
    Attacks may morph, need to modify flow specifications accordingly.
    Pedro Marques:
    That is a valid point.
    Not many flows are on attack on any single time.
    David Meyer:
    We are coming to the end of agenda.
    Let's take further discussions to mailing list.


    None received.