Routing Area Open Meeting (rtgarea) IETF 93 (Prague) =============================================================================== Area Directors: Alia Atlas (akatlas@juniper.net) Deborah Brungard (db3546@att.com) Alvaro Retana (aretana@cisco.com) Area Secretaries: Jonathan Hardwick (jonathan.hardwick@metaswitch.com) Jon Hudson (jon.hudson@gmail.com) Wiki: https://trac.tools.ietf.org/area/rtg/trac/wiki/WikiStart Scribe: Jonathan Hardwick (jonathan.hardwick@metaswitch.com) Location: Congress Hall II, Hilton Prague, CZ Time: July 21, 2015, 1520-1720 (3:20pm-5:20pm) ------------------------------------------------------------------------------- 1. Administrivia ---------------- Alvaro opened the meeting at 15:27. Alvaro presented the IETF note well. Alvaro asked participants to use the routing area wiki (link above). ROLL and PIM have been re-chartered. L2TPEXT, LISP and TRILL have been added to the RTGAREA since the last IETF. WG chair training has been happening. Check the wiki for details. ------------------------------------------------------------------------------- 2. Working Group and BoF Reports -------------------------------- BESS (Thomas Morin): WG meeting size stable at ~100. Good meeting and discussion. Problem is there are lots of slot requests for meetings but not much mailing list discussion between meetings. We need to fix this. We have presented a slide of things to do to be sure not to have a slot in the next meeting. Alvaro: Our time here is expensive; we should use this time to resolve issues we cannot resolve on the list. IETF is not 3 sprints per year, it is continuous work. BFD (Jeff Haas): Work smooth with no contentious discussions, so we did not meet. Seamless BFD is through WGLC and is pending a shepherd report. RFC 5884-bis - ditto. BFD YANG DT making excellent progress. New work - integrating BGD with VRRP. New work - BFD protection for VxLAN environments. New work - making BFD authentication implementable. BIER (no-show) CCAMP (Daniele Ceccarelli): 3 new RFCs, concluding work on WSON. Flex-Grid work is progressing. Encoding progressing, signalling layer next. New work coming for OTN networks and WSON with impairments awareness. I2RS (Sue Hares): Having a great week. Working with netconf to finalize requirements for protocol. Models completed. Met with TEAS WG for 21 hour to discuss TE model. We will be further discussing the protocol in netconf this week. IDR (John Scudder): Meeting on Monday and Friday - least desirable scheduling possible. error-handling and as0 drafts are in RFC Ed queue. add-paths sent to IESG, waiting for other add-paths docs to proceed. A large part of agenda is flowspec. ISIS (Chris Hopps): 4 new drafts LSP lifetime attack vector L2 bundle - new L2 TLV Homenet related drafts - p2mp (IS-IS on wireless network) and isis-over-ipv6 L2TPEXT (Deborah for chairs in absentia): Have several documents to finish off. Active mailing list. No meeting this time. After documents are done, they will think of closing. LISP (Luigi Iannone): Discussing re-chartering. New use cases are on the table. We need to focus on a few of those. MANET (Stan Ratiff): OLSRv2 multipath document ready for last call. DLEP going back into last call. MPLS (Loa Andresson): 6 new RFCs since last time. 16 rising to 18 active WG documents. 1 draft returned to the WG for more work. Seamless MPLS architecture. 2 ADs have kicked it back. Comments understood but we clearly have different ways of looking at the document. Loa: A question for the ADs. The reports you have here on the wiki - what kind of level of detail are you looking for? Alia: we will brief WG chairs at the next WG chair chat what kind of report to write. Please send comments Adrian Farrel: can't read the wiki as presented - please zoom in. NVO3 (Matthew Bocci): Agenda focussed on progressing CP and MP work in the working group. We had two Virtual interim meetings on OAM and Control Plane that were very productive. We have a large discussion planned on how to move forward, as well as what to do with the three encapsulation methods that have been accepted. OSPF (Acee Lindem): Two RFCs published. YANG model will be presented. Problem is YANG is so flexible, you can do so much with it, you don't know where to draw the line. We have made progress in design team. We were meeting every week, now every 2 weeks. Segment Routing - hoping to do WGLC soon, but it seems there are still ongoing tweaks, so we will hold off for now. Long range goal of WG - get more adoption of OSPFv3. Number of v3 deployments dwarfed by v2 deployments, but v3 is superior protocol. PALS (Andy Malis): Most discussion will be management / OAM related. No new RFCs or in editor queue. 5 drafts in IESG review. Several drafts will be forwarded to the IESG soon. PCE (Julien Meuric): No new RFCs. A few documents pending chairs review (stateful PCE) Some IDs are ready for WGLC We will discuss early allocation for SR code points - some IANA issues we hope to fix this week face to face. YANG work. Some core PCEP extensions. JP will not be here on Thursday - please talk to him ASAP. PIM (Stig Venaas): Presenting reports via the wiki is better than presenting slides. We have only 90 minute meeting this time but will want 150mins again next time. WG name changed from PIM (the protocol) to PIM (Protocols for IP Multicast) to reflect the WG's newly expanded scope. We are doing PIM YANG model but need input from YANG experts. Do we have simple framework model that is nearly empty, or try to put everything in and have a really big, complex model? ROLL (no-show) RTGWG (Jeff): 10 active WG docs. 1 new RFC. SFC (no-show) SIDR (Sandy Murphy): 10 new draft versions, several hopefully final. One document in IETF last call. Two lengthy reviews long after WGLC. New work: RPKI actions to handle transfer of address blocks New work: possible adverse actions by certificate authority. Will discuss implementation experience of RPKI We have seen requests for deeper review experience for some adjacent technologies around for example timing issues. SPRING (John Scudder): 2 new WG drafts Problem statement ready for IESG WGLC for architecture document will start. This is keystone document, please comment - your last chance. Some milestones slipped - we are updating them. We have some flow control issues due to holiday schedules. We hope to catch up with our milestones soon. TEAS (Vishnu): 3 new RFCs published To discuss: TE topology, how does it correlate with I2RS topologies? We discussed to coordinate with I2RS. RSVP/TE models being developed, must align with openconfig team ACTN documents will be discussed. TRILL (Sue Hares): Focussed on OAM, active-active, directory support. Looking at TRILL over IP. Looking at multi-level and multi-protocol work. DETNET BoF (Lou Berger): Lots of interest. 175 attendees. Deterministic network - lossless jitter-free (due to congestion) traffic delivery. Presented 6 different use cases. Industrial automation, audio, building automation. Good response from room. Half of attendees thought interesting problem to solve. 20-30 people volunteered to work on it - which is enough to sustain a working group. ------------------------------------------------------------------------------- Routing YANG Architecture Design Team ------------------------------------- Lou Berger Made good progress on 3 priorities. Intend to work on this in RTGWG. All work published on github. Let Lou know if you can't find it. Please comment - comments should go to the RTGWG. ------------------------------------------------------------------------------- ANRP Presentation ----------------- Distributed Route Aggregation on the Global Network (http://www.cs.princeton.edu/~jrex/papers/dragon14.pdf) Joao Luis Sobrinho The Internet does not scale well - some routers cannot process +512k routes. Most prefixes are advertised globally - more specific prefixes are preferred. Analogy. Every crossroads in every city has signpost for every neighbourhood in the world. Leads to poor performance of BGP. The situation may be worse with IPv6 - more prefixes are possible - we need a plan for IP addressing to mitigate this. BGPSEC adds further per-prefix drag. DRAGON allows to save 50-80% of routing state. No changes to BGP protocol or forwarding plane. Requires upgrade on routing software to take account of new DRAGON routing decisions. Outline: Aim for system where more specific prefixes are distributed only in the vicinity of the AS that originated them. Hierarchical arrangement of ASes - provider and customer - customers originate more specific prefixes. RIRs tend to distribute information in a geographic region. Dragon: filtering strategy Gao-Rexford routing policies: prefer customer > peer > provider export all routes from customer; export all routes to customers Use route attributes to tag routes as learned from customer, peer or provider. Say 2 prefixes p, q with q subset of p. Want to minimise distribution of q. Other than origin of p, in the presence of p, filter q if attribute of p route same or preferred to attribute of q route. We have proved routing is correct, consistent with the situation without filtering, and even optimal in the sense that the number of ASes that forgo the route to q is maximal. This can be deployed incrementally in the Internet. Dragon: aggregation strategy Dragon has some detailed rules for when it is alllowed to automatically aggregate more-specific prefixes into an aggregate prefix. Dragon: performance results Tested using real-world routing data. Basic dragon uses filtering only; saves 47% of prefixes. Full dragon uses filtering and aggregation: saves 69% of prefixes. Conclusion: Dragon is a solid framework for reasoning about route aggregation. Comments from the audience -------------------------- Doug Montgomerie: in aggregation example, prefixes are provider independent. Can you comment on security aspects of having authority to send an aggregation prefix? Joao: We need to describe those conditions in more detail. Doug: Do you need to have a full covering set? Joao: Yes, you do. Sandy Murphy: What prevents aggregation of a non-full-covering set in your model? It is not secure to assume that all ASes are operating correctly. Joao: Yes, this would crete black holes and is not managed. John Scudder: Aggregation: if you have a well-connected sub-graph of customer ASes, do you only see the aggregates outside the sub-graph? Joao: mostly yes. John: What happens if the well-connected sub-graph becomes less well connected? Joao: The system self-organises and does not break; performance will be worse. This happens in real time. Randy Bush: You are doing 2 things. 1) dropping covered prefixes, operationally good, but can you convince vendors to implement something that will lower the rate at which they can suck my blood for FIB space? 2) Do my customers give me the authority to aggregate their prefixes? They can be traffic engineering. They are business customers. 3) First half of dragon has no impact in RPKI, but aggregation does. It is more complex than you think, please send me email if you want details. Overall this is good stuff, love it if operators could beat on vendors to do at least the first half. Joao: Sometimes it seems the interest of the customers and providers is in conflict. Customer may be multi-homed and send more-specific to one provider; how does other provider react when it receives more specific from its provider/peer? Dragon You could have a "don't use dragon" policy per prefix. Sue Hares: You have 3 different aggregation strategies. What happens if these pieces of the network you are aggregating transition rapidly? What happens during change, for the different algorithms? Joao: We have another paper on that, submitted for publication. Dragon will recover from transitions. Sue: Do your algorithms have different fail points, slowness properties etc.? Doug Mongomerie: Do you address issues of how it affects routing dynamics? Say 1 customer flaps wildly? Is upstream routing stable? Joao: Absolutely, we address this. Flapping is allowed for and absorbed. Aggregation must stop if flapping occurs. Jeff Haas: Is your definition of correctness complete? If the more specifics are suppressed then forwarding throughout the network must not be changed. If you tie the fate of more-specific to less-specifics, then because of the lack of speed of BGP propagation, you may end up with meta-stable route oscillations - look up "proxy aggregation" in the literature. There is wisdom not to make the fate of a route dependent on another route for this reason. Ruediger Volk: What conditions have to be applied to the routing policies in the cooperating ASes? Weird routing policies in place may interact badly with dragon. Joao: Can you be more specific? Ruediger: Can we assume that all players are using isotone routing policies? Joao: No, absolutely not. Rudiger: Some policies e.g. shortest AS path first are not isotone. Customers may actually be paying for that behaviour. ------------------------------------------------------------------------------- CBOR as a generic TLV format ---------------------------- Joe Hildebrand There are 2 types of 'type' in TLVs that the IETF specifies. - Storage type (such as "IPv4 address"). - Semantic type (such as "source IPv4 address"). These are often mixed. Result: end up with per-TLV parser code; could be streamlined. In application land we use JSON. Mostly as browsers have JSON parser built in. JSON might not fit: edge cases, complex parser, easier to mess up security and can be slow. Binary data must be base64 encoded. Larger wire size. CBOR is better fit (RFC 7049): binary encoding of JSON++ small wire size, parser code size (880 bytes ARM code) Fixes known issues of JSON Defined diagnostic rendering (implement in Wireshark) Could we use CBOR for TLVs? Small amount of parser code to test well and test once. May improve TTM, interoperability, diagnostic support. This presentation was just to socialize an idea from application land, to see if there is interest. Comments from the audience -------------------------- Jeff Haas: CBOR appears to miss an overall length field up-front. Joe: You could wrap the CBOR. Jeff: Sounds like a TLV to say you have CBOR inside. Jeff: This is a nice feature to stop reinventing parsers. Positioned as JSON++. JSON was nice for dropping inside browsers; But you can't do text-based surgery on this, you need to parse the whole thing. Joe: Commonly applications just json.parse() the whole doc anyway. Hannnes Gredler: How does this compare to message-pack? Joe: We talked to those guys - they were uninterested in standardizing CBOR; Carsten Borman did some design work and ended up with something more intentionally designed than message-pack. They fit into the same space. Hannes: are there implementations? Joe: cbor.io has implementations. Jie Dong: could be useful for generic networking architecture for introduction of new protocols that are defined using data modelling languages. Joe: doc called CVDL that makes it easy to describe protocols that will be encoded in CBOR. COSE WG defines encryption - don't need to reinvent encryption for your protocol. Toerless Eckert: Is there a mailing list to continue this discussion on? Joe: We are going to set up cbor@ietf.org. (This is in fact alive.) Toerless: I always think that going down to binary levels of encoding is unnecessary optimization; get benefits of readability and reusable code by using common encoding languages. ------------------------------------------------------------------------------- Open Discussion / Any other business ------------------------------------ There was no other business to discuss. Alia closed the meeting at 17:17.