Folks, enclosed you find my meeting minutes for the RRG sessions on March 11 and March 14, 2008, in Philadelphia.
Should I have missed somebody's comment or question, don't hesitate to let me know. - Christian
IRTF Routing Research Group Meeting March 14, 2008, Philadelphia, PA, USA ------------------------------------- Minutes taken by Christian Vogt <[EMAIL PROTECTED]> AGENDA 09:00 Chairs: Logistics, agenda bashing 09:05 Christian Vogt: Six/One Router 09:30 Christian Vogt: DNS Map 09:50 Dino Farinacci: LISP update 10:45 Lixia Zhang: APT incremental deployment 11:30 End CHRISTIAN VOGT: SIX/ONE ROUTER Jari Arkko: If we agree that the cost of address translation is acceptable, then I have an even simpler solution: Just use a regular NAT without additional functionality. Christian Vogt: That's possible, but the additional functionality, which Six/One routers have beyond simple NAT'ing, offers benefit for deployers as well as for the Internet at large: The traffic redirection functionality will facilitate traffic engineering and multi-homing. And the functionality to do "inverse" NAT'ing (i.e., the equivalent to tunneling) will eliminate the disadvantages of NAT'ing when Six/One Router is deployed on both sides of a packet exchange. This not only makes the address indirection transparent to hosts and edge networks, it is also a chance to eventually mitigate the adverse affects of NATs -- be they used for routing scalability purposes, or for any of the other reasons for which they are widely deployed already today. Jari Arkko: All solutions, not just Six/One Router, have a cost, and we have to carefully analyze this. In the case of Six/One Router, the cost comes in the form of address translation for packet exchanges between upgraded and legacy edge networks. Christian Vogt: The impact of address translation depends on whether the translation is 1-to-1 (each edge address maps onto a unique transit address) or many-to-1 (edge address multiplexing). Most of the issues with today's NATs are specific to many-to-1 translation and absent from 1-to-1 translation. Address translation in Six/One Router could, in principle, always bee 1-to-1. But due to IPv4 address scarcity, many-to-1 translation may be more desired in the specific case where a host in an upgraded edge network communicates with an IPv4-only host in a legacy edge network: The transit address of the host in the upgraded edge network then has to be IPv4, and unless it is unique for the host, many-to-1 translation will be required. -- In all other cases where upgraded and legacy edge network communicate, 1-to-1 translation can and should be used. And when two upgraded edge networks communicate, Six/One Router does not perform translation at all, but rather an equivalent to tunneling. John Scudder: Addition to slide 11: During the deployment phase, edge networks won't be able to fail-over packet exchanges. Christian Vogt: Right, because the transit addresses selected initially are used by the host in the legacy edge network, so re-connection is required upon fail-over. DINO FARINACCI: LISP UPDATE Phil Eardley: The interworking mechanism that uses translation, is this the same that Six/One Router is doing? Dino: Yes, but a lot of details are different. Tony: Do I have to renumber when I change my proxy provider? Dino: No, all proxy providers advertise the entire edge address space. Christian Vogt: If all proxy providers advertise entire edge address space, then all of them will have to be paid by someone, presumably the edge networks that adopt LISP. Isn't this a deployment hurdle? OTOH, if only selected proxy provider(s) advertise the edge address space of an edge network, then that edge network will have to renumber upon changing proxy provider(s). Joel Halpern: Given the advantages of IPv6 in terms of larger address space and more topology-independent bits per IP address, maybe we should focus on routing scalability for IPv6 rather than trying to solve the problem for both IPv4 and IPv6. Christian Vogt: Or rather accept different solutions for IPv4 and IPv6 rather than striving for one unified solution. LIXIA ZHANG: APT INCREMENTAL DEPLOYMENT Ruediger Volk: Users won't like if voice packets get delayed during mapping lookup. Tony Li: This is an issue that is general to all address indirection proposals where the edge addresses are non-globally routable. Someone: Denial-of-service vulnerability with caching: By sending packets to random destination addresses, attacker can cause a local indirection router to fill its cache with bogus entries. This may result in decreased performance or denied service for legitimate packets. Joel Halpern: Not sure how you save anything for single provider because what APT gives for a single provider is what the provider can achieve already today with MPLS. Lixia: You keep the routing table in tunnel routers small via caching and having all information in the mapping table. Joel Halper: OK, if you get the caching to work, then there would be an advantage. Christian Vogt: Most address indirection proposals call for deployment at the Internet edge. Deployment starts in some region of the edge and grows to the rest of the edge. APT complements those proposals with a technique that starts deployment in the Internet core and grows from there towards the edge. Very interesting idea. Christian Vogt: APT's tunneling and mapping handling are orthogonal aspects. Neither depends on the other. Lixia: Right, but we use both in APT to reduce the requirements on edge devices. Edge devices are important; there are many of them.
IRTF Routing Research Group Meeting March 11, 2008, Philadelphia, PA, USA ------------------------------------- Minutes taken by Christian Vogt <[EMAIL PROTECTED]> AGENDA 09:00 Chairs: Logistics, agenda bashing 09:10 Philip Eardley: Locator/ID Proposal Evaluation 10:10 Chairs: Mapping Model Discussion 11:30 End CHAIRS: LOGISTICS, AGENDA BASHING Tony Li: RRG's recommendation to IETF will be a new routing architecture, i.e., a description at conceptual level. It will not be tied to specific proposal. Dave Meyer: From a sufficiently high perspective, everything looks the same. What is it that you mean by "conceptual level"? Tony Li: One level above algorithmic level, but just one level. Dave Meyer: Could you give examples? Tony Li: Map-and-encap, translation, push, pull. Aaron Falk: Once you pick architecture, you flesh out the specific design implications, based on the engineering knowledge in this group. Tim Shepard: Sounds what you proposing is what the charter of the group is, which is good. Dow Street: How much IETF will follow our recommendation will indicate how well we did our job. Tony Li: Fred Templin's presentation was moved to the Internet area session. PHILIP EARDLEY: LOCATOR/ID PROPOSAL EVALUATION Tim Shepard on policy routing: Look at today's Internet -- you have two classes of service -- those networks in the core and those on the edge. Christian Vogt: Good example. It shows that, if you put certain networks at a disadvantage at the benefit of the Internet at large, they are likely to strive for the advantage of the other networks. In the example Tim has given, edge networks strive for provider-independent address space, which architecturally should be reserved to providers. David Oran: Was this group chartered to solve the address exhaustion problem? Three ways: Same solution for IPv4 and IPv6, different solutions, or don't solve v4 case at all. Tony Li: RRG was not chartered to solve the address exhaustion problem. Christian Vogt: Right, but a solution should not exacerbate the address exhaustion problem it either. Scott Brim on Philip's slide: Anycast and proxy are not equivalent. Christian Vogt on computationally expensive tasks in indirection routers: Tasks in indirection routers are oftentimes computationally more expensive tasks when you communicate with legacy networks. Philip Eardley: Which you will do presumably for some time... Christian Vogt: That's correct. Scott Brim on mapping storage: Most of the mapping resolution systems don't require you to have all the information in one place. Philip Eardley: Yes, this is only looking at the push systems. Sriram K. on mapping updates: Mobile networks such as airplanes cause more frequent mapping updates. This increases the high churn of the mapping resolution system. Someone: The Internet is going to suffer if you make it too complicated. Dimitri Papadimitriou: Are you concluding that map-and-encap is the way to go? Philip Eardley: No, we don't. We just limited our analysis to map-and-encap schemes. Christian Vogt: It is necessary to focus a bit in order to come up with a good analysis because the solution space is large. Putting focus on map-and-encap was therefore wise, IMO. MAPPING MODEL DISCUSSION Dino Farinacci: If people were to trade-off packet loss vs. propagation delay, what would they choose? -- Fifty-fifty. Someone: Analysis would be better than a poll in the room. Joel Halpern: What is important is determinism. Stig Vens: Not saying which would be better -- loss or delaying. But analysis of this would be important, especially because it is the first packet in a connection. Tim Shepard: Be it loss or delay -- what matters to the user is what the responsiveness is. And if there will be different classes of service, there will be demand for first-class service. Lixia Zhang directing discussion back to architectural level... Tony Li: Push or poll. Sriram K.: All the basic hooks for doing push, pull should be available. The element of distributedness of mapping is another feature of flexibility. The equipment providers can combine these elements to implement mapping distribution algorithms that can be proactive and dynamic so as minimize mapping delays. Elliot Lear: Authors should put more emphasis on security considerations. Christian Vogt: Before we can decide whether a poll or a push system would be preferable, we should decide what the mapping resolution system should achieve. E.g., if it were to achieve mobility support, a poll system would be preferable. Joel Halpern: Saying that something is not within scope will help us. Tim Shepard: We don't have the power to set policy on how a system will be used. Sometimes systems are used for something they were not designed for it. An example is Connexion's use of BGP for mobility. Elliot Lear: Can we do better than what is out there today in terms of mobility protocols? Tim Shepard: Should there be a place in IETF that considers architectural decisions? These are important architectural decisions that are to be made. Tony Li: We are talking about what churn rate a mechanism can support. There is churn for mobility and for other reasons. Sriram K.: Eventually, cost-performance trade-off will set the limit on what the mapping systems can support. In order to keep cost from being excessive, performance may have to be limited. For example, push-only system can be very expensive while its delay performnce is the best. Based on the advertised performance for the mapping system, the mobility application developer can decide whether to depend on mapping or resort to traditional IP mobility solutions. Tim Shepard: ID/locator split is how people handle host moblity. Lixia Zhang: Different understanding of what ID is: In LISP, ID is an address. In HIP, it's a real ID. Another clarification: You can solve the problem at the IP layer, and it is still outside the routing system. Dave Meyer: The point I didn't see much discussion on is mapping resolution latency. Ross Callon: Granlularity and churn are currently labeled "not done" on Scott's overview. This seems to be very important, however. Scott Brim: This is why I labeled them. Tony Li: Are there more things to be discussed and put on Scott's list? Dave Meyer: Deployability is important to consider as well. Currently missing on Scott's slide. Christian Vogt: One thing to be added to Scott's list is the placement of mapping information: Where should mapping information be stored -- at the owner, at the user (so that it can reach the owner), or at a third party. Tim Shepard: Another item for Scott's list: How does the mapping resolution system respond to churn rate change? Dino Farinacci: Should we add how well a system supports IPv4/IPv6 transition? Tony Li: No, it's not in the charter. Someone: Should reachability be part of the mapping system? David Oran: I wouldn't confound reachability and preference. Sriram K.: Prioritization of mapping messages in processing would help failure recovery. Dow Street: We should also consider dependencies on entities that are not on the data path. E.g., if I have to contact a 3rd party that is off the path to the peer I want to reach, and the path to the 3rd party is down, then I won't be able to reach my peer even though the path to it is up. Lixia Zhang on "churn": Two types of churn -- intentional (mobility, updates), unintentional (failure). Darrel Lewis: Amplify on what Lixia says: Who is authoritative for mappings -- owner or 3rd party? Lixia Zhang: Three entities: owner of mapping data, user of mapping data, holder of mapping data. Philip Eardley: Another item for failure mode: resilience of mapping system.
