2.4.6 Global Routing Operations (grow)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

David Meyer <dmm@1-4-5.net>
Vijay Gill <vijay@umbc.edu>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.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
  • - draft-ietf-grow-collection-communities-02.txt
  • - draft-ietf-grow-bgp-med-considerations-00.txt
  • - draft-ietf-grow-embed-addr-00.txt
  • - draft-ietf-grow-rift-01.txt
  • No Request For Comments

    Current Meeting Report

    Bert.Global Routing Operations WG (grow) Minutes for IETF 59
    Thursday 04 Mar 2004    1300-1500
    CHAIRS: Geoff Huston <gih@telstra.net>
            David Meyer  <dmm@1-4-5.net>
    Minutes recorded by Giles.Heron 
      o Administriva                         5 minutes
        - Mailing list: majordomo@lists.uoregon.edu
          subscribe grow
        - Scribe?
        - Blue Sheets
      o Agenda Bashing                       5 minutes
      o Status of Active Drafts              40 minutes
        - Med Considerations
          McPherson                          5 minutes
        - Embedding Globally ... Considered Harmful
          Plonka                             5 minutes
        - BGP Communities for Data Collection
          Meyer                              5 minutes
        - Operational Concerns and Considerations for Routing
          Protocol Design -- Risk, Interference, and Fit (RIFT)
          Meyer, et al.                      25 minutes
      o Re-charter discussion                30 minutes
    Administrivia/Agenda Bashing
    Draft status:
       Danny McPherson not present at the meeting. It is planned to issue new 
    version of this draft in March. Comments on the current draft should be 
    sent to the author, via the grow mailing list, promptly. In the absence of 
    further comments the revised document will be in WG last call.
       Dave Plonka is not present at the meeting. No comments have been 
    posted on this draft. The chair proposed moving this document to WG last 
    call, with no objections. The WG last call will be issued following this 
    IETF meeting.
       BGP communities for data collection. It was noted that there are some 
    changes in the -01 revision, and mostly editorial changes in the -02 
    version. The chair proposed moving this document to WG last call, with no 
    objections. The WG last call will be issued following this IETF 
       David Meyer indicated that this approach (RIFT) had been described in the 
    routing area meeting, and was discussed in that venue. It is intended that 
    the document be revised at least through one further iteration prior to WG 
    last call.
    Discussion on RIFT:
       Presentation by Dave Meyer:
       Risk, Interference and Fit (RIFT) used to be called RPO (Routing 
    Protocol Overload). The name seemed to be inhibiting the discussion, so it 
    has been changed to RIFT.
       The discussion was around "fit". The Routing AD, Alex Zinin, had asked 
    for a Design Team  to look at concerns around overloading Internet 
    routing protocols with functions which weren't directly related to 
    routing packets. The Design Team had not made much progress on 
    definitions of "route", "packet" etc.
       The focus of RIFT is on BGP, but it is noted that IGPs are also in 
    scope. The IETF 57 debate was interesting, as it did expose some 
    concerns around the use of BGP as generalized feature transport 
    mechanism. Some see this use as unhelpful, and offer the view that it will 
    destabilize the network. This debate has intensified with additional 
    functionality using BGP (e.g. signaling, auto-discovery, Virtual Private Lan 
    Service (VPLS) etc.)
       RIFT Framework:
         GPT = General Purpose Transport (GPT): model BGP as a generic 
    transport infrastructure. 
         SPT = Special Purpose Transport (SPT): model BGP as special purpose 
    transport for interdomain routing information. 
       Both models assessed for Risk, Interference and Application fit.
       "Application" is defined as combination of BGP data type and 
    associated signaling data. e.g. IPv4 routing system, L3 VPN, etc
       "Risk" is modeling of robustness tradeoffs. It is intended to include 
    consideration of the impact of adding new applications to existing 
    implementations, feature churn etc. Also there is a risk in tradeoff 
    between extending existing protocol and designing a new one.
       It was reported that the Design Team struggled to reach any 
       Multisession BGP fits in with this form of risk assessment 
    reasonably well. There are three drafts on multisession.
       Imagine you have a model which lets you compete risk based on number of 
    Address Family Identifier/Sub-address Family Identifier (AFI/SAFI) pairs.  If 
    risk means anything at all then assume that the risk of the SPT model is 
    bounded by the GPT model - else you can't argue for the SPT model.
       Assume number of AFI/SAFI for SPT model is small (e.g. 2 - 
    unicast/multicast). That means that multisession BGP is trying to find a way 
    to get GPT down to a similar risk profile to the SPT (by grouping the 
    AFI/SAFI). Aim of multisession was to group AFI/SAFI and to then run in 
    multiple processes. For small values of g (the size of the grouping) the 
    risk profile looks like SPT. But there are other components of course - 
    shared memory, process interactions etc.  So risk is trying to model what 
    happens to an implementation when you add AFI/SAFIs to it.
       Interference is trying to model the potential for a new 
    application to adversely affect the protocol level operation of an 
    implementation. For example creating a new state with deadlocks or 
    destabilizing the distributed behavior of BGP. So risk is at 
    implementation level and interference is at protocol level.
       Nobody has said anything about risk or interference. The 
    contentiousness comes with fit.
       Application fit is matching requirements of the data to be 
    distributed to the underlying capabilities of the distribution 
    mechanism. e.g. broadcast, multicast and unicast distr.
       We're at the 3rd attempt to organize this section. First couple of 
    times looked at solutions instead of issues/problems. Version now has 
    assertions and counter-assertions (as that was what was going on in the 
    discussions). This is an unbounded set - everyone has their own ideas as to 
    what fit looks like. From discussions today maybe should try to 
    organize this around issues.
         Dimitri Papadim - the assertions/counter assertions section seems hard 
    to evaluate.
         David Meyer - this doc isn't supposed to conclude rightness vs 
    wrongness on these 3 attributes, but to document the issues as they are. 
    That's why have tried different structures to try and get at this.
         Kurtis Lindqvist - the way the assertions and 
    counter-assertions are written doesn't give explanation of why people are 
    arguing the way they are. if you read doc as such it's hard to make top 
    text fit assertions. Perhaps broaden it a bit so people can 
    understand why people are arguing one way or the other.
         Luca Martini - perhaps this is because one vendor is trying to get at 
    another vendor. Several counter assertions are missing.
         David Meyer - It was easier to get one side of this than the n-1 
    other sides. People on the committee need to help contribute this stuff.
         David Meyer - example of assertion #3. Almost a transcript of what 
    happened in the design team.  The Virtual Private Wire Service (VPWS) 
    application is not a good fit for BGP. Based on the assertion that BGP is 
    poorly suited to VPWS signaling requirements because PWs are 
    inherently P2P. Attributes are per-wire, as compared to routing or 
    auto-discovery where you want info to go everywhere. Suppose you use an RR 
    you have to send union of all the attributes to the RR. So message is n 
    times as large, and RR has to send the n messages to each endpoint.
       Counter assertion is that it is a good fit because the RR only needs to 
    distribute a label range. This gets round the size of the setup message so it 
    isn't really n times larger. Only per wire info will be bigger.
         Kireeti Kompella - especially when k = 0 (per wire info).
         Yakov Rekhter - fails to recognize that VPLS (or any other 
    application) has signaling as one (but not the only) component. This 
    discussion fails to look at system-wide implications.
         Kireeti Kompella - an analysis of the ops impact of two protocols 
    rather than one is also interesting in this context.
         Luca Martini - we have strong indication that most of these L2 
    services won't be running on devices which also run Internet routing, so the 
    two protocols argument doesn't hold.
       Counter-counter assertion. Label ranges are efficient if and only if:
         1) a large enough label range is pre-allocated to accommodate all the 
    systems you might ever add to the VPLS/VPWS (assuming no service 
    interruption is acceptable)
         2) there is no per-wire info other than labels that needs to be 
       Basically the argument goes that as soon as you want to send some 
    per-wire status or info (e.g. MTU size) then you've got problems. Also 
    argued this is a waste of label space and that it fragments the label 
    space. May make debugging harder. Also may be sub-optimal for non 
    fully-meshed topologies.
         Luca Martini - found out at Level3 that MTU was very helpful in 
    detecting mis-matches.
         Kireeti Kompella - in the case of VPLS only have one MTU
         Vach Kompella - assuming with VPWS that all PWs are the same type. 
    We're worried about transitions where one PW might be IP only 
    Ethernet-Frame, another might be something else. Even if Ethernet have two 
    types of encaps. Some router vendors haven't done both kinds. Not that 
    there isn't per-wire info, but that there is and we'll get into it as soon as 
    we start deploying this stuff.
         Vach Kompella - how do we add to asserts/counter asserts.
         David Meyer - send to list.
         Kireeti Kompella - the guys who made this comment don't 
    understand label ranges. Ranges can come in chunks - so can allocate a few 
    labels and then add a range. So it depends on how you want to do label 
    block allocation. In LDP you must have 100 messages for 100 sites. For BGP 
    the best case is 1. We do labels in blocks of 8 or 16. We have 
    deployments of this.
         Yakov Rekhter - people who made certain claims fail to 
    understand what they are analyzing. Making assertions based on random 
         Rahul Aggrawal - one comment on wasted label space. Look at other 
    places where they're allocated (e.g. 2547). in 2547 if you do per 
    interface labels you're wasting them.
         Luca Martini - can we have example of system wide analysis?
         Yakov Rekhter - VPLS has auto-discovery and signaling. This is all 
    signaling. Where is discovery on auto-discovery?
         Kireeti Kompella - in new version of draft explain how path 
    selection is done. RR scaling is really powerful when you go inter- AS. For 
    LDP is M * N mesh across two ASes. With BGP you multihop it just as for 
    2547. My point is that about fit are we screwing up BGP by using it as a 
    transport. Nothing to do with label ranges. In doing VPLS or VPWS we've 
    changed nothing in the way BGP distributes things. Component per NLRI. When 
    you do attribute filtering, add AS paths, check for loops, advertise to 
    peer groups - all of that is the same. NLRI is just an opaque 
    bit-string and is only looked at when you want to install routes or do path 
    selection. When you talk about application fit - application is 
    application of info for VPLS or VPWS. Haven't changed anything in BGP - 
    it's just what we're carrying. Think of BGP as a big switch to carry 
    common stuff and then AFI/SAFI stuff. Most changes are inside the 
    switch. For 2547 main changes were for constrained filtering. Works 
    without change for VPLS. For meta question - what is all this about, BGP 
    distribution mechanisms vs application requirements this analysis is off in 
    the weeds.
         David Meyer - don't disagree on that. Talked to a few people this 
         Yakov Rekhter - if you want to keep this section then you need to say 
    that it makes no claim for validity of assertions or counter 
         David Meyer - I was looking for different approach. This one didn't 
    work either. Right approach is more along lines of what Kireeti was 
    saying. Need to up level a couple of levels, say "these are some issues" and 
    leave it at that. Would it need to be more detailed than that to be 
    useful? My sense is that this has diminishing returns. Will write 
    something much shorter and more abstract. Can do that pretty easily. 
    Kireeti will help.
         Yakov Rekhter - mustn't constrain to BGP. People extend other 
    protocols as well - e.g. ISIS.
         David Meyer - suggestions on how to do this?
         Yakov Rekhter - can have pointers to drafts which extend OSPF and 
         Vach Kompella - If you up level one or two levels the debate might end 
    up not being heated, but also may not yield results. What is the 
    end-goal of this thing? Is it to say "people want to change protocols and we 
    need to see if there's a fit" or are we going to take specific 
    protocols and say why specific changes do/don't fit. If we don't get 
    useful result from going up level then I don't get the point of the whole 
         Kireeti Kompella - one reason it's useful. we've had consensus for 
    both BGP and LDP in L2VPN. The issues around BGP overload mean the people 
    who'd like to use BGP are asking "why is this wrong, why are some 
    vendors not doing this". If you say "here are the issues" they can read 
    this and make their own decision. It's not a question of X or Y, it's a 
    question of what am I getting myself into if I pick X. The series of 
    arguments and counter-arguments makes it hard to see real issues. Real 
    question is "if I add this stuff to BGP then have I fundamentally 
    changed the protocol".
         Vach Kompella - I'm asking for an AS applicability statement. That 
    draft should say "here's the applicability of BGP to this". If your 
    network matches those criteria then it fits. But doesn't address does this 
    break BGP, or LDP, or OSPF. If those are the issues you're concerned about 
    you have to come up with a better way of expressing that than 
    assertions/counter assertions.
         Yakov Rekhter - that's why we need to change this. 
    Assertions/counter assertions goes nowhere. Let's focus on what are the 
         David Meyer - we'll do that. Want to get that done, get it onto the 
    list, have discussion, do WG last call, and get on with it. Can do in a 
         Kurtis Lindqvist - The other question in my mind is what do you plan to 
    do with the doc once published?
         David Meyer - supposed to be informational
         Kurtis Lindqvist - but what is it for. Explains issues and how we got 
    here. I like assertions/counter assertions as lets you know why this doc is 
    being published. If you take that out you lose a lot of the value in the 
         David Meyer - we could compromise on an appendix with the 
    disclaimer Yakov Rekhter mentioned.
         Yakov Rekhter - it's an embarrassment to publish an RFC with claims 
    that may have no validity at all. Need to think about 
         Kurtis Lindqvist - I can agree with Yakov, but we need some way to 
    reflect why we published this at all.
         Kireeti Kompella - people want to know what goes wrong if we use BGP. If 
    we do an accurate job of defining issues without the fight on either side 
    then SPs can make their own choice.
         Yakov Rekhter - e.g. of proposal of using RSVP-TE to signal 
    Point-to-multipoint Traffic Engineered LSPs. This doc can be used as is to 
    show tradeoffs between PIM and RSVP-TE without getting into debates, 
    assertions and counter- assertions. 
         Kurtis Lindqvist - I prefer what Yakov has said to what Kireeti has 
    said. Saying something slightly different.
         Kireeti Kompella - Yakov expresses it better but think he's saying the 
         David Meyer - Kireeti and I will get the new draft up and if poss 
    we'll WG last call and be done with it.
         Rahul Aggrawal - need to note the proposal in MPLS WG to add stuff to 
    Other drafts
       Bounded LPM was rejected.
    Charter update
       IESG looking at this. Operating without for now. Dropped 
    milestones and some items that were inherited from PTOMAINE.
       (1) First goal is to find ways of reducing effect of prefix 
    sub-aggregates to reduce NLRI load.
       (2) MED issue.
       (3) Effects of BGP as edge-to-edge signaling
       (4) Effects of interaction with TE etc. on BGP. How do we isolate 
    global infrastructure from such effect.
    Discussion on (4)
       Yakov Rekhter - shouldn't we look at IGP itself on goal 4 rather than 
       David Meyer - we were thinking of BGP when we wrote this.
       Yakov Rekhter - if IGP doesn't work then BGP doesn't either.
       David Meyer - do we have latitude to discuss this and work on it 
    before next telechat?
       David Kessens - Yes. You can discuss anything, BUT this WG has to work 
    not on IGPs. Interaction OK.
       Yakov Rekhter - are you saying we should only work on BGP.
       David - OK to deal with interaction but not on IGPs.
       Yakov Rekhter - routing systems have IGP and BGP. Just like ignoring 
    auto-discovery in VPLS.
       David Kessens - have to draw the line somewhere. if you have good args to 
    change then we'll listen.
       Yakov Rekhter - isn't it obvious that to make BGP work you need the IGP to 
    work? If you talk about impact of ISIS-TE on routing system then you need to 
    look at ISIS first, not BGP.
       Alex Zinin - common ground. What Yakov's saying is covered here. 
    Interaction between TE extensions and BGP happens _through_ ISIS.
       Yakov Rekhter - so why not state this in charter.
       Alex Zinin - need to send mail to WG chairs.
       Yakov Rekhter - does chair disagree.
       David Meyer - I don't. Just worried about procedure.
       David Kessens - let's not focus on procedure but on getting it right.
       David Meyer - will take it as an action item to work on that 
       David Kessens - will help if can be done this week as am not in next 
    week. Faster the better.
       Yakov Rekhter - question on item 3. How do you plan to determine the 
    effects of using BGP on the scalability of BGP. Is it just a wish-list or do 
    we have a specific plan?
       David Meyer - No, don't have a plan.
       Yakov Rekhter - can someone tell me the plan?
       Bill Fenner - The RIFT stuff is a beginning of this. I think of it more as 
    analysis. Can always deploy the wrong thing and measure the wrong thing. 
    Analysis like RIFT lets you talk about things based on analysis.
       Yakov Rekhter - analysis of what?
       David Meyer - RIFT was supposed to cover item 3.
       Bill Fenner - charter item pre-dates RIFT.
       Yakov Rekhter - you should look at rfc2547bis as it looks at 
       David Meyer - I'm taking away action to rework item 4 by end of week.
       Yakov Rekhter - what about 3? If that's what you mean then you can mark it 
    as done, as rfc2547bis analyzes scalability. What else do you have in 
       David Meyer - I think that one was put in to charter to cover RIFT and 
       Bill Fenner - if we have better way to describe RIFT work then that's 
       David Meyer - I need new text for 3 and 4 and will get that to ADs by end 
    of week.
       Bill Fenner - I think 3 is fine, but apparently it raises hackles.
       Kireeti Kompella - don't think RIFT really covers this.
       Bill Fenner - maybe we need a fifth item to cover RIFT.
       Kireeti Kompella - I like RIFT. But talking about scalability there's 
    other stuff not covered in RIFT - like how much data is in BGP, what's the 
    volatility of this data. Scalability is a different dimension of risk. RIFT 
    just covers static aspects. What happens to BGP when it carries 1M 
    prefixes? What is the difference if 10 prefixes change per second vs 10K?
       David Meyer - there was a discussion as to whether or not RIFT was 
    in-scope for GROW. Writing milestones and goals for an ops group is 
    different to a protocol group. Trying to dis-ambiguate the situation with 
       Yakov Rekhter - why does item 3 only look at BGP as signaling. What 
    about auto-discovery.
       Bill Fenner - confusion over word signaling. In this context it means 
    "that which is not IP reachability".
       Yakov Rekhter - need to tighten language.
       Bill Fenner - OK. Lot of argument when RIFT began as to "what is 
    non-routing information". That's why wording evolved. Has evolved in 
    direction which is not write.
       Alex Zinin - editorial issues better handled on mailing list. Post new 
    charter to list and let people comment.
       David Meyer - what do other ADs think?
       David Kessens - fine, let's just get it done. No nitpicking.
       (5) document operational aspect of routing security and provide 
    recommendations to other groups.
    Discussion on (5):
       Yakov Rekhter - is this routing infrastructure, or routing 
    protocols, or both?
       David Meyer - this is ops group so is both.
       Sue Hares - infrastructure includes RPSL etc., not just protocols.  
    Human beings are part of this. Are you going to look at RPSL and ops?
       David Meyer - I would imagine that ops issues around RPSL would live 
       Sue Hares - RPSL is just an example, but you want to look at 
       Bill Fenner - my concern here is that enumerating every aspect we're 
    interested in risks missing one. Trying to say any operational aspect of 
    security in routing system is in scope.
       Alex Zinin - security of routing protocols belongs in routing area. 
    we're documenting operational aspects of routing security.
       Yakov Rekhter - should be operational aspects of securing the routing 
       David Kessens - send text and stop nitpicking.
    Status update on WG.
       (Geoff Huston has had to leave the meeting due to illness.)
       Bert Wijnen sent message to list. Vijay Gill resigned, and Geoff 
    Huston has come on. Vijay Gill will be tech advisor along with Bill 
    Fenner. David Kessens is our AD. Will be some changes to the charter as 
    we've discussed. 
       David Kessens - first post to list. Longer discussion takes the longer 
    will take. Realistically this won't all get done this week. Needs to be 
    done by Thursday next week. Bit of a complication as David Kessens not 
    there next week and Bert Wijnen traveling.  
       David Meyer - Kireeti and I taking an action item. I will post new 
    charter by 


    None received.