Last Modified: 2004-01-22
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.
(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|
Bert.Global Routing Operations WG (grow) Minutes for IETF 59 Thursday 04 Mar 2004 1300-1500 ================================= CHAIRS: Geoff Huston <firstname.lastname@example.org> David Meyer <email@example.com> Minutes recorded by Giles.Heron <Giles.Heron@tellabs.com> Agenda ======= o Administriva 5 minutes - Mailing list: firstname.lastname@example.org subscribe grow - Scribe? - Blue Sheets o Agenda Bashing 5 minutes o Status of Active Drafts 40 minutes - Med Considerations draft-ietf-grow-bgp-med-considerations-00.txt McPherson 5 minutes - Embedding Globally ... Considered Harmful draft-ietf-grow-embed-addr-00.txt Plonka 5 minutes - BGP Communities for Data Collection draft-ietf-grow-collection-communities-02.txt Meyer 5 minutes - Operational Concerns and Considerations for Routing Protocol Design -- Risk, Interference, and Fit (RIFT) draft-ietf-grow-rift-00.txt Meyer, et al. 25 minutes o Re-charter discussion 30 minutes Meyer/All Minutes ======= Administrivia/Agenda Bashing Draft status: draft-ietf-grow-bgp-med-considerations-00.txt: 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. draft-ietf-grow-embed-addr-00.txt: 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. draft-ietf-grow-collection-communities-02.txt: 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 meeting. draft-ietf-grow-rift-00.txt: 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 consensus. 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 distributed. 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 assertions. 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 morning. 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 assertions. 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 ISIS. 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 argument. 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 issues. 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 month. 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 doc. 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 self-respect. 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 same. 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 OSPF. 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 BGP. 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 milestone. 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 scalability. 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 mind? David Meyer - I think that one was put in to charter to cover RIFT and GROW. Bill Fenner - if we have better way to describe RIFT work then that's fine. 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 RIFT. 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. Charter: (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 here. Sue Hares - RPSL is just an example, but you want to look at infrastructure. 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 system 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