---------------------------------------------------------------------- Minutes of the IRTF Routing research group meeting at IETF 76 November 13, 9:00 - 17:00, ANA Crowne Plaza hotel, Hiroshima, Japan ---------------------------------------------------------------------- Minutes by Christian Vogt, Dave Oran, Lixia Zhang AGENDA 09:00 Logistics, agenda bashing Chairs 09:10 Process towards a recommendation Lixia Zhang 09:30 Routing Architecture for the Next Generation Internet Xiaohu Xu 10:15 Routing and Addressing in Next-Generation EnteRprises Fred Templin 11:00 Evolutionary Path Towards Global Routing Scalability Lixia Zhang 11:30 Lunch Break 13:00 Open mike All 13:30 The Name Oriented Sockets Interface Christian Vogt 15:15 Official End 17:00 Real End Slides available at: https://datatracker.ietf.org/meeting/76/materials.html#wg-RRG THE RECOMMENDATION PROCESS (LIXIA ZHANG) The co-chairs put forward the following milestones for the RRG recommendation process: December 15, 2009: Final call for proposals February 15, 2010: Compare and evaluate candidate proposals March, 21, 2010: document RRG recommendation Aaron Falk: RRG recommendation should consider all types of cost, in particular transition cost, who pays for the solution and who gains the benefits, to capture different nature of costs in the documents. This was concluded in RRG review meeting with IAB yesterday. Brief discussions on (1) the tight schedule, we shoot for next IETF for a preliminary, rather than the final fully polished, version of recommendation (do plan to finish the final version before the following IETF); and (2) on the nature of the recommendation. We should document solution space analysis, but also need recommendation of a single proposal. Can be combination of proposals as long as each proposal addresses unique part of problem space. Tim Shepard: The routing scalability problem will continue to be interesting, even beyond these milestones. We may realize, however, that part of the routing scalability problem may be solved by solutions other than changes of the routing system. May be solved outside of routing system. E.g., host-based solutions such as multi-path TCP may take away some load of the routing system. ROUTING ARCHITECTURE FOR THE NEXT-GENERATION INTERNET by XIAOHU XU Pete Resnik: The administrative domain of your proposal is geographic. But routing does not have to be geographic, right? Xiaohu: This was just an example. We do use a hierarchical host identifier, because this is easy to manage. But the hierarchical boundaries do not have to be geographic. Gregory Cochie: You slides have mixed routing and identifier resolution. Hence to clarify: Do you use a DHT for identifier resolution? Xiaohu Xu: We use a DHT for identifier resolution. The issue with the DNS is that only a limited amount of mapping information can be stored at the bottom-most layer of the hierarchy. With a DHT, more mapping information can be stored at the bottom-most layer. DY Kim: According to your proposal, both identifiers and locators must be globally unique and hierarchical. Is either one really a requirement? I.e., should both identifiers and locators really be globally unique and hierarchical? Xiaohu XU: Answer is yes to both of your questions. Both identifiers and locators must be globally unique and hierarchical. ROUTING ADDRESSING IN NEXT-GENERATION ENTERPRISES (FRED TREMPLIN) DY Kim: On your slide with your first diagram, the IPv4 addresses can be private, right? Fred Templin: That's right. DY Kim: In your diagrams, you were using IPv6 at the edge. Yet your mechanism also seems to work if you used IPv6 addresses, global IPv4 addresses, or private IPv4 addresses at the edge. You could even use identifiers instead of IP addresses, right? Fred Templin: Yes, we are indeed envisioning HIP to be used alongside my proposal, although the HIP identifiers will be transparent from the perspective of the proposal. IPv4 addresses could be used at the edge, but we focus on IPv6 addresses here, as there won't be enough IPv4 addresses to make the proposal feasible. Christian Vogt: As you said in your presentation, the basic encapsulation concept is already old; the fundamental difference between all encapsulation proposals is not so much about the components, but rather about how the components are put together. It would be useful if the RRG recommendation analyzed the different ways to put the components together, and what the resulting pros and cons are. Fred Templin: Right. Another difference between my encapsulation proposal and many others is that I have taken an engineering approach and worked out most of the details already. Peter Lothberg: How does a border router know when to NOT use a redirect received from a default mapper. E.g., how does the border router know when a redirect has timed out? Fred Templin: Redirects have a lifetime, assigned by the default mapper by which they are sent. Peter Lothberg: What if the egress tunnel router goes down before the lifetime expires? Fred Templin: The ingress tunnel router listens for ICMP Destination Unreachable messages that indicate the unavailability of the egress tunnel router. There is also a liveness protocol between the ingress and egress tunnel router, which starts as soon as the ingress tunnel router has received the mapping. This liveness protocol is piggybacked on the data packets. Mingwei Xu: Your proposal is similar to some of the work from the Softwire working group. Softwire uses BGP to exchange mapping information, but fundamentally it is doing the same that your proposal does. Fred Templin: Softwire uses an alternative mapping system. There are other alternatives, such as reuse of the DNS, or DHTs. You will find similarities in all of the encapsulation approaches. This work started earlier than any work in the Softwire working group. Xiaohu Xu: As we know, caching is still an issue in LISP. How do you avoid it? Fred Templin: If redirect times out, the traffic will fall back to the default mapper, until the default mapper sends another redirect to refresh the cache. Xiaohu Xu: Then your proposal is very similar to APT. What is the difference? Fred Templin: Yes, this proposal is very similar to APT. The draft talks more about this. Tony Li: Since the example topology in your picture is recursive, it is possible that the transit network in the middle is a tier-1 ISP. Then the topology may be much denser than in your picture. So there may be many other transit networks, or chains of transit networks, that connect the networks to the left and to the right of your picture. Each of them will have their own sets of border routers. If the currently selected path fails, the ingress border router will flood the default mapper. Fred Templin: Not necessarily. The default mapper will not just provide one mapping, but multiple. Tony Li: Do we have a liveness mechanism for the backups? Fred Templin: They have a lifetime. Plus, there can be liveness checks between pairs of border routers. Tony Li: So now we have N-square liveness probing? Fred Templin: This is still an open issue. But the issue is not specific to my proposal. All encapsulation proposals have the same problem. AGGREGATION-BASED EVOLUTIONARY PATH TOWARDS GLOBAL ROUTING (LIXIA ZHANG) Aaron Falk, on Lixia's point that there needs to be an immediate benefit: You should also consider cost, not just the benefit. in this community there are social pressures, especially if the cost is low - part of cost is perturbing existing system. Christian Vogt: Agree. Risk comes with any type of change. So small changes are typically preferable over big changes, even if the benefit for a big change may be larger than the benefit for a small change. Aaron Falk: I actually think that risk is the biggest cost for any solution. Christian Vogt: On Lixia's point that the benefit for a solution must be immediate... Solutions that require coordinated deployment by multiple parties already cannot provide an immediate benefit, and hence have a significant deployment disadvantage. David Oran: You have an advantage if pair-wise deployment is possible. Ruediger Volk, on Christian's point: I agree that this is true for very different parties. But if multiple parties are facing a very similar problem, coordinated deployment may be feasible. Christian Vogt, on David's point: Yes, by pair-wise deployment you can remove the risk that your deployment cost will not pay off. However, for this to work, some form of bilateral agreement is necessary. And requiring such bilateral agreements is not a scalable approach. Ruediger Volk, on Lixia's claim that FIB compression provides benefit: Not sure about this, because FIB compression alone is only a data plane optimization that does not improve the scalability of the control plane. Lixia Zhang: FIB compression is not a necessary first step. You do it only if you need to. And whether or not you do it has no impact on the second step. The second step will then improve the scalability of the control plane. Tony Li: Although you do spend effort on the first step, effort that you won't spend any more on the second step. Lixia Zhang: You will only spend effort if you feel you need it. An analogy: You can spend money today on bread, or you can save the money to buy something nicer after one week. You may be able to buy something very nice after a week, but if you don't eat today, you may no longer be after one week. Tim Shepard, on Virtual Aggregation: When you say "path stretch", do you meet additional hops within an ISP? And if so, how do you avoid loops? Lixia Zhang: Yes, "path stretch" refers to additional hops within an ISP. But there can't be loops, however. Read the specification. Peter Lothberg: Some ISPs drop certain prefixes because they don't comply with their peering policies. This practice cannot be supported by Virtual Aggregation. Lixia Zhang: Again, you don't have to do Virtual Aggregation if it doesn't work for you. But I would be happy to talk more with you to make the practice you mention compatible with Virtual Aggregation. Tony Li: If you ignore more-specifics, then you are effectively doing proxy aggregation. If your neighboring AS's don't do the exact same operation as you do, it may happen that your customers' traffic will be routed around you. We actually ran this experiment in 1993. David Oran: A graph that I would like to see is one where the X axis shows the benefit of Virtual Aggregation on routing scalability, and the Y axis shows the number of lines in the BGP configuration file that needs to be exactly right for Virtual Aggregation to work. Lixia Zhang: Yes, I agree. Ruediger Volk: If this uses proxy aggregation, then you may end up creating loops. Tony Li: Proxy aggregation is not known to cause loops, but it can cause traffic engineering faults. E.g., instead of traffic between Germany and Japan going via the U.S., it may go via Africa and Asia. - summary: god routing architecture fulfills function needed today, put FIB,RIB under control, must be incrementally deployable!, stay flexible for tomorrow. - Paul Francis: if/when LISP or ILNP succeeds one day, we no longer need all this stuff. VA provides solutions to meet individual AS problems today while we wait. [end of AM session] ---------------- 1300 AFTERNOON SESSION START OPEN MIKE DISCUSSION A lively discussion on whether renumbering, assuming it can be done, could be used to make routing table size under control. Lothberg expressed an opinion that we do not have a routing scalability problem, because a transit address has a large number of end nodes behind it. If we had an identifier-locator separation, we could adapt addressing as the topology changes. Topology-aligned addressing will reduce the load on the routing system. Others pointed out that this would be the case only if the connectivity is tree-like; today's topology is richly meshed, or more like spaghetti than tree or hierarchy. Separate from the fact that every end node (identified by some EID as Lothberg proposed) can be reached through multiple different interfaces, eveyr edge site can also be reached through multiple paths (site multihoming). how would the overall picture look like? Halpern, Resnick and others expressed opinions that renumbering cannot be taken as a given at this time. Mobility for individuals could be handled by the end hosts. But renumbering on the larger scale seems more like a network issue. See Carpenter draft "Renumbering Needs Work". Vogt pointed out that Lothberg assumed that the routing scalability problem can be fixed by identifier-locator separation. His opinion is that host-based identifier-locator separation can solve host multi-homing problem. And it mitigates the renumbering problem, in that it eliminates issues with referrals (i.e. one use EID in referrels instead of IP address which may change due to renumbering), such as in applications, configuration files, scripts, databases, etc. Furthermore, NAT can be a way to get around the difficulty of renumbering. Joel Halpern: I think identifier-locator separation is a useful tool that we should push forward. But we have a choice, and I have a preference on this choice: The separation can be at edge network borders or in hosts. If we push the separation into hosts, we still need to solve the renumbering problem partly. But I believe that the existence of the identifier-locator separation will enable us to find better techniques to solve the renumbering problem. Joel advocates a combination of ILNP plus the work on renumbering. Brim: But we also need a solution at edge network borders until we have solved the renumbering problem. Lothberg: A couple of years ago, I calculated what the size of the routing table would be with 8+8, in a future scenario with 20 billion mobile users. It was half of what the routing table is today. Zhang: Number of route announcements per allocated address block can be large, the site who owns the block is multihomed, so we are talking the product of (# fragmentaitons)X(# multhome links) here, because people do traffic engineering. Christian Vogt: Back to Joel's comment. Fully agree with the need for a combination of solutions. As a matter of fact, I suggested the same a few RRG meetings back. I would like to add to this, at the risk of making myself unpopular: Unilateral address translation would be one solution to the renumbering problem. There are two reasons why NAT'ing is unpopular: First, because it is has a robustness issue due to introducing state in the network. Second, because it is incompatible with address referrals. Now, the first of these goes away in IPv6, where we can do stateless one-to-one NAT'ing. And the second goes away as soon as we have an identifier-locator separation in place. Remi Despres: I have a proposal in Softwire, SAM, that uses encapsulation instead of translation and is therefore transparent. Could this be reused here in RRG? Christian Vogt: It could, but unilateral NAT'ing as opposed to bilateral en-/decapsulation has the huge deployment advantage that it does not require a mapping system. True, this comes at the cost of loss of end-to-end addressing. But if we have an identifier-locator separation, loss of end-to-end addressing will no longer matter. Scott Brim: Fully support what you say about NAT. Operators are parsimonious. So we need to take into account how much NAT there is and how much NAT there will be. Remi Despres, on Christian's comment: SAM does not do end-to-end encapsulation like LISP; it is local to one network, and therefore very easy to deploy. The difference is like between 6to4 and 6rd. Joel Halpern: Regarding the question of whether to place functionality at edge network borders or inside hosts: While a placement at edge network borders may give us some leverage on the short run, I would like to evolve to a solution that is not dependent on additional functionality in the network, to reduce the dependency on special network infrastructure. Remi Despres: Yes, but then we should proceed with what Christian is proposing: an identifier-locator separation where the identifier is the domain name. This solves everything. Peter Lothberg, on Joel's comment: Joel made a very important and correct point. We can put boxes into the network to interface between the old and the new world, and then move them further and further to the edge until they fall off the cliff. Lixia Zhang: I agree with Peter, but I wonder how we get from here to there. Especially if we don't have the money. We need an evolutionary solution, where each step is small. Peter Lothberg: That reminds me of DSL, where operators have polished copper for a long time rather than upgrading to fiber. We can polish copper until we have spent more money than we would have if we had deployed fiber in the first place. It is not only the investments, it is also the operations and support. Christian Vogt: Lixia's call for an evolutionary solution seems to be based on assumption that it is much more difficult to change hosts than it is to change the network... Lixia Zhang: No, the problem is not that host changes are difficult. The problem is that it is difficult to rely on a sufficient number of hosts to be upgraded. Peter Lothberg: But for this you can use network-based proxies temporarily. However, there should be a clear direction of where things are going. The problem with an evolutionary solution is that every step is costly. Pete Resnik: Two comments. First, on Peter's point why people want to polish copper. There is a reason why they polish copper: It is because they have lots of it. And the probably only way to make them adopt something else is by legislation. Second, while it would be nice to have a host identifier, you may run into situations where traffic makes a large detour so that the identifier can be maintained. Peter Lothberg: Not trying to solve the problem with DSL. I was just making the point that the total cost of polishing copper over 15 years was higher than adopting fiber in the first place. To Pete's second point: Detours are not necessary because the hosts will get their address from their current location, and the identifier is independent of that. We will have a mapping system Tony Li: How many folks believe that an identifier-locator separation is necessary. Dae Young Kim: I support identifier-locator separation with the restriction that identifiers are globally unique, and locators are locally unique. This allows each AS to have its own private locators, and inter-AS gateways operate only on AS numbers. Peter Lothberg: Trying to respond to Lixia about the enterprise. Assume you have an enterprise with private locators, then inter-AS gateways could translate between the private locators of different AS's. If we had an extensible address format, this would allow us even to use longer addresses in certain parts of the Internet if, one day, we run out of address space. Unfortunately, IPv6 was designed not to be extensible. Gregory Cauchie: Comment to Kim -- We thought about AS for some time, and we found that a problem of this is traffic engineering. This doesn't work well. If you have a good solution to this, it would be interesting to hear it. Comment to Tony about group charter -- We are in routing research. Are we dealing with "how to get there", or are we focussing of routing. Tony Li: Our goal is to design a routing architecture. That includes addressing. Routing and addressing are intimately tied together, and you can't talk about one of the two without considering the other. Now, the current routing protocols don't do anything fancy, and as the evidence shows our problem is addressing. Peter Lothberg: I haven't actually seen any advancement in routing in this group so far. Another comment: If we have an identifier-locator separation, you can actually do something like label swapping, so that the address in the middle of the road does not need to be the same as the address at the beginning of the road. Dae Young Kim: Which number to use for identifier, and what number to use for locators is a detail. We don't need to consider it. Scott Brim: Tony, I need a scoping statement on identifiers. We had statements on whether identifiers should be global or local, and if we discuss this, I have plenty to say. Is this in or out of the scope of this discussion? Tony Li: Not arguing whether this is relevant; I just note we have only two minutes left. John Schnitzlein: I don't think identifier-locator separation is necessary. It may be useful, but that's a different question. I think we should be looking for designs that don't require mapping, because the mapper may not scale, it may be insecure, etc. THE NAME ORIENTED SOCKETS INTERFACE (Christian Vogt) Meeting adjourned.