IETF 74 GROW Notes Agenda -Administriva 10 minutes 1) bruno decraene 10 minutes draft-decraene-bgp-graceful-shutdown-requirements-01 Presenter: ------------------------ Bruno: Presenting requirements based some providers' input. No graceful shutdown for interdomain BGP, no consensus for operational mechanisms, and requires cooperation with your peer. Goal is no packet loss, handle common topologies, and enable eBGP failover when AS's have multiple common ASBRs. Current draft covers both taking down, and turning up BGP sessions. Comments: ------------------------ Wes George: Need something that states that if an attribute is added it will be silently dropped by non-participating remote peers 2) Pierre Francois 10 minutes draft-francois-bgp-gshut-01 Presenter: ------------------------- Pierre: We try to avoid loss of manual eBGP session shutdown. Operational proceedures rather than protocol changes is the goal. First technique (outbound) talks about modifying local pref to shunt traffic away from the peer-link that you are going to shut down. Inbound case is harder- but you can use a community message to the remote peer to have the remote peer modify the local-pref to the first provider's desired value. Deployment seems simple, and suggests that operators review and provide suggestions. Suggests a 'g-shut' bgp-community to make this mechanism standard accross operators. While this mechanism isn't perfect (loss of packets is possible, rewriting due to other configuration mechanisms) its still reasonable. Ron Bonica: how do you trigger the shutdown, why not withdrawl the prefix Pierre: we want to avoid dropping packets during the transition Yakov Rhector: Why not get a standard community assigned - this seems worth the effort Danny: what about the transitive nature of the communities how do you expect the operators restrict that - rewriting? Pierre: The receiving provider should be responsible for filtering, we don't want this to be transitive. Ron Bonica: What if the shutdown doesn't follow the community advertisement. Pierre: We want to keep this operational, rather than modify the standard. Peter Schoenmaker: polls the room and then will send the document to the list to achieve consensus for adoption as a working group document. 3) Daniel Massey, et al 20 minutes draft-cheng-grow-bgp-xml-00.txt Presenter: ----------------------- Dan Massey: Route monitoring data via XML format. routviews.org example - how do we feed real-time data? Starts as binary then turn into ascii? both? Propose a schema to handle attributes and changes to the data in XML - proposes and describes the schema where consumers of the infromation can select which data is important to them. Includes a dump of the actual packet data on the wire. Binary data adds little to overall file size. Compression makes overall data dump same size as existing MRT. Comments: ------------------------ Larry: Binary is faster and smaller size, prefer it. Dan: Thats valid, ascii is better for short term use. Dave meyer: the important thing isn't the size, the important thing is that you can self document the data. Plus you can convert from XML back to MRT. Dan: this is about processing time and binary is good. Lixia: Processing time is a good metric to publicize, but was not included into this version, next version will have that information. Cengis: Processing time is a real issue, need best of both worlds - add this to the MRT data format as an option. Vijay Gill: More data is better - XML is the right format, if you want MRT, convert and throw the XML out. Presenter Requests this become a working group document. Rudiger: what are you targeting? storing the data? would you expect BMP to do this? What you make manditory parts of the schema, is different from the question, you want to use this type of encoding. Presenter: i would expect some agreed upon structure, to handle extentions for other things. Peter Schoenmaker: we're out of time lets discuss this on the list. 4) Paul Francis 30 minutes draft-francis-idr-intra-va-01 Presenter: --------------------------- Paul FRancis: Document was presented in IDR, now being presented here. This compresses FIB not the RIB, can be deployed by a single ISP. Minor changes to routers, many providers are doing tricks today. combines aggrigation and tunnels. The idea is to break address space into aggregation chunks that would not be possible without tunnel interconnection. Tunnel exit handling is sort of like penultimate pop popping. there must be backups for the aggregation points. Yakov: this requires providers to _not_ set 'next hop self' on external peering connections. Paul: Yes that is correct. Yakov: do you assume every pop will have a router that does this. because if a pop doesn't have a router, next hop could be a long way away. This has a cost - aggrigation routers might be expensive hardware based routers. Paul: you can re-use existing routers Rudiger: Large spectrim of tradeoffs that can be done here, but this isn't cheap. Well OK you are not reducing the fib space, you will need to do this with redundancy. Hop count isn't free. I have been following this along time - the idea is interesting, but it really is something that has tradeoffs, and well ok, you also have to take into account the bandwidth that is used within the boxes due to extra hops on encapsulation. Paul: we have evaluated this against an existing ISP - showed 10x reduction in fib cost, with 1% additional path cost. Milage may vary, there is alot of understanding we don't have yet. Shane: one cost is increasing the rib size due these virtual aggregation prefixes. How are you handling exception cases for more specifics. Will need tools to enable all this will be opex cost. Paul: 100-200 additional prefixes is expected in general. you can use additional room in the fib with more specifics, up to your policy. This more specific route case is a management issue, need to write tools. Dimitri: What about the router running out of RIB size. Paul: This is a per-router issue, some can be upgraded, some will need to be swapped out. Yakov: there is a mechanism to do this via operational mechanisms as demonstrated by a recent NANOG presentation. Yakov: If every router is an aggregation point, why bother. Dan: RRG presentation is 5) Varun Khare 20 minutes draft-zhang-evolution-01.txt Global routing scalability is an issue for different types of participants in the DFZ. VA is a map-encap scheme, that can be stretched across ASNs. Mapping information can be shared between AS's to avoid de-capping at every AS boarder. This could allow for RIB reduction amoung participating ISPs via route filtering. We haven't analyzed the value of seperating functions and destributing mappings. yakov, others: many issues with this with subtle issues with traffic engineering paul: is there a draft? Lixia: details remain to be analized Gargi: Should devices have their own functions? is there benefit from having seperate Aggregation Ruters? Paul: Any device could have any functions 6) Danny McPherson 20 minutes ibgp scaling considerations Not a current draft on this yet, objective is just to educate the community. Lots of growth in unique routes - increasing as AS interconnection 'flattens'. Best path changes trickle down to alot of router processing when they change. This amplification occurs on every route/attribute pair, and is not helped by route-reflectors. Many slides on how these updates occur in great detail. Issues include operator configuration, global transitive attributes, complexity of RR/iBGP meshes, and bgp path selection. Not just a vendor/implementation issue. Jim: why is accept-own mentioned? Its only used for VPNs. Danny: it adds to the state, the bgp machinery behind that increases the paths being propigated - not a accept own specific issue, more fundamental. Lively discussion was sent to the list due to time constraints. Was mentioned that the RR's are the point of the iBGP mesh that is under the most strain, rather than the clients. 7) PAPADIMITRIOU Dimitri 20 minutes cache-based forwarding Cache based forwarding is an problem that has been studied with several metrics, replacement algorithms and aquisition a techniques. Both read and write operations utilize these strategies. Caches have hit rate, hit latency, update rate, miss rates, and miss latency. These characteristics indicate the efficey of the cache system. Reach ratio vs cache size, coping with failures, dependancies, security, are all areas of intrest in the draft. Careeti and Dino: this is usefull, security cases are interesting, but don't assume caching is good. Shane: this is usefull work, get practical intrest. 8) Rolf Winter/Iljitsch van Beijnum 20 minutes draft-van-beijnum-idr-iac TE of incomming traffic is problematic. This talk is about some sets of tradeoffs. Proposes a 'cost' metric and suggests a place in the BGP path selection process for it to exist. soliciting feedback from the operational community to see if its usefull. Then may go back and re-try presenting to IDR. mark rodrigus: suggest presenting to NANOG might be a good idea. .