Routing and Addressing (ROAP) BOF THURSDAY, March 22, 2007 09:00 - 11:30 Congress II (Note: This is currently listed in the agenda as the intarea meeting.) ADs: Jari Arkko (jari.arkko at piuha.net) Mark Townsley (townsley at cisco.com) Chairs: Thomas Narten (narten at us.ibm.com) Peter Schoenmaker (pds at ntt.net) Mailing list: https://www1.ietf.org/mailman/listinfo/ram DESCRIPTION This is an architectural discussion about future IETF work on identifier-locator split and multi-level locator designs that may help issues with routing scalability and be useful in other ways, in the long term. It is BOF run within the Internet Area open meeting. The intent of the BOF is not to immediately create a working group, but to talk about whether a new identifier-locator split or multi-level locator based mechanism would help routing scalability and what the desired properties and boundaries of a new design might be. The discussion is expected to be architectural, i.e., focus on high level design decisions and not specific protocol bits. Assuming that the meeting and ongoing list discussion converges on the desirability of a new design and the properties thereof, it is expected that a working group will be created around the IETF-69 timeframe. Specific protocol proposals are out of scope for BOF discussion. However, new designs are very welcome in this space and it is important to learn how the designs work with real-life devices and applications. It is expected that experimental specifications for early proposals will be appear in parallel with ongoing architectural work. The routing scalability problem has been described in Section 7 of [REPORT]. The causes and nature of the problem are fairly well understood and agreed. However, there is less agreement on whether the problem is urgent and how the growth rates in the routing table compare to our ability to improve hardware. There is cause for optimism with regards to the short to medium term ability to build more scalable router architectures [SCUDDER]. Specific discussion of the urgency of the problem (or lack thereof) is out of scope for the BOF, however. It is nevertheless clear that the current routing system scales according to the number of prefixes that are also used as end system identifiers in addresses. Can the IETF develop a model where this would not be needed? This BOF focuses on the use of an identifier-locator split or multi-level locator design to, among other things, improve the scalability of the routing system. Note that such improvements are useful even if one considers the current scalability problem to be sufficiently addressed by hardware improvements. For instance, a design that allows the system to scale better allows us to increase the throughput on a given amount of hardware resources, allow easy renumbering or multihoming for more customers than those currently capable of getting it, and so on. The BOF also takes it as given that there are existing IETF and IRTF designs in this space, such as HIP and SHIM6. It makes little sense to repeat these efforts for exactly the same type of functionality. As a result, the BOF focuses discussing what new functionality or deployment approaches may be needed that justifies building new mechanisms or extending the existing ones. Finally, the BOF should take it as given that new designs need to work for both IPv4 and IPv6 and that they need to be able to work with existing unmodified hosts, do not change the core Internet routing infrastructure, do not expect changes from applications, have support for dealing with referrals, and be incrementally deployable. Note that the above scope excludes many interesting topics and research from this discussion. Scoping is necessary, however, to achieve something that can reasonably efficiently be specified and deployed in the current Internet. There are other forums (such as [RRG]) that look further into the future, including considering so called "clean slate" designs. AGENDA ----- 1. Administrative (chairs, 5 min) - notes takers - agenda bash - blue sheets [TME : I missed this as I was trying to find and plug into power.] ----- 2. Scoping the BOF (ADs, 10 min) Jari : Background - we would like to know if there is IP layer work that should take place. More specifically, we would like to focus on ID-locater separation. We would like to - listen to the community - gain from the last 6 months of list activity We will have a presentation from the routing community, what their requirements are. We will also have a architectural design presentation. We can't go into bits and bytes here, looking for a higher level discussion. Do we need a - network based solution ? - host based solutions ? - both ? Do NATs figure in ? If we can answer just a few of these questions, we have achieved something. Whatever we do needs to be deployable. It makes sense to allow unchanged applications to continue working. Backwards compatibility with existing networks is similarly important. This is a big change, but even with big things, you have to get them deployed. Next steps include - continue discussion on the RAM list - come to agreement on the scope of work and directions to be headed. We would like to encourage engineering ideas to be submitted as drafts - and also we have the routing research group. The difference between these is that these are works in progress - do we have engineering level work ahead of us, or is more research needed ? - Why we are here? - What's in scope? - What's out of scope? ----- 3. Routing issues where id-loc split might play a role (David Ward and John Scudder, 20 min) David Ward : I am not here to talk to you about requirements - they are not clear, I am here to talk to you about goals. Although we have seen a lot of interest recently, the routing community has been discussing this for 15 to 20 years. I am going to try and bring in a few new ideas. What's critical is that we need to clearly define the problem. We also need to discuss whether or not we need to enable new tools or new protocols, or remain with the tools we have today. Two main goals : We want the rib/fib growth to flatten or even go negative if possible. we want the dynamics of the routing system to slow down. Baseline preferences from Vince, David and Dino - many thanks to them for their work. People who think about routing prefer a mechanism to associate an ID with Locator addresses. ID's do not necessarily have to be routable. We prefer a solution that can be incrementally deployable. We want little or no modification of Internet infrastructure - so we have to live with data bases that exist today. That is primarily BGP and DNS. We are trying to reduce the router state load. Who is going to pay and who is going to benefit from this change ? There is a difference between site-based and provider-based goals. Sites need to be multi-homed. Sites needs to be connected to more than one provider. Sites needs to be able to change providers. A question is, does session survivability during the changeover ? Sites must be able to advertise traffic engineering and service desires - multi-provider local balances. Provider goals : Network nodes need to scale in multiple ways. Need to conserve both power [requirements] and cost of network nodes. In addition, the providers need to be able to maximize their resources to deliver cost effective connectivity. This may not be possible with modern architecture. Providers need to be able to prevent bad actors from hijacking their resources. This may be the end of the beginning of the 1980 Internet architecture. Do we want to enable a new tools set to build network functionality ? Issues include : Do we want to solve - network partitioning - mobile ad hoc networking - resource mapping - service locators - ability to have a single end-point in multiple service domains This is a tale of two databases. Routing Database - RIB [second one lost] What we see today is that there is no separation of the provider from the site. All endpoint state is reflected back into the global internet. We all bear the cost of new endpoint state. Second there is mapping databases in the DNS. There is currently no notion of mapping a node to its location in the network. So, it is interesting that the is a lack of relationship between routing and mapping. Both databases assume static endpoints with minimal security. The routing community believes that we need to add a new mapping database to the network today. In addition, a few other things are critical. Margaret Wasserman : I thought that you said before that the routing community does not want a new mapping function ? David : If it all possible they want to reuse the mapping functions we have today. If you look at the network, tier 1 networks have acquired a number of non-contiguous prefixes, so that they are effectively random. Also interesting, if a site must announce more specific routes, they may not need to do anything but traffic engineering. So, in summary - We have re-chartered the RRG - Questions include - finding the scaling of any solutions ? - what's the time frame necessary to solve this ? There is a lack of clarity right now for the exact requirements, the exact design and thus the exact solution. Bishop : In your baseline preference slides, the list of issues are solved by a number of mobility protocols. Ip mobility doesn't exist on the Internet today. David : This is not taking your laptop somewhere else. Bishop : I didn't see redundancy there. David : For sure. Shane : You have site based and provider based goals. Speaking as a provider, I am much more interested in solving the site multi-homing problem than the site mobility problem. My fear is that by overloading too many goals, we don't wind up solving any problem. Second, the real problem is solving for multihoming - I think that the mapping database will really be the core problem. This is a pretty new area. How do we solve and scale the mapping function to provide multi- homing is the core problem Chair : Clarifying questions only Vince : There are a whole bunch of solutions that dance around the mapping problem - the other side is that we need an Internet architecture that can satisfy the drivers of this growth, such as end site multi-homing. This can be sold as adding functionality that is needed. Dimitri : What is the difference between a service locator and a locator ? David : On an end point, if I have reachability for high speed Internet, it may not matter. Services associated with a locator may be a [?]. Dimitri : Domain and service domain is similar David : Networks have overlay networks now. ? : Who is going to pay the cost for this ? Providers come in different shades of grey. Providers may be in the core, or towards the edge. Some of their priorities may be different. David : I agree with you. ? : End to end dynamics are important. The best architectures are not so go if they hose TCP. David : I agree Rüdiger : The administration of the address space has to be considered as well. David : There have been a number of factors. It is hard to apply policy to random numbers. - What properties should a solution have, if it it is going to help routing scalability? - Traffic engineering requirements - Role of identifier-locator split vs. general engineering improvements such as faster hardware 4. Architecture and design space discussion (Dave Thaler, 45 min) Dave : I am going talk about the design space. Terminology : Users start with names, not addresses. Ultimately, these are human names. Routing deals with locators Security deals with identities These may or may not be tightly bound. Today we use hierarchical aggregation as a tool, which is broken by - PI addressees - Site multihoming, which injects more specifics - Traffic engineering, which also may inject more specifics All three of these are due to local operational state being propagated globally. The mobility problem, conceptually you could do mobility by routing Or, you could (in principle) by name resolution. But you can't. We have to work with the existing world. The inability of the name resolution system out there to deal with rapid changes. Now, there is TTL, but the results of name resolution are cached, so they don't respect any TTL. The second have is that people want to preserve established connections. One trouble is you may go from being connected, to not being connected, and back to being connected. Will the connection survive the drop ? A good application will try to hide this from the user. From an application perspective, all should be transparent. If application did this, would this be sufficient ? No, due to real time applications. By contrast, in Site mobility (sites changing ISPs), the primary issue is renumbering. The pain of renumbering depends on how much has to change. RFC 3582 - applies to site and host multihoming. One name choses a set of locators to send to. Many application (TCP) only communicate one address, and you don't want to rebind in the middle, There is also a desire for location privacy. Today, the locator is in general visible to the endpoint, unless there is translation. Gregory : Is a locator and an identifier the same for privacy ? Dave : I intended to use something more abstract. What you are trying to hide is the locator. If they see enough they can infer your topology. People say, if I use NATs, all of my space needs to be changed. Going on, when I say managed system, is things that are frequently updated. Common cases In homes : Hosts get automatically updated, gateways are basically never updated. In the corporate world, routers get upgraded, while hosts are updated extremely rarely. It is hard to do this in the corporate world. So, how often you are updated depends on where you are looking. It turns out that new applications tend to move to higher level APIs. This is good for us, as these higher level APIs could be used to hide the IP address. There is a trend against apps even understanding IP addresses. Management and security systems are frequently the last and the hardest to change. Unlike applications, where changes on some end points may be beneficial, with management systems, until you change all of them, you get no benefit. That is what we have learned from IPv6 experience. Incentives : It is best that changes are only required by entities actually feeling the pain. Often, only one entity (such as one end) experiences the pain and is incented to change. (FOr example in Mobile IP, a endpoint many move but the web server does not.) It is best if solutions only require those feeling the pain to change. Supporting referrals - one application wants to refer or redirect you to another one. Can you redirect by name ? Yes, but this is limited. Applications, for example, may only cache addresses. Also, not all applications have a name. How is the mapping secured ? You want to be sure, if you start with a name, you get the same [service]. There is a name to IP address binding and a address to connection binding Today, DNSSec or IPsec are not really well deployed You can - secure per hop - secure end to end - or not have security. You need a chain of trust from the name to a connection. But not all applications know names, so you need an identifier 1.) How do we secure mappings today ? Identifier is algorithmically derived from the identity. This Binding is signed by someone you trust. 2.) How do you map ? If name == identifier, this is a no-op 3.) How you you map identifier to locations ? - Deal with things that dynamically change Dino : Also reachability of locators - that is different Dave : Yes. 4.) Where do you do it ? Vertically - application layer, network layer, below IP, etc. Horizontally - inside the host, or out in the network somewhere Margaret Wasserman - There are also issues of state in the network and path asymmetries 5.) When do you do it ? - A priori - On demand - at name resolution - at time of first packets - forced to buffer - this could introduce circular dependencies between routing and lookup - when do you get changes to the mapping ? Implications : If you do this in a router on demand, this implies demand on the router from the control plane Will this lead to mapping tables as big and dynamic as BGP day is today ? If so, have you gained anything ? Margaret Wasserman: Once you have developed the mapping function, why don't you replace BGP and we are done. It is almost certainly going to be as large as todays FIB. Ross : Issues are the total load on the control plane, which might be 10^4th slower than the data plane. You could really redesign routers... Elliot : You have an issue as to what problem you are trying to solve here. All of these presentations have almost no data on them. [I don't like that.] Tim Shepherd : You went down a path assuming a ID locator separation. Dave : These questions are for people who are assuming an ID locator split Elliot : There are other architectures to do this. Jim [?] : I think that you are missing the services point of view. Margaret : There is a referral that we don't always think about - an example, you might want to look on the node and get back to other nodes that are connected to it. That is a form of referral you are not including. Dave : Question 3 - is the identifier routable or not ? If it is not, you may need both ends to change. If it is "routable" it may introduce routing state. Question 4 : Is the ID and the locator present in the data packet ? Can intermediate systems see the identifier or not ? In tunneling, for example, the intermediate routers can see both addresses if they look inside the encapsulation. If not, asymmetric paths may mean intermediate systems may not have mapping state. Summary : Incentives are in different places os maybe there will be complementary solutions. - Reasons for doing an identifier-locator split - Design alternatives - Architectural tradeoffs - Application impacts - Balancing costs and benefits - Deployment 5. Solution space (Pekka Nikander, 15 min) Pekka : Potential benefits of the ID / locator split. Why should we do this ? There are lot of design choices. Will focus on 4 aspects - deployment, which is related to incentives - Where to implement - Identifier Structure - Resolution models If we think about deployment, one way is LISP 1 - - Identifiers are routable, which may increase routing state - identifiers are routable over another infrastructure. - get mapping from the DNS - new id-based routing system Also, vertical versus horizontal choice Vertical : Within App In IP Stack Below IP Horizontal : At the application deeper in the network Answer may be in multiple places. Questions : - How do we assure uniqueness ? - Are identifiers routable ? Globally ? Locally ? - How do the existing or proposed solutions fulfill the different types of needs? - A case for one or multiple solutions? Security Questions - self authenticating or not How do we resolve this mapping ? Is it Query based, like DNS ? ID router may do this. Potential benefits : Obvious ones : - Stable IDs - maybe on 2 levels Dino : Define stable ? PI addresses are stable PA addresses are not More benefits : - Better routing tables - may help with TE - may help with site multihoming. - Sub network mobility - provide IP4 and IPv6 interoperability Since you can change locators, some protection from DOS attacks We have solutions with a lot of additional information. There will be pain in the beginning, in return for gain later on. Two distinct communities will share the pain. Is there a way of getting these benefits by following one approach - or do we need more than one - 2 or more - solutions ? 6. Open discussion (45 min) 7. Conclusions and next steps (10 min, chairs & ADs) [Question on Dave Thaler Slide 12 ] I am afraid that the people doing control and management software assume that ID and locator is the same, which makes this difficult. Eric : Is the mapping function an attractive nuisance. Some people might want to use it for mobility. Who will control those policies - building another flavor of BGP ? Iljitsch : Both mapping databases, BGP and DNS, are about 20 years ago. BGP doesn't scale, DNS scales but isn't dynamic enough. I think it is important to take this opportunity to build this from the ground up and not use 1980's technology. Mobility and multi-homing are different things. Another thing, I think that Dave [Thaler] has a good view of what we can and cannot do. [couldn't hear response well enough] Iljitsch : We have DNS and BGP now, neither is going away. I was saying it makes sense to build the ID locator split from the ground up. Pekka N. : The horizontal is how you deploy it, the vertical is where in the protocol stack you deploy it. Lisa : I looked at the presentation - I thought I would hear everyone's wish lists Jari : We need to focus on the requirements. Mark : We wanted to look at the design to decide what we could possibly do. Margaret : I would like to see us form a working group, but I am not sure what the charter should be. I love the idea of an interim meeting in May. I think that we need a solution that works for IPv4 and IPv6, although the service level may be different. I am not sure where the new mapping function will come from. I think that it is going to require some breakthroughs. [?] : I think that I agree with 99.9% of the presentation - which worries me. What we should be looking at is, where is the gap we need to address ? Mark : Exactly - where are the gaps. David : A number of members of the ROAP directorate are here and we are going to write down a description of what the problems are that we are going to solve. [?] : And some kind of a gap analysis. Ross : I think that there are some things that we agree on - I see a lot of people who are willing to work ion this - I see a lot of willingness. I see a lot of this that we do not agree on - the problem we are trying to solve, the universe of possible solutions. Asking a person who doesn't know what the problem who to create a solution is probably not a good idea. Hard problems I see are : Where is the mapping ? Where is this happening ? How do you align the costs and benefits ? "It is about time we did." Fred Templin : I don't think that the jackup community is loosing sight of mobility. Pekka : I was just pointing out that there are these two communities. Danny : Network or host : If you don't aim at hosts, then end to end will be a casualty. Also, I do not think that there is a consensus in the routing community. Eric : I do not know what the focus of the working group would be. Dino : From a designers perspective - hard questions with easy answers. I would like like to have answers here in the spot. [When asked why, he said :] So I can start coding on the plane home. - Can we use the same solutions for IP v4 and v6 ? Dave Thaler : If possible, yes. - Do you believe we have to have a short and long term solution ? Jari : Yes - Do you believe that the long term solution [LTS] should replace the short term [STS] one ? We cannot make operators turn the network too often. Peter : If possible the STS should take into account the LTS ? : You have to design knowing that the short term solution will be around forever ? Dave : When do you think that these need to be deployed ? Dave Ward : I think that it is insane to assume that the short term solution will wither away. Dino : A short term solution will take maybe one or two of the problem statements to fix. We need to be really careful that we don't have a plethora of solutions. It is really important that we don't have too many solutions. Lisa : I agree with Dino We need a very clear requirements document. Bill Shepherd : I shouted why are you asking all of these questions and Dino said that he wanted to start coding on the plane. Aaron : The usual definition of IRTF vs IETF is that research is what you do when you don't know what you are doing. Margaret : I have concerns - I think that there is a lot of space for research, but I think that designing the solutions should take place in the IETF. They don't have to be as open as WG in the IRTFs. Jari : It is clear that we don't fully understand the problem - the Directorate will be working on the problem statement. We need to get Dino coding. We need that experience A quick poll - interest in an interim meeting ? [30 people at least] [Meeting ended a few minutes late]