Last Modified: 2005-09-20
| Done | Publish Risk, Interference and Fit (RIFT) document as WG I-D | |
| Done | Publish Embedding Globally ...Considered Harmful as WG I-D | |
| Done | Publish MED Considerations Draft as WG I-D | |
| Done | Publish Collection Communities as WG I-D | |
| Done | Submit Collection Communities to IESG for BCP | |
| Done | Submit Embedding Globally ...Considered Harmful to IESG for Info | |
| Done | Submit MED Considerations to IESG for Info |
| RFC | Status | Title |
|---|---|---|
| RFC4085 | BCP | Embedding Globally Routable Internet Addresses Considered Harmful |
Global Routing Operations WG (grow)Minutes of GROW WG Meeting at IETF64 Monday, November 7 at 0900-1130 Chairs:
David Meyer <dmm (a) 1-4-5.net> Notes:
NOTES1. Administrivia
2. Agenda Bashing
3. Review and status of work itemsActive Draftsdraft-ietf-grow-rfc1519bis-02.txt (Proposed Standard) AD Evaluation has been completed, and review comments have been passed back to WG chairs and document authors. The review comments are to be addressed in another revision of the draft. Action draft-ietf-grow-collection-communities-08.txt (BCP) This is a longstanding work item intended to provide a common means of interpreting the communities that were being passed to route collection points. The document has been in the RFC Editor Queue awaiting the completion of the BGP Extended Communities draft in order to normalize the document's references. Yakov Rekhter has suggested these community values being recorded in an IANA registry as a means of allowing future extension of community values as an IANA registry transaction. The AD advice is that required document edits to effect this are relatively minor and can be made in-situ without re-passing the document back through the entire document review process. draft-ietf-grow-anycast-02.txt (BCP) In Working Group Last Call as a candidate BCP (Last Call ends on 19th November 2005). draft-ietf-grow-mrt-01.txt [presentation by Larry Blunk] Current consideration is related to the timestamp (first field in basic header) which uses a 32 bits (no microseconds). A further revision of the specification has added OSPF support for microseconds. Security Considerations also added. The -02 revision is proposed to include specification of an IANA Registry for Type/Subtype codes, and support for 4-byte AS numbers. The question was asked whether there was support for adding microseconds for RIP support. Regarding the proposed IANA Registry the document author will make suggestions to the Working Group on this. draft-ietf-grow-bgp-med-considerations-04.txt (Informational) Action Proposed work itemsdraft-scudder-bmp-00.txt [presentation by Bill Fenner on behalf of the authors] This draft proposes adding a wrapper around BGP messages to allow these messages to be duplicated and forwarded from a BGP speaker to a monitoring station. There is a considerable volume of BGP monitoring being undertaken, but the predominate current method is by explicit BGP peering with a monitoring station. This would allow a monitor to receive updates as they are forwarded from BGP peers, rather than only collecting updates that are passed on the Adj-RIB-out. Working Group discussion noted that this would allow greater flexibility in terms of monitoring incoming BGP information from peers. The proposed message types to be flagged in the wrapper protocol include incremental BGP updates, peer up/down state transitions, and table dump (Adj-RIB-in if available, Loc-RIB if that's all you have). The proposal deliberately does not define data storage formats. There was a favourable response to the flexibility this offers on monitor report formats. A query was raised if this monitoring function be combined with what actually gets accepted by the router, comparing Adj-RIB-In with Loc-RIB changes. The question was asked as to adopt this as a working group document. Not enough people have read the draft (the people who had read it agree to adoption). Action The question was raised that this has an element of protocol specification, and is this properly managed in an OPS Area Working Group. Action The question was raised about including flags for identifying 2-byte or 4-byte AS BGP sessions, so receivers don't have to work though any potential ambiguity cases. figure this out? It was noted by Bill Fenner that this would be a great addition to state the capabilities you've received at BGP Open even if you aren't monitoring at open time. 4. Update from the NANOG IAB IPv6 multi-homing BOFDave Meyer [presentation] Some constituents in the operator community are evidently not in line with SHIM6 direction and some are feeling disenfranchised by IETF in general. The NANOG BOF was attempt to close this loop. Minutes and Real media video are available on NANOG website. Metagoals around IPv6, around operators at IETF. The BOF had explained the IAB's role. Geoff Huston had presented SHIM6, and then the operator perspectives were sought. Some operators were confused about current state of the spec. It was noted that there was the message that SHIM6 is not necessarily the complete answer in the multi-homing space, but neither was Provider Independent address allocation from the registries. This is one data point, not the only one about what operators think about SHIM6 and about IPv6. Service provider conclusions - SHIM6 doesn't address Traffic Engineering (TE) requirements (although injecting prefixes doesn't, either), and TE must be supported on day one - and SHIM6 may even be in conflict with TE requirements, There was the question regarding unicast RPF and firewalls, and about inbound TE with transit ASes. It was noted that PI for IPv6 gives a much larger swamp in the routing space, and additional complexity is not a good thing for implementers or for operations. Content provider conclusions - don't like state in servers, concerned about roundtrips before first content delivery, what about short-lived conversations? Geoff Huston - short-lived conversations implies SHIM6 is aware of transport sessions, but it's not - SHIM6 is at IP layer. Erik Nordmark - what was concern about state in servers that have TCP time-wait state anyway? SHIM6 state could be in the noise by comparison. Dave Meyer reported that Vijay Gill (at NANOG) expressed concern about complexity and cost constraints with support provisions for low-margin customers. E-mail from John Payne - do not put TE in hands of end users, it's at a site level (at least with overrides). First hit is of critical importance, don't hunt through DNS to find a locator that works. What other multi-homing work is going on? Dave will compile materials for IAB web site next week, and has volunteered to run the session at APRICOT 2006. Jordi Palet - we need white papers to get this resolved. Dave - response in the form of an up-to-date review of what GSE was and bring it back into the IETF, write a document that builds on the multi6 architecture document, and work though the final barriers to IPv6 deployment. Spencer Dawkins - one comment from NANOG was that providers are very concerned about host-based solutions when they have so little control and influence on individual host behaviours. If they override what hosts do, why are we using a host-based solution? Kurtis Lindqvist - look at what's happening in RIRs - there's a lot of pressure on RIRs to allocate PI now. And there's nothing providers can do to prevent customers from sending traffic any direction they choose now. 5. BGP Status ReportGeoff Huston [presentation] IPv4 routing table size. We were seeing a lot of advertisement fragmentation around 2000, but this stabilized in late 2001, but we're now on another growth trend in terms of prefix size. Routing table now growing at 25,000 entries/year. Now announcing a total of 1.4 billion /32 IPv4 addresses. More-specific announcements (ignoring AS path differences) - seeing about 60,000 entries at most observation points. "Root prefix announcements" is growing at a faster rate than the total table. AS numbers growth is steady. We think this is multi-homing at the edge. Average AS path length is actually slightly falling, and the observed AS length radius of the network isn't growing, it's compressing (to about 3.6 ASes)."If you could aggregate IPv4 prefixes", could drop about 60,000 entries that aren't adding any additional reachability information to the routing table. About 10,000 routing entries are obviously trying to do TE, and a larger number is uncertain whether there is local TE. Also seeing "checker boarding" - people who don't advertise all of a prefix. Two thirds of entries in the path are about path differentiation, not about reachability. IPv6 routing table is still about 800 routes. Some address disaggregation coming out of Korea late 2004 / early 2005. Recent growth in advertisements probably attributable to recent workshop activity. Geoff did some numerology with the IPv4 address counts. Currently seeing 85 /8-equivalents in the routing table. Applied a smoothing function, then performed a first order differential. This yields a noisy wave-form, but on average we are growing in the routing table by 5-6 /8s per year. First-order differential of log function is flat right now. RIRs have given out another 40 /8s that we can't see in advertisements. The total size of this unadvertised address pool is still growing, but at a rate that is slowing. A projection exhaustion point of the IANA unallocated pool was predicted to be in 2012, and the first RIR exhausts into local address pool about a year later. But this is a "well-ordered" model, and we have to expect some form of rush in address allocations - which we can't model. Pekka Savola - would expect that the RIRs become more conservative when they are running out of space to allocate. Geoff reported that RIRs are responding to members needs. Its not entirely sure that the allocation policies would change in the time available. http://ipv4.potaroo.net shows allocated versus advertised space graph which has some interesting data for the current year in terms of allocated space and advertised address counts. Cengiz - Based on this, do we have to switch to IPv6 because we are running out of IPv4 addresses? Geoff reported that we are using unallocated addresses now as the basis of address distribution, and following the exhaustion of that pool, players would need to be more creative about finding addresses to meet their needs. A lot of current damping of the potential routing table growth is due to RIR policies relating to address allocation from the unallocated pool. When this pool exhausts, there is a likely switch in the address distribution model to forms of address trading. However, it's unlikely that we can aggregate the distributed addresses in the same way as we do now - one possible outcome is rapid unconstrained growth in the BGP table once again. Ron Bonica - old prefixes that are disappearing? If you reclaimed those prefixes, how much longer? Geoff - reclaim and issue at higher address compression point would give you up to 2026 in terms of total address lifetime, but that assumes an almost perfect model of bringing addresses back into the network. |