[RRG] RRG Meeting Minutes

[Christian Vogt <christian.vogt@nomadiclab.com>]

Folks,

attached please find the RRG meeting minutes from July 27.

In case I have missed a comment that you think should be added, please
send me a note:  christian.vogt@nomadiclab.com

Best regards,
- Christian

Meeting of the IRTF Routing Research Group

July 27, 2007, 9am-5pm, Palmer House Hilton, Chicago, IL, USA

Minutes by Christian Vogt <christian.vogt@nomadiclab.com>



Meeting Agenda

The order of the presentations following the lunch break was changed during agenda bashing.  Here the updated agenda version:

09:00 Chairs:  Logistics, agenda bashing
09:05 Tony Li:  Design Goals
09:30 Lixia Zhang & Scott Brim:  Design Taxonomy
10:15 Christian Vogt:  Six/One
11:15 Lixia Zhang APT:  A Practical Transit Mapping Service

12:00 Lunch

13:15 Jim Griffioen:  Separating Routing and Forwarding
14:00 Dino Farinacci:  LISP-01
14:30 Eliot Lear:  NERD
15:15 Dave Meyer & Dino Farinacci:  LISP-CONS
16:00 Luigi Iannone:  Cost of Mapping

17:00 End



Tony Li:  Design Goals

[reference:  draft-irtf-rrg-design-goals-01]

Tony summarizes the changes to the design goals document:

- Scalability.  Added explicit requirement that the control plane (which consists of the state and processing overhead involved with computing and maintaining the routing table) should scale independently of the size of the Internet user population.

- Routing quality.  Added routing stability as another routing quality goal.

- Security.  Any solution should provide the same security as the Internet architecture provides at the time the solution gets deployed.  The old draft version required the security that the Internet architecture has /today/, but the security provided might change until a solution gets deployed.

- Deployability.  Clarified that solutions should be deployable only from a technical perspective.  Deployability from other perspectives, such as in terms of today's business models, will not be discussed at this stage.



Lixia Zhang & Scott Brim:  Design Taxonomy

[reference:  http://www.cs.ucla.edu/~lixia/taxonomy.pdf]

Lixia presents work on a design taxonomy.  This work is not complete yet, and there is continuing work on improving it.  It is based on existing solution proposals, but looks at them from an abstract perspective.  It therefore does not use any solution-specific terminology such as "ingress/egress tunnel router".

Dave Meyer:  Reducing the size of the routing table comes at a cost.  Need to evaluate trade-off beween small routing table and its costs.
Lixia:  That's a good point.

The taxonomy differentiates two approaches:  (1) Topological aggregatable addresses, and (2) separation of edge addressing space from transit addressing space.  Shim6, Six/One use (1); LISP, Ivip use (2).  Approach (2) could be recursively applied, resulting in more than two addressing spaces interconnected through tunneling mechanims.

Geoff Huston mentions that there should be more approaches.  E.g., MPLS would not be covered by (1) and (2).  He will send a more detailed comment to the mailing list.

There are three entities involved in the mapping between address spaces:  The owner of the mapping, the holder of the mapping, the user of the mapping.  These may be three different entities.  Three fundamental questions:  (a) How to get the mapping information?  (b) How to detect failures?  (c) How to handle failures?  Solutions must address these three questions in a secure and scalable manner.  They must also address data delivery performance:  Delays due to mapping look-up, delays due to suboptimal paths, packet loss due to lack of mapping info or during path failure, and congestion.

Failure detection:  Today, path failures are handled by BGP through prefix withdrawals.  This alone will no longer suffice if we have multiple equivalent paths with different destination addresses.  If all destination addresses are visible to the host (as in Shim6 or Six/One), failure detection can occur inside the host.  But there need to be additional mechanisms if multiple destination addresses are mapped onto a single edge address at the border between edge and transit space.

Erik Nordmark:  The advantage of host-based reachability verification is that the host can monitor the full paths in both directions.  Reachability verification inside the network may be more difficult due to asymmetric paths, and only part of a path may be visible.

If the mapping takes place inside the network, two new questions arise:  What to do with packets during mapping look-up?  What to do with packets in case of failure?  These issues did not exist before, because look-up and failure handling now happens when packets are already in the network.

Kevin Fall:  Handling failures inside the hosts may not be good if you think of less and less capable devices such as mobile phones.
Erik Nordmark:  It depends on how many paths you can select from.  If you only have two, failure handling is easy.  If you have 16, it becomes more difficult.

Erik Nordmark:  There is a risk that you engineer a multi-homing solution, but forget about traffic engineering.
Lixia:  I don't see a big difference between the two.
Erik Nordmark:  There are different levels at which you might want to do traffic engineering.
Elliot Lear:  We need more data on whether it is sufficient to solve the multi-homing problem, or whether we need more functionality for traffic engineering.

Sandy Murphy:  You are mentioning mapping security on your slide.  This is only one part of the security of the routing system.  John Scudder had a presentation on routing system security at last IETF.
Lixia:  Right, this is a good point.



Christian Vogt:  Six/One

[reference:  draft-vogt-rrg-six-one-00]

Dave Oran:  For routers to be able to rewrite addresses consistently for packets in both directions, paths have to be symmetric.  How do you enforce that your paths are symmetric?
Christian:  You don't need symmetric paths.  If there is an address rewrite in one direction, hosts will see this and adapt their addresses.  Hence, the new addresses are also used on the reverse path.  You also don't need Six/One-specific state on routers for address rewriting -- no per-host state, no per-session state.  Routers simply rewrite the routing prefix part of an address, not the entire address.  And the routing prefix depends on just the provider via which packets are directed, not on a host or a session.

Tim Shepard:  How does a router rewriting an address know that a host can recognize the address change?
Christian:  Six/One requires support on both sides of the connection, and we are currently assuming that this support exists.  The draft describes an approach for transitioning towards full or at least very wide deployment of Six/One.  One could also devise a mechanism for discovering Six/One support on the remote side of a connection.  But given that Six/One is required for edge networks to do traffic engineering, full or wide deployment of Six/One would be required anyway.
Tim Shepard:  This is a nice idea, but I wonder if we will be able to get to a full or wide deployment of Six/One quickly.  I wish we had thought about something like Six/One years ago...
Christian:  Right.  The crucial part is to bring Six/One support into hosts.  You don't need any support in the network.  Edge networks just /use/ Six/One in case they want to do traffic engineering.

Dino Farinacci:  This looks very much like Shim6.  What is the difference?
Christian:  The crucial difference is that Six/One can cope with network-side address rewrites.  Hence, different than Shim6, Six/One enables edge networks to choose a provider through which packets go.
Dino Farinacci:  Now, what is the difference between Six/One and GSE?
Christian:  In GSE, the hosts never see their own IP address in its entirety.  Thus they don't know which provider their packets go through, neither can they influence the selection of the provider.  Hosts in GSE also are not aware of provider changes so that they cannot adapt, e.g., by triggering a TCP slow start or reset TCP round-trip time estimates.

Brian Carpenter:  I wish that we have had an idea like Six/One in the Multi6 working group.  Besides, the GSE proposal never reached a state that was plausible.  I believe that Six/One is promising.

Geoff Huston:  If both the host and the edge network select addresses (and thereby a path), who wins?
Christian:  Given that the edge network has the packet after the host, the edge network has the final say with respect to where packets go.  This is in line with the design objective of allowing a host to /suggest/ which path packets take, but leave the final decision to the edge network in order to give it full flexibility for traffic engineering.
Geoff Huston:  The problem is that only the host has the full view of path failures due to potential path asymmetries.  So only the host can do reliable failure detection/recovery.  If you allow routers in the network to rewrite addresses, then the addresses chosen by a host for failure recovery might be rewritten by a router -- thus defeating the host's failure recovery.
Christian:  This is correct, but there is a clash of interests here.  On one hand, hosts want to be able to have full control over path selection, as only they have full visibility of path failures.  On the other hand, edge networks want to be able to control path selection for otherwise they are limited in terms of what traffic engineering they can do.  Six/One effects a compromise.

Erik Nordmark:  Did you remove anything from Shim6?  Or is Six/One on top of Sim6?
Christian:  The addresses in Six/One are generated differently than in Shim6.  All addresses in an address bunch have the same interface identifier, which is cryptographically generated such that remote correspondent hosts can securely verify that all addresses in the bunch belong together.  (This is a protection against impersonation attacks.)
[Added after the meeting:  Another difference is the way context IDs are generated in Six/One.  They can be used by middleboxes to associate different addresses of the same correspondent host, even if the correspondent host is located in a remote edge network.]

Dino Farinacci:  Did you consider tunneling instead of address rewriting?
Christian:  Hosts have the knowledge necessary to reverse address rewrites without having the original addresses in the packets.  We can therefore save the bandwidth and processing costs of tunneling.
Erik Nordmark:  When Mike O'Dell wrote 8+8, he said that rewriting would be useful for operators.
Suresh Krishnan:  Rewriting is useful for operators when they do traffic engineering.

Erik Nordmark:  The beauty of rewriting an address in a router is that this is a router that is likely to have the authority to change the packet:  Since the packet goes through that router anyway, the router would even have the ability to drop the packet altogether.
Erik Nordmark:  If you use provider-independent addressing space in the edge network, the network can select the provider anyway, and the host has no influence on path selection at all.  Shim6 is the other extreme, where the full control is with the host.  Six/One makes a compromise.

Tim Shepard:  Since only the host has full visibility of which paths work, it might be good to leave path selection to the host.  You could do this with a signalling mechanism through which the edge network could signal a preferred address to the host.  This could be implicit by dropping packets or rate limiting packets.
Christian:  Had thought about explicit signaling during the design.  It could be a new kind of "ICMP Route Redirect" message, or a new Preference field for Prefix Information options in Router Advertisement messages.
Tim Shepard:  There is a real traffic engineering question here.  Is this in scope of the research group?

Dow Street:  An alternative to address rewriting inside the network would be for the network to signal a set of possible prefixes to the host, and the host could select from those.



Lixia Zhang	APT:  A Practical Transit Mapping Service

[reference:  draft-jen-apt-00]

Elliot Lear:  Does a mapper return all mapping entries to an ingress tunnel router that requests a mapping?
Lixia:  No, only one single mapping.  If there is a failure at some point in the future, the tunnel router will request an alternative mapping.

Erik Nordmark:  The originator of mapping information must be able to provide proof that it can speak on behalf of the mapped edge network prefix.  This may require a different mechanism than secure BGP.

Dino Farinacci:  If you attach mapping information to BGP messages, then you will need to change the NRLI.  Otherwise, you might end up with namespace collisions because path attributes are associated with NRLIs.  This may require changes to all BGP routers.
Lixia:  This is a detail.  And as I said, using BGP for mapping distribution is just a first-cut, quick-and-dirty solution.
John Scudder:  BGP messages may get filtered, so this is an unreliable way of using BGP.  Better choose a different approach.

Dave Oran:  The end result of the mapping distribution would be that every router in every tier-1 provider would store the entire mapping table, right?
Lixia:  This is another detail.
Joel Halpern:  Do you have to distribute the whole mapping table?
Lixia:  Why not?  Every edge network can inject its own piece into the global mapping table.

Luigi Iannone:  We have netflow traces.  If you have software, we could run it on our traces.
Lixia:  Yes, we could use that.  We are only interested in the distribution, however.



Jim Griffioen:  Separating Routing and Forwarding

[reference:  ftp://ftpeng.cisco.com/tli/calgriffpout-final.pdf]

Joel Halpern:  What would be the ratio between header bits and payload bits?
Jim:  The headers of subsequent packets can be reduced after a first packet with a full header was sent.

Peter Lothberg:  Given that forwarding elements cache the information they get from policy servers, how do they learn if the policy changes?
Jim:  Through relatively short lifetimes.

Christian Vogt:  Only the hosts have real knowledge of end-to-end reachability.  How can they influence path selection?
Jim:  Currently the hosts query the route servers anyway.  Preferences of a host could be added on.

Iljitsch van Beijnum:  Your headers are very large compared to the size of the packets.  Do you have a rough estimate of the header size?
Jim:  We are currently working with channel IDs of 160 bytes length.
Iljitsch van Beijnum:  The ratio will be very bad if payloads are small such as in VoIP.
Jim:  VoIP sessions are long-lived flows.  You can reduce the size of packet headers after session establishment.

Sue Harris:  Regarding session lengths, you should look back on past research.
Jim:  Please send me the links if you have specific papers in mind.

Christian Vogt:  Can we re-use route information for multiple flows?
Jim:  We are still working on this.

Christian Vogt:  You are caching path information in routers.  Are you introducing a connection based approach?
Jim:  We used a fixed lifetime on how long you store the path information.  This lifetime is very short and it is refreshed by every packet of the flow.



Eliot Lear: NERD

[reference:  draft-lear-lisp-nerd-01]

Mark Handley:  We have been using peer-to-peer for the mapping database.

John Scudder:  How often will the mapping database get updated?
Eliot:  An edge network can update the database as often as it wants to, but the database only gets distributed at a limited rate.

Ilijitch von Beijnum:  For edge networks that multi-home, you need to know which of these connections are up.
Eliot:  This is a problem that LISP's reachability detection must take care of.



Dino Farinacci:  LISP Draft Changes

[reference:  draft-farinacci-lisp-01]

Iljitsch van Beijnum:  Does every multi-homed edge network need to run an ETR?
Dino:  Basically yes, but the edge network's provider may run the ETR on behalf of the edge network.

Christian Vogt:  Are the locators shown on slide 12 those of the party verifying reachability or of the party whoose reachability is being verified?
Dino:  Of the party being verified.
Christian Vogt:  How does one ITR know whether or not another ITR in the same edge network is reachable, so that it can set the reachability bits for that other ITR correctly?
Dino:  The information comes from the edge-network-internal routing protocol.

Mark Handley:  You are sending reachability information from one site's ITR to another site's ETR, and this info is in turn used by the latter site's ITR.  Is there a synchronization problem?
Dino:  You need to use an alternative path for the reachability information to get back to the latter site.
Mark Handley:  Are you assuming that the ETR and the ITR are the same box?
Dino:  It works better if both are in the same box.



Dino Farinacci:  LISP Implementation Report

[reference:  draft-farinacci-lisp-01]

Christian Vogt:  There is a transition problem with LISP in general.  To handle traffic with a multi-homed site, you need ingress and egress tunnel routers on both the multi-homed site and the correspondent site.  This means that a LISP-enabled multi-homed site can no longer be reached from a legacy correspondent site.  An early adopter of LISP therefore puts itself at a disadvantage, so why would anyone adopt LISP?  I don't see a way of introducing LISP incrementally, except by following the approach of Ivip:  You decouple the tunnelling function from the correspondent site and use anycast addresses to reach an ingress tunnel router.
Dino:  What if Google deployed LISP first?
Christian Vogt:  Then Google would no longer be reachable by the rest of the world and Yahoo would take over.

Brian Carpenter:  Right, the problem with LISP is that you have to get the traffic from a legacy correspondent site (which does not have its own ITR) to some ITR somehow.  You also have to figure out what incentives providers have to set up ITRs where customers can reach them.
Dino:  Do you know a business case for this?
Brian:  No.



Dave Meyer & Dino Farinacci:  LISP CONS

[reference:  draft-meyer-lisp-cons-01]

Joel Halpern:  The CONS model seems to imply that owners of EIDs become responsible for forwarding at the same time.  We lose some flexibility here.
Vince Fuller:  Yes and no.  The overlay you are using to forward a query is just a way of implementing the look-up database.

Darrel Lewis:  When a querying CAR performs a recursive look-up, it follows the topology in two directions.  This has some interesting security implications.

Mark Handley:  There is one fundamental question:  Can an ITR hold an entire mapping database, and will it have to?  It seems that it has to.



Luigi Iannone:  Cost of Mapping

[reference:  http://inl.info.ucl.ac.be/publications/locator-id-separation-study-cost-mappings-caching-and-mappings-lookups]

Mark Handley:  Are the short-lived flows that you have found in your traces just some sort of scans?
Luigi:  Don't know.  We observed a number of ingress flows that consisted of only a few packets.

Dino Farinacci [relating to Luigi's comparison to DNS]:  LISP-CONS uses per-site queries, while DNS uses per-host queries.



Tony Li:  Conclusions

Tony gives some recommendations on how to proceed working on the routing and addressing problem within the RRG:

- With today's PI prefixes, we use the regular routing infrastructure for reachability.  This will change with the introduction of an ID/locator split.  We need to make sure that people know that using PI prefixes will be different with an ID/locator split.

- A substantial part of the routing table growth is due to deaggregation.  We need to better understand the motivations for such deaggregation.

- We need more analysis on the proposals that we have at hand.

- We should continue to focus on the conceptual level, not on protocol details such as packet header formats, which are irrelevant at this stage.