IETF-69 Routing Area Open Meeting ================================= http://rtg.ietf.org ADs: Ross Callon, Dave Ward Scribe: Deborah Brungard Administriva and Area Status ---------------------------- Dave Ward opened. Reviewed the "Note Well" statement and agenda. Routing Area Working Group Reports ---------------------------------- BFD (Dave W.) - did not meet. CCAMP (Adrian) - we're halfway thru meeting, one session was today, we will have another session tomorrow. Areas of overlap worth flaging: advertising TE interarea info (discovery) interAS for OSPF and ISIS. Will be polling ISIS and OSPF groups for feedback, and we are progressing the ASON routing work. Dave W. - some interesting aspects of TE being considered, and also on ASON routing and for the requirements of arbitrary number of hierarchical levels. Had some issues in the past, need to look at these with a wider group. Need to get people together from ISIS and OSPF, make sure to discuss this with Acee and Chris. FORCES (Dave W) - did meet with an extremely abbreviated meeting, will be doing issues on list. IDR (Dave W) - couple of drafts on reducing BGP thrash, if interested should go. ISIS (Dave W) - 3 presentations, new generic application, carrying non IGP information, similar to splitting routing and nonrouting info, should participate. We are working to move multiple informational isis documents to proposed standard to relieve dependencies other documents have on them, will be discussing this. L1VPN (Dave W) - did not meet. MANET (Ian) - two docs going to last call, MIBs, looking for comments, two others almost ready, should be finishing several charter items. MPLS (Loa) - couple of new RFCs, couple in RFC-ed queue, Liaison from ITU-T on T-MPLS, undertaking a security effort with ccamp, going well, looking at upstream label allocation. OSPF (Acee) - New cochair, Abhay Roy. Moving towards completion of couple documents, 3 went for standard since last meeting. Will be updating charter. Dave W.: Asked will be updating to work on new items being introduced in ISIS? Acee: We will have discussions on working better together. Dave W: Yes we need to work better together, PCE also has related items. PCE (JP) - interAS almost done, on using IGP we have several issues to sort out, soon ready to do a last call. PCEP has 9 implementations, working on monitoring, making good progress on MIBs, policy framework almost done. PIM (Mike) - new Cochair - Stig Venaas. Recharter complete. Finishing existing drafts, including pim refresh reduction. RPSEC (Tony) - almost putting to bed BGP security requirements, looking at milestones and charter, if people have analysis need to get done bring them in. Talked with a few people on sidr's block on rpsec requirements docs, almost done. RTGWG (John Scudder) - one document in editor's queue, meeting this afternoon, graceful restart, several other drafts. SIDR (Sandy) - several drafts expect progress, meet this afternoon. VRRP (Radia) - hope to have document done and recharter. TMPLS UPdate - Stewart --------------------- Presented slides. TMPLS was liaisoned after it was consented (similar to after in RFC editor’s queue). 4 documents involved. TMPLS is essentially an Ethernet pseudowire running over a packet switched network over Ethernet. G.8110.1 derivative of Y.1711. Currently for a static configured managed service, ITU does have plans to develop a control plane. Complete soup to nuts rewrite in ITU language. ITU experts claim MPLS and TMPLS will always be configured as separate networks. Goal to support on transport plane and use same ethertype as MPLS. Yesterday in pwe3, the presentation included interworking discussion even though before it was claimed no interworking. We've been discussing ongoing our concern with ITU on TMPLS as it does have a potential catastrophic impact on MPLS. Key issue is using the same codepoint for two different things. We think could be massive interoperability issues. And concerned their work plan also includes incorporating new pseudowire types. Routing over Low Power and Lossy Networks - JP Vasseur and David Culler ----------------------------------------------------------------------- Presented slides. RL2N (Low power Lossy Networks) are networks comprising a large number of highly constrained devices interconnected by wireless links of unpredictable quality. They are important because there are many applications already: industrial, healthcare, "smarthome". What makes L2Ns special are that they are an order of magnitude larger, links are highly unstable, and nodes die much more often, unique requirements vs. the current internet. Routing in L2Ns is a must for energy saving and to route around obstacles (including poor quality links). Constraint routing is a must. Why can't use an existing routing protocol? None satisfy the minimum set of requirements. Need to carefully evaluate if could adapt, may need a new protocol. The L2Ns routing requirements are unique as totally different dynamics in the network. What about MANEMO (Mobile Ad-Hoc NEMO)? Different but some commonalities. Suggest do not design solutions for all L2Ns. Research has focused on near optimal solutions to the specific problems. IP is maximizing interoperability. The number of proprietary solutions is exploding. If we don't do anything will have IP-proxy gateways with lack of end to end consistency in terms of routing, QoS, management, security. IETF Standardization status: 6LoWPAN will work on L2/L3 protocol agnostic requirements and potentially give to RL2N. A new mailing list for discussing the routing isses: RL2N (Routing for Low Power and Lossy Networks): https://www1.ietf.org/mailman/listinfo/rsn Currently doing multiple RL2N drafts: requirements, survey on existing protocols applicability, metrics. The question is does the IETF community agree that we should be having a WG focusing on this? Dave Culler - said he thought it was a good summary of the requirements. Dave Ward - commented we haven't had a BOF on this, we could do for Vancouver if there is interest. Jeff Mulligan - at the 6LoWPAN working group, we decided layer 3 routing shouldn't be part of our area, we will work on reqs and then look to the routing area group. In ANSI, have chosen to use 6LoWPAN as transport layer, many disparate networks to tie together. We don't have anything to support. Hopes IETF does this vs. ANSI. Chris Hopps - maybe should do in routing area wg? John - no, don't think so. Dave W - first need to see if we feel should work on it. Emmanuel - thinks will be of interest to do this, doesn't understand why say these requirements are unique, not so clear. See more overlap. Except for the scalability. JP - have time? can we discuss more specifically the requirements? Dave culler - the one draft does go thru this analysis. The scaling is a key issue for algorithms. A different meaning for what is a connection, link. We need discussion to understand the current protocols. Emmanuel - agree we should look at scalability. Kevin - I can grasp those requirements, but I'm wondering how lossy is different. How do you partition this vs. what we are doing in routing. JP - not just referring to links and nodes, referring to nodes die much more often than the Internet. This is what I was calling lossy. Dave - I see the difference is really on the assumptions we have had on what is the link and fundamental routing assumptions. Kevin - I just don't see yet what is so different from what has been done. Dave Culler - depends on how much visibility need to have in the presence of a lot of noise. Need to recognize many fundamental differences. Acee - I have no fears of this infringing on the ospf wg. Looking at the drafts, I see a lot of different conflicting items. Have you considered taking one of these industrial protocols and starting with it? JP - with the requirements draft we are hoping to partition, and hopefully find a solution for a common sub set. Dimitri - you said already these protocols are running - in the internet? JP - they started with proprietary protocols in the cloud, then using gateways with IP proxy to the internet. But now we are seeing the need to go one hop more and becoming more complicated. Dimitri - what is the timeframe - can we do something in a reasonable time? JP - the longer we wait the more difficult to migrate. Dimitri - do they have the same type of traffic locally and over the wider cloud? JP - see more inter-communication - point to point. Dimitri - need an address allocation, more than just routing, will you address those? Dave Culler - we agree - many more issues need to consider. As scale, multiple points of ingress/egress. It is changing. Most important is to start. Ross - need to continue to next topic. If interested, get involved before the BOF. Dimitri - is there a mobility component need to consider? Dave Culler - it will grow to that, and other cases won't have it. Ian - like the effort to gather requirements first. The vendors with proprietary solutions probably cater to their specific market. Need to get a common part. Don't think ready for a wg yet, maybe a research group. Dave Culler - for example, remote monitoring - there are so many straight forward cases, not really at a research group level any more. Ian - if have well defined requirements, than yes maybe can start. But as it looks now, it is too wide. JP - we are trying to define. Ian - before the group is formed should try to limit better the space. Dave W - do people here think this is a well scoped problem and have a BOF in Vancouver? (good show of hands) Ian - has there been discussion to have a research group look at this problem? Dave W - Ross, I, and JP are discussing. We are thinking it may seem a working group, though if it is not well defined, then a research group. Dimitri - maybe do both - long term problems for a research group. Ross - yes I've thought also we could identify short term work for a working group and longer term work for a research group. RADIR Update - Thomas Narten ----------------------------- Routing and addressing directorate - had been formed in March 2007. Broad goals with a survey on ongoing efforts, identify gaps, and encourage discussion. link: https://www1.ietf.org/mailman/listinfo/radir Recent focus has been on development of a problem statement. Expect to be posted this week on ram and rrg list. Main "pain" have identified is in load on routing infrastructure. Expect community feedback. Several ongoing work areas: IDR, GROW, RTG, and future in Internet Area. Brian C. - do you think the routing list is serving a function or just random? Tom - a lot is being cross posted and not showing too much focus. Brian C. - agree no one is moderating so gets really out of focus. Leslie - depends on charter, clarity is not necessarily good, should go by what chartered. Tom - agree - we should look at charters for where to have the discussion. Open Mike --------- No comments.