RRG Meeting  Friday 8/1/08
(credits to Steven Blake and Benno Overeinder for taking the minutes)

Time	Speaker		    Topic	
9:00	Chairs		    Logistics, agenda bashing
Agenda approved

9:10	Joel Halpern	Some observations on Location and Identity
(Slides: http://www3.ietf.org/proceedings/08jul/slides/RRG-0.pdf)
In RRG email discussions, people use the terms ID, locator to mean a number of similar but different things. It is important to clarify our terminology.
An IP address names an IP interface; a PA address also names the provider of that interface.  When talking about identifiers, it is often vague on exactly what we try to identify.
  An IP address is for delivering packets, and should be allocated to fit
  the need of the forwarding system. 
  Transport layer protocols need identifiers that are independent from the
  paths taken by the data. If one can explicitly name the communicating
  entity, and exchange that name as part of the initial communication,
  things become cleaner.
Propose to untangle IP and transport
  - remove IP address from pseudo-header
LISP EID is still naming a location, a local address; it is not a clean identifier to build on.
This untangling of IP and transport will require changes to the host. Believe that we can still change hosts, and it is necessary in the long run to make a difference.

DISCUSSION:
> Louis Burness: agree with what being said. Question whether the separation
  between transport and network layer is the right place; or the identifier
  would belong to the application layer?  But to address DoS mitigation,
  one considers control at network layer.
> Joel: the main point is to get an ID to anchor communication that is
  separate from the IP address.  There exist multiple valid ways.
> Jari Arkko: agree with almost everything. One observation: if you have
  this sort of separation (and use a global locator as today's IP address),
  an implication is seeing the effects of renumbering in local networks,
  may not get all of the benefits of some other proposals.
> Joel: has implications for the visibility of renumbering; having a real ID
  should make renumbering easier (but not totally solved). It also means you
  may also want to consider local addresses to avoid renumbering; yet to
  walk down that tree.  Valid to say renumbering is a pain, make it easy
  or not needed - decide on one way or the other.
> Jari: works has been done along similar direction, e.g. shim6 & HIP, which
  are yet to be deployed.  What is the incentive model to get this change?
> Joel: there are relationships; in particular HIP can be a way to implement
  what I proposed. But 2-3 things that are relevant yet different. We need to get a clean architecture picture and work with various parts of the community to make this happen.  Shim6 was useful for raising issues but doesn't quite get us where we want. If we don't act, sooner or later someone else will.
> Marshall (from Jabber by John): what would it look like to have one
  locator for identify multiple processes on multiple machines?
> Joel: that is done today. You very often send to a thing that is physically
  distributed. between locator and ID: allow many to many mapping.
> Christian Vogt: two supporting comments.  First, relates to reason why
  identifier conflates with locator, which originally was secure binding.
  Need this and it is not trivial.  Made sense when hosts were fixed.
> Joel: binding isn't secure today; any solution has to address the security.
  Don't think they are any more difficult to secure than any of our other
  security problems.
> Christian: Second, do we need a new ID/Locator split?  i.e. between
  hostname and address. ILNP proposes applications use only hostnames, I
  suggest pushing hostname all the way down between transport-network layer.
> Joel: possible that the domain name space can serve as a secure ID space.
  Personal guess is that you want a fixed size binary space. DNS names have
  the properties we want.
> Christian: could convert an arbitrary size hostname name to a fixed size
  ID. host name is already there, may as well make use of it. Just an idea.
> Dmitri: should RRG focus on locator/ID space (as you defined), or the
  global-local space?  Can we modularize the problems?
> Joel: question of what piece of this is appropriate to do. Example: We
  already provided a scalable routing solution - use aggregatable addresses,
  done.  But this didn't work because of the way the system behaves. We are
  dealing with a system, not just the routing piece.  We need to solve the
  the routing problem in the context of an overall solution.
> Dmitri: should we concentrate on the global problem and wait on the routing
  solution.
> Lixia Zhang: good questions.  Need to agree on the big picture first: how
  many piece out there, and what are the inter-relations.
  Support Joel's talk 100%. Very important to clarify these basic concepts.
> Ruediger Volk: do we understand the resistance to changing host stacks?
  An even bigger problem is changing the middle boxes.
> Christian Vogt: why would you have to change the middle boxes.
> Ruediger: firewalls like to match on fields like addresses; assume certain
  semantics.  Firewalls are one of the reasons we are afraid of renumbering.
> Brian Carpenter: known for years that firewalls are a wart on the
  architecture.  Have to solve this or firewalls will block deployment.
  Change may have to reengineer every firewall.
> Joel: (1)if we can't make any changes, then we can all go home.
  (2)Most firewall haven't had IPv6 implemented.  We have time to help 
  them do it right. Should access control be on ID or location?  I believe
  probably location, making the problem simpler. May be advantages to tying
  ourselves to IPv6. It's a lever that people have to do but haven't done.
> Brian: can't block ourselves on the fear of change; have to accept that
  changes going in for IPv6 based on RFC 2460 (due to government), going in as we speak.
> Marcelo Bagnulo: Firewalls/ACLs will work on ID or locator? probably on
  locator. In this case, how is this useful to reduce the renumbering pain?
> Joel: if we separate that what you have to change and when will be
  easier.  Can't change firewall to work on IDs now.
> Marcelo: firewalls should be able to work on IDs.
> Jari: host changes, discussion assumes that this is a binary decision; in
  reality shim6 and HIP have been able to do this in a backwards compatible
  fashion; can work with existing hosts and firewalls.  Not that hard to do
  that.
> ?: there are IPv6 firewalls; being introduced now.
---------------------

10:10	Mark Handley	Multipath  Transport, Resource Pooling, and
                        implication for Routing
(Slides: http://www.ietf.org/proceedings/08jul/slides/RRG-2.pdf)
A different version was presented at transport meeting earlier. 
Where should be the boundaries between different forms of control in today's Internet?  If one looks the control architecture of Internet, the control part is congestion control and routing. Today focuses on multipath transport.
Things that stress routing include
  - scalability (due to natural growth)
  - multihoming
  - increasing demand for fast recovery from failures
  - resilience to flash crowds
  - 4 billion cellphones with multiple radios that can be used simultaneously
Make an assertion (no real evidence but gut feeling): can't make routing scale and do all the following in the routing system:
  - multihoming
  - fast recovery
  - short-timescale TE
  - mobility
Can only do a few things in the routing system and the rest solved elsewhere.
Resource pooling: make a network's resource behave like a single pooled resource, to increase reliability, flexibility and efficiency, by shifting load among various parts.
Everyone reinvents resource pooling for specific problem; not interact well.
Resource pooling in routing:
  - BGP TE
  - OSPF/MPLS TE: Primary goal: Robustness-prevent overload;
    secondary: high utilization
  - BT, AT&T dynamic alternative routing
Recent resource pooling:
 - Multihoming: pool reliability and capacity
 - Google, Akamai, CDNS
 - BitTorrent: pool upstream capacity (over space and time)
Current 2 main ways of resource pooling, that fight each other
  - routing based TE: not a great control loop
  - Application-based load balancing between servers
What might work?
  - Multipath: only way to get real robustness is redundancy
  - Multihoming, via multiple addresses (if hide multihoming beyond a single
    address, don't have an easy way to move things around; other ways to identify a path can also work)
  - Mobility, via adding and removing addresses (no need to involve the
    routing system, or use non-aggregatable addresses)
Multipath transport layer: one can use multiple subflows for the same transport connection, move traffic to less congested paths
  - so far congestion control only spreads load over time
  - multipath transport spreads load over paths! Approximate load-dependent
    "routing" by the transport layer.
  - Theory results show that this works even when multiple paths share
    the same congested link.

> Dow Street: is it fair to say that you can translate the additional
  capacity into robustness by sending same data along multiple paths?
> Mark: yes, but that's not the main thing I'm after. Maybe one would send
  TCP syn along multiple paths, but most apps don't care robustness to that
  degree all the time.  For apps with unconventional requirements, sending
  over multiple paths may fit, though with associated cost. Already send
  multiple copies of VoIP traffic, so can just send over multiple path.
> Dino Farinacci: does the source control the path ten hops downstream?
> Mark: trying to sketch out a design space; multiple ways to allow the host
  to be involved in path selection.  Today talking about path selection by
  address, works with multihomed sites.
> Dino: get more benefits by IGP after the packets leave the site. Seen this
  before, eventually reach a common path.
> Mark: transport protocols have capacity measure built in, can adapt over
  short time scale to changing load. Can get better resource pooling if you
  also involve the routing system, but not necessary. A theory paper on
  Power of two choices: randomly choose the least-loaded server gives good
  load balancing.  An open question is whether you will get sufficient
  pooling with just two paths.

Resource pooling gives you the ability to accommodate a wider range of traffic matrices and do it over very short time scale.  Tradeoff between utilization and flexibility.
Multipath transport gives TE for free.  Operators can influence transport path selection by adding congestion marking (ECN) on packets on more expensive links to balance cost. You can't do this with single path transport.

> Dino: seems that the multipath is controlled by the source; feel there
  can be a hierarchy of control, e.g. some control knob by routing layer.
> Mark: use transport for short time scale control, routing system for
  longer time scale; don't want to use routing system to move traffic
  around in short time scale.

End systems can optimize globally (that ISPs often cannot).  Routing system doesn't have the degrees of freedom transport can see (example: slide 16).
Resource pooling principle:
  - Observation 1: often only practical way to achieve resilience at
    acceptable cost
  - Observation 2: cost-effective way to achieve flexibility and high
    utilization
  Consequence: at every place in a network architecture where sufficient
  diversity of resources is available, designers will attempt to design their
  own resource pooling mechanisms
  Principle: can judge network architectures by how well they enable resource
    pooling, effective and don't fight each other
Corollary: most effective way to do resource pooling is to harness the responsiveness of the end systems in the most generic way possible, as this maximizes the benefits while minimizing the conflicts.

Multipath TCP: been proposed at least five times before; understand the benefits better now, the consequences of not solving the issue right.
- Multi-server HTTP: request chunks of a file, each from a different server;
  better pooling, but less general.
- Multipath Routing for resource pooling: only if 
  - router can make a choice (at flow granularity) of more than one path
    to the same destination
  - load-balancing between path based on the measured congestion (maybe
    via a tunnel architecture). 
  - same effect as moving traffic away from congested paths.
    - harder to make stable
    - doesn't provide resilient for individual flows.

> Oran: you said that load balancing doesn't help for particular flows
  because we don't do per-packet l.b. due to re-ordering. If we are going to
  revisit TCP, shouldn't we revisit this also?
> Mark: no need to change TPC; only a standard way to know which packet
  follows which path, need path ID in packet header.  This requires change of IP, can bring more flexibility.
> Iljitsch: disagree, papers out there showing we know how to handle 
  re-ordering, so we can do per packet load-balancing
> Mark: know how to do it, never done it, but don't get resource pooling
  benefits unless congestion control can see that packets take different paths.
> Magnulo: stability requires lower response times; per-flow can be faster
  than aggregates.
> Dow: if doing it in the routing system; implied that routers are making the
  path decision, instead of hosts making decision but still at IP layer.
> Mark: source routing is one option; DSCP; many possible solution;
  but they seem unlikely to get deployed. The key point is congestion
  control should know which packet sent which way. How to make sure packet
  go different paths is a good design space question. For simplicity this
  talk assumes address determines paths.
> Lixia: respond to Iljitsch - not whether we can solve a problem, but 
  what is the best case to handle the issue; transport is the right place.
> Stuart: very concerned; looking at doing 100 Gbps, very scared about
  renumbering.
> Mark: know how to do per-flow load-balancing in the network.  Ability to do
  loose source routing by transport seems a middle ground.  But the long
  history of loose source routing is not that great.
> Dino: single vs. multiple addresses; single address goes a long way,
  especially with default route to single exit, if you take full routes to 
  the host then multiple addresses make sense.
> Mark: don't care about shortest path; care least congested paths.
> Dino: can get most of the way there with single addresses, help keep
  things simple; not convince one needs multiple addresses, unless you
  want to control ingress path.
> Stuart: many mechanism besides congestion; may care about latency, or least
  variation.
> Mark: really care about least congestion. Really application decision.

Assume a world where most flows are multi-path
  - greatly reduced need for TE
  - in principle can use aggregated PA addresses for routing with multi-homed edge sites.
  - one issue with PA address is failure detection, since address aggregated.
    But not a problem with multipath transport, data can be retransmitted
    over other paths in one RTT.

> Stuart: no such thing as never, maybe BGP fast re-route can be even
  faster (e.g. within 50msec)
> Mark: BGP can never be as fast as transport.

For legacy end systems, failure recovery is more problematic
  - can restart a connection using a different address from DNS
  - tunneling from one ISP to other is feasible, but ugly
  - 8+8 would make this easy

> Dino: why do you assume that you can't have 8+8?
> Mark: 8+8 has lots benefits. But with aggregated routing announcements,
  when a link fails, one may announce a more specific route, works but
  destroys scalability. Other solutions exist.

Directed BGP updates: do it only after a failure, and only in local scope. Have not worked out details yet.
- IPv4 is probably a lost cause for PA addresses; don't have the aggregation.
- for IPv6, everyone wants PI addresses anyway (no one wants to renumber)
-  but mobile hosts have to renumber anyway
- for non-mobile hosts, if PI addresses are really needed, one-to-one
  address writing to a PA address is probably the way to go; take stress
  out of the routing system
Summarizing:
  - multipath transport can deliver resource pooling; closest thing to
    load-dependent routing that is likely to scale and be stable
  - people will attempt to build resource pooling anyway
    - such solutions may conflict
    - multipath transport minimizes bad interactions between such solutions
  - need to think critically about division of control functionality, what's
    done by routing and what's by end hosts.
  - what is role of routing and network-based traffic engineering?

DISCUSSION:
> Dmitri: is it not exacerbating the problem of advertising more addresses?
> Mark: want them to be PA
> Christian: one good reason for multipath transport is security, if you
  do it at transport then the security problems are smaller: shorter life
  time, less data exchanged.
> Mark: there are both wins and losses. Hard to say there are great security
  benefits at transport layer; just different. But none of them is show-stopper.
> Brian: Q1-you mentioned stability, not believe you can prove that multiple
  sessions are stable.
> Mark: should read the best paper on transport stability:  http://www.cs.ucl.ac.uk/staff/m.handley/papers/resource-pooling-principle.pdf
> Brian: Q2 - assuming what we see today remains true, most streaming uses
  TCP, has anyone looked at the impact of this on TCP congestion management?
  and on multipath TCP congestion management?  multipath changes the
  conventional understanding on why or how one does congestion control.
> Mark: if IPTV becomes ubiquitous, it may change.  Big advantages for
  multipath for realtime applications, but looking for a combination of
  low-delay and least congestion.  Choosing low-delay is unstable, don't
  know how that will behave with TCP.  Youtube assuming that capacity is
  greater than what they are trying to transport.  RealPlayer can do
  low-timescale congestion control.
  People using TCP are doing file transfer.  If you use TCP for realtime,
  don't use the whole congestion window.  If application has less BW than
  available via multipath, then you have an interesting choice to make.
  The basic constraint is to send data over each path to get congestion
  control clock going. Beyond that, do you really want to load-balance
  proportional to congestion windows?  The theory only explored heavy
  traffic case; more research needed here.
  Almost none of the ideas here are mine.  Just trying to advocate
> Dow: flag of concern about using multipath transport, that you would have
  to have physical multihoming to benefit, but maybe that is not the case.  Can you achieve this over a single link, by provider giving you multiple addresses?
> Mark: would work, not sure how this would impact the routing system. 
  Design space is to let us choose different things than paths.  Address is the easiest way to do, not the only way.
> Dow: service providers might recognize that they don't have control
  over this anyway.  Need to be more explicit about this control tussle.
> Mark: can see my neighbors wi-fi's, could work out multihoming with my
  neighbors.
> Lixia: heard many benefits, but how will it work with multipath?
> Mark: right now multipath transport is a niche solution in edge networks
  (wish it wasn't). If it became ubiquitous, then would be a problem.
> Dino: use replicated unicast if that would scale.
---------------------

11:10	Dino Farinacci	LISP for Multicast Environments
(Slides: http://www3.ietf.org/proceedings/08jul/slides/RRG-3.pdf)
How to run inter-domain multicast over LISP
- Want unicast and multicast to be consistent
- No head-end replication at source site
- Packets only go to receiver sites
- No changes to hosts, site routers, core routers
- use existing protocols (but need some simple changes to PIM to make it work)
- support PIM SSM, don't preclude ASM & Bidir
- Have separate unicast and multicast policies
- (S-EID, G), key to look up mcast routing table
   - S-EID is source host, G is group
   - state resides in source and receiver sites
- (S-RLOC, G): state in the core; S-RLOC=source site ITR
- uLISP site: support unicast LISP only
- LISP multicast: supports both
- Multicast ETRs at receiver sites
  - sends unicast PIM JP (S-EID, G) to ITR S-RLOC address
  - sends regular PIM JP (S-RLOC, G) through core, build tree branch
    from ETR to ITR
  - decapsulates multicast (S-RLOC, G) into (S-EID, G)
- Multicast ITRs
  - encapsulates (S-EID, G) packets into (S-RLOC, G)
- Multicast proxy tunnel routers (m-PTRs)
- Gives example

Aggregated tree; don't need state in the core from all hosts in a source site.  May not have precise replication because we are using aggregated trees.

> Maria ?: is it that you don't want to solve this problem; it is solvable in
  the forwarding plane
> Dino: you are right, need more data to see if the trees will be sparse

- Join policy: one exit, one entrance
- Introduced M-priority to map-reply
- Locator reachability used for both unicast and multicast
- Mapping entries contain all locators
- Can turn off using priority 255
- LISP multicast interworking (between LISP and non-LISP sites)
- Multicast at receiver site
  - would require another mapping table; operationally a non-starter
  - mPTRs

> Marshall Eubanks: traditionally, my TV (first hop router) joins (S,G).
  I'm on a website and I want to get your TV transmission: am I seeing your
  S-EID?
> Dino: yes, only xTRs see S-RLOCs
> Marshall: then S-EID needs to be globally unique (not net-10)
> Christian: it is up to site if it has on PI or multiple PA; wouldn't the
  site be translating to the same S-EID anyway
> Dino: in non-LISP site, and to do PIM control plane NAT function
> Christian: that would happen automatically
> Dino: if you misconfigure a non-LISP multicast site, ..., do you now have a 
  protocol that pushes the translation.  Advantage with unicast is that you
  can configure it in one place.

- Don't want to implement head-end replication
- mPTRs decapsulate and deliver to non-LISP sites
- Goes over case studies
- Further simplification: make all sites that deploy LISP be unicast and
  multicast

> Marshall: (Q on slide 30) Best solution is to employ unicast and multicast
  LISP at the same time.  Do they have to support traditional multicast also?
> Dino: only on the inside.

- Best possible outcome: (S-RLOC, G) state in the core only.
  (may have missed his point).
- Don't know if we want to co-locate mPTRs and xTRs.

DISCUSSION:
> Tony Li: in hybrid case, you are injected EID prefixes into global routing.
  how is it different from the normal prefix a site would have
> Dino: also a unicast problem (with PTR).
> Tony: how do you withdraw those prefixes before everyone has deployed
  LISP to help routing?
> Dino: when a site adds LISP, those prefixes are removed from the PTR
> Tony: didn't hybrid case imply that non-LISP site cannot reach a LISP site.
        LISP site had to inject prefix.  As long as there is one non-LISP
        site on the net; everyone has to inject his route.
> Dino: right
> Jari: taking the same idea (of LISP) and extending it to multicast; could
        possibility do the same for mobility.
> Dino: have to because multicast depends on unicast routing
> Jari: for future organization of this meeting, might want to focus on how
        to solve the unicast PTR problem rather than looking at multicast or
        mobility (before solving unicast problem).
        Want a place to discuss the unicast question.

--------------- 11:40 - 13:10 Lunch Break ---------------

13:10	Lixia Zhang  	Routing Scalability: Separation versus Elimination
(Slides: http://www3.ietf.org/proceedings/08jul/slides/RRG-5.pdf)
Goal of this presentation: contributing to RRG design convergence
- understanding design space by carefully studying all proposals
- identifying commonalities and differences at the highest branching points
- Solicit consensus on direction to march forward
Ð Articulate an overall task list (for later discussion)

Define scalable routing: not defined by any specific ceiling, but the ability to control the scale of routing system.
- Allowing the global transit core to route on aggregatable prefixes only.
- Two ways to get there: separation versus elimination

Separation: separation of edge prefixes from transit core (APT, IVIP,
LISP, Six/One)

Elimination: eliminate non-aggregated prefixes (PIs, de-aggregated PAs) entirely, i.e. push multiple PA addresses all the way into hosts of
multihomed sites (SHIM6, multipath transport, ILNP)

If separation
- hard part is mapping system design.
- Need to develop effective detection and recovery mechanism for failures
  occurring between the core and edge networks
- Need an incremental deployment plan.

If elimination
- new work on handling of multiple addresses by host/transport
- host changes
- site renumbering when changing providers.

Which way to go:
- Renumbering is considered by some people a non-starter.
>ÊThomas Narten repeats this viewpoint at the microphone. 
- host can/not be change?
- the only sure answer: future is uncertain.

If we choose to go done elimination direction:
- multipath transport will solve the hard problem
- but if we guessed wrong... we could face a routing scalability crisis.

If we choose separation,
- if choose wrong... we would have wasted all the hard work (worst case).
- if we choose right: we solve a decades long problem.

> Marshall Eubanks: Is decoupling real? ÊIf we have foo and UCLA has foo,
  this requires coordination. ÊBut with coordinating, you haven't any gain?
> Lixia: yes the ends need coordination; the encapsulation bridges the ends
  without needing manually configured tunnels.
> Thomas Narten: does separation eliminate NAT? Can you give an example?
> Lixia: if consider bridging v4-v6: encapsulating one in the other can be
  part of a separation architecture.
> Thomas: Is there anything that cannot be done today that this solves?
> Jari: There is nothing special about this. Just that if for routing
  scalability reason, one needs to employ such encapsulation, then one may be able to bundle the ability of translation between v4-v6 with this.
> Brim: [the only reason this is special is that if you have separation
  infrastructure already, you already have the machinery to play with
  interconnecting islands of experimental protocols]
> Joel: today ISPs can already filter out packets addressed to their routers
  if they want to (but many do not).  What is new here?
> Jari: during the (long) transition period, you don't have this benefit.
> Lixia: correct; this talks eventual benefit.

Separation can provide routing scalability benefits
- while multipath transport getting ready over time. 
- without depending on all/majority edge sites adopting PA addresses with
  a given time frame (if ever).

> Tony: seems you'd have a hard time separating while keeping
  interoperability. Êe.g. if 4 sites doing separation, they still have
  to advertize their prefixes into the core, so you don't seem to have
  any benefit until every converted.
> Lixia: this is one of the hard problems mentioned earlier, incremental
  deployment, i.e. can I (as an ISP) solve my own routing scalability
  problem when I need to?  These are still part of research. But today's
  question really is: should we try to solve this problem? 
> Tony: Can we get to a point where we can truly separate while one site has
  not transitioned yet, but still have the benefit?
> Lixia: We agree on the problem
> Brim: We agree on the problem, we still working on it, but that does
  not mean we should stop now just because we don't have the answer yet.
> Thomas Narten: you seem to beg the community to try, as if we were all
  opposed. Do people not think we should go in this direction? 
> Lixia: yes, the mailing list shows different views here.
> Philip: Isn't it the case that if some edges adopt multipath transport,
  then you get some benefit?Ê Is it not a linear benefit?
> Lixia: the definition of scalability is that I want to control the size.
  If 80% of edges have not changed to PA, I don't really have the control.
> Steven Blake: NAT as a solution
> Brim: Does not see the benefit as linear with the percentage of adopted
  edges, you still need to propagate the non-aggregated prefixes.
> Dino: (to Tony) partial deployment of separation does bring benefit;
  used LISP as an example to explain.
> Louise Burness: If a site choose to go LISP, but the benefit goes to the
  core routing system?  Wouldn't this be a mismatch between cost and benefit?
> Dino: The sites get the benefits, better multihoming support.
> Lixia: This talk is opening discussion about whether separation should be
  pursued, if so we will examine all the proposals and address the issue
  of benefit-cost alignment.
> Jari: go one level up: What are we doing here?ÊAsking what we should
  investigate? ÊDo we need to look at both separation and elimination?

We are mindful of the cost and open issues with separation.
We can and should combine separation with multipath transport (presentation of mark) to get both benefits.

Mobility: support 10 billion flying toasters. People hold different views regarding whether mobility support should/not be combined with the mapping service in separation design, so we should keep investigating.

Putting all pieces together: what are the tasks
- need to first figure out tasks, then who owns what
- develop a separation solution
- multipath transport progressing in parallel
- clarifying name space: as well stated in Joel's talk, untangle
  identifiers from IP addresses
  Who is working on the identifier piece? ÊNeed the overall framework
- Reach consensus, start drafting working plan

DISCUSSION:
> Vogt: Two comments. ÊCombining the two approaches is a really good idea.
  Second, not fully orthogonal, there are architectural dependencies.
  Separation provides 2 goals: independence (from provider), and a single
  prefix inside.  But wouldn't the combination cancel the single prefix
  benefit?
> Iljitsch: We need to look how loc-id separation interacts with multipath
  transport.
> Lixia: all multipath transport needs is a set of addresses to play with,
  supposedly one for each of its providers. So a site can divide its PI block
  into sub-blocks, one corresponds to each of its ISP. When the site changes
  an ISP, it just needs to change the mapping (of the sub-PI-block to the
  ETRs of the new ISP).
> Dino: There are alternative ways to achieve the same. If it's costly to
  assign multiple address to each host, can do LISP encapsulation at host
  as another way to support multipath transport with separation.
---------------------

14:10	Steve Blake	    An Overview of ILNP
(Slides: http://www3.ietf.org/proceedings/08jul/slides/RRG-4.pdf)
Giving the talk on behalf of Ran Atkinson
Thoughts on a new namespace, many ideas are from previous work.
Claim: Richer set of namespaces -> better support for many functionality.
Effects of API: 
- BSD socket API still use IP addresses
- Java programmers use DNS APIs (Apple starts supporting this too), move
  towards connectivity independent application protocol design.
This talk focuses on how adding network layer host identifiers can help solve some parts of the architecture gap.

Routing RG Issues:
- scalability
- multi-homing 
- mobility

> Iljitsch: we have ~30K ASes, quarter million prefixes, ~30K multihomed
  ASes can't be responsible for quarter million prefixes; there must be
  something else going on
  (editor's notes: many edge ASes announce multiple prefixes, perhaps due
   to legacy allocations and TEs)

Each multihomed site announces more specific prefixes to DFZ, because transport protocol header checksum includes IP addresses. So the fix is to de-couple transport protocol from network location.

Mobility is just highly dynamic multihoming, want transport session stays up while moving. Again the fix is to de-couple transport sessions from network locations.

Controversial statement: Internet routing architecture is just fine, but we
are (ab)using routing to work around limitations in the Internet's
naming architecture.ÊIf we can solve the naming architecture, existing routing protocols and techniques will be fine and don't need
to change.

ILNP: An 8+8 approach--using the high order half of IPv6 address as locator, the low-order half as identifier.
- transport state contains only identifier (a slight overstatement...)

ILNPv6: A set of enhancements to IPv6
A bit more detail, each node can have one or more IDs; a node can be a single machine, a virtual machine, or a dist. system.
Naming comparison, ILNP: Transport layer changes, ...
Implications
- can multihoming without impacting routing
- mobility becomes a built-in capability
  but need a way to tell correspondent where we move--use DNS
ILNP depends on DNS enhancements.
DNS will have separate RRs for ID and Locator, each with difference TTL value.  Also add a "locator pointer" RR, to facilitate subnet moves.
Each of these RRs can have a preference value.
One node finds out whether the remove one supports ILNP from DNS replies (whether reply has L+I RRs), if not, do conventional IPv6 handling.
Should use DNS names for referrals among applications.

> Oran: how to handle app's (e.g. BitTorrent) that hand IP address around?
> Steve: need to change the API to receive benefits of ILNP, to change DNS
> Thomas Narten: so source really means apps here.
> Steve: move DNS further down the stack, to the kernel
> Iljitsch: identifiers are not necessarily unique?  How to handle that?

Handling mobility: MIP has IP addresses retain dual role, ILNP separates
the two. Locators handle the move, while keep constant ID for upper layers.
Use ICNP locator change notification.
If two ends move at same time, fall back to DNS

> Thomas: the fun is always how to do mapping--Is DNS fast enough?
> Steve: Locator RR has TTL=0, not cached
> Christian: Did they use DNS as rendezvous server for quick updates?
> Thomas: in practice, people do cache, even ttl=0.

Should focus on concept first, how to construct a system this way. Engineering details later.
> Vogt: Christian: Rendezvous is outsourced, DNS is used to access
  the rendezvous server (?)

Primarily use ICNP to notify moves between 2 ends, only fall back to DNS.
Update DNS for potential new correspondents.

Slide on mobility implementation.
Support for both host and site multihoming
NAT integration: ILNP falls into "elimination" which invokes renumbering.
If doing translation, avoid renumbering

> Iljitsch: if you only translate the top 8 bytes, works, but what
  if translate the whole 16-bytes?
> Thomas: really a specialized NAT
> Lixia: is this a separation approach with DNS as mapping service?
  but you require a globally unique ID (that separation scheme does not require).

Operations considerations
no changes to IPv6 routing, forwarding
require changes to host stack in fundamental ways
Backward compatibility:
- use DNS to detect remote nodes capability
- fall back to ordinary IPv6 if either node not ILNP
No free lunch
- no network interface names
- a few legacy apps may be problematic, especially those use address
  for referrals.
- DNS reliance not new, but more explicit: DNS failure= network down

Summary: treat IP address as consisting separate ID and locator, this enables native mobility, multihoming

> Sheperd: does DNS have to run over an island not ILNPv6?
> Steve: DNS servers have to run in a island that does not move
> Lixia: the so-called native mobility support is just by moving the 
  rendezvous function from home agent (MIP) to DNS?
> Steve: yes. but one big difference here is that the rendezvous point
  does not forward packets as home agents do
> Lixia: without NAT, ILNP requires renumbering.
  With NAT (to avoid renumbering), then ILNP requires a new management system for managing a name space of unique node identifiers.
> Christian: ILNP seems a package of several useful pieces:
  (1) name-based API
  (2) a new type of DNS which makes renumbering simpler,
  (3) the split of locator and identifier. Q: to support mobility one must make the identifier part globally unique--this can be hard to enforce.
  e.g. today MAC address is not unique.
> Answer: There is no need for global uniqueness.ÊIf generated from MAC
  address highly probably to be unique, but if you generate a packet,
  the ID plus the locator will be unique, and can bind that to the domain
  name, such that the transport layer can do the right thing.
> Christian: Then this is quite similar to Six/One, there exists a
  coupling between locator and ID. One difference is what to expose to apps.
> Steve: ID unique within a set of locators--Steve's version of ILNP.
  You want apps to use DNS.
> Iljitsch: Uniqueness of identifiers 
  -> do look up together with locator to get fqdn
  -> if you loose the fqdn in processing -> loose all the benefits
  -> back to single loc/id pair.
  If you don't make this 64 bit unique -> not a real ID? Need be careful here.
  Need to push for DNS usage.
> Steve: use (ID, locator) for reverse lookup to get fqdn.
> Lixia: Promoting the use of names for apps is the thing we should push.
  But the mobility support can be doe with dynamic DNS (orthogonal to ILNP?)
 ÊA separate solution to mobility?
  If fast DNS you can use just with IP... just rendezvous mechanism is required here.
> Thomas Narten: what if a spoofer intentionally cause ID collisions? 
  have a way to deal with that?
> Steve: Global uniqueness of loc/id, use this in session (metadata)
  to make unique.
> Thomas: No free lunch -> legacy apps stay problematic;
  need multiple DNS lookups (I, L queries).

Lixia: The whole thing interesting -> can we take the thing apart and
look which components can be applied now or start to work on it.
e.g. changing socket call to use DNS names will take decades for a wide rollout, but if we start today, we get closer to the end. ÊLets try to start working on parts and proceed without breaking things.
Difference parts of the idea can be borrowed and used in overall solution.

> Brian Dickson: Convenience library to facility the use of sockets.
Done that, been there, ...

> Iljitsch: app referrals are encoded in fixed fields --> problem is that
  protocols have to be changed, not just implementations.
  Separate this address from the applications in protocols (in the IETF).
> Answer: Similar like HIP, one has to translate HIP (address-like) also
  separately.
> Vogt: Now translation between application and transport layer, we
  would like to have split between transport layer and IP (level 3) layer.
  It would be nice to make it backward compatible to transport layer
  (just like HIP), but should be doable.

---------------------  15:30 - 15:45 Break  ---------------------

15:45	K. Sriram    Architectural Considerations for Mapping Distribution 
                     Protocols
(Slides: http://www3.ietf.org/proceedings/08jul/slides/RRG-1.pdf)
Pros & Cons of three approaches to ID/LOC split.

> Lixia: What seen so far is assumption how should be aggregated.
 ÊThis seems an analysis of the proposals on the table, not a taxonomy of
  solution space; Other approaches do not need EID space aggregation, and are not discussed here.
> Christian: isn't this (EID aggregation) an optimization for any mapping
  system? I think this is applicable as an optimization to any of the solutions.  
> Lixia: take NERD as a counter example: it does not require the EID
  aggregation.
> Sriram: The method is not newly proposing EID aggregation but is meant
  to deal efficiently with exceptions in the aggregation. 
> Luigi: What is the complexity of such system (number of exceptions
  and how to manage)?

Exceptions is another form of de-aggregation -> better have aggregation
with many exceptions, rather than de-aggregation with less exceptions
-> where is the sweet-spot?

Answer of Sriram: About 5 times more entries (first question). ÊThe
sweet-spot is having one /20 with a few exceptions rather than a list of many /24s; this should be quantified by real data.

What if the size increase with factor 10? ÊThere are multiple spots
where you can aggregate in the network (answer by Lixia).

> Dimitri: The number of exceptions in the system?
> Answer: Limited number of exceptions (10 or 12) not 200 exceptions.
  If there are many pieces, then there is no point in aggregations (counting the exceptions). ÊAnd there are other issues to think of.
> Iljitsch: We should be careful, handing out parts of ID space, rather 
  splitting and announcing a /22 with exceptions, announce the /23 and the other parts not any more (as you do not own them other). I want to contact a specific address, so why should I be bothered with a /22 block with exceptions. 
> Sriram: It is a balance between cache hit and overloading the cache? 
  If you do provide a /16 and are prepared for exception handling rather than provide lots of more specifics, you optimize for cache hits.
> Iljitsch: You opt for cache hits not for cache size (you put more in
  the cache).
> Marshall: Provide routing which is less work/storage than BGP.
  Correct? (Answer: Yes)
  Even small, you get millions everyday, you do not check all the paths... but in this system, with every hit you check what will happen. ÊWhat is the implication for scalability? ÊYou do the some extra work/overhead. ÊSee the same amount of effort.
> Sriram: If a /8 is well aggregated except for for some exceptions, you
  check, and you have great benefit in treating the exceptions efficiently; you would not want to break up the /8 into many /24s just because of a few exceptions, etc. Something (quantitative analysis based on data) still to do (look into).
> Lixia: a PI block can be geo independent (like IBM, big companies).
  A big company, with a big PI block, can spread over multiple continents, 
  If existing blocks get more and more de-aggregated, what could you do to aggregate the fragments?
> Sriram: Will look into this for further quantification with realistic
  data.

-------------

Presentation by Brian Dickson
(Slides: http://www.ietf.org/proceedings/08jul/slides/RRG-6.pdf)
Back on the envelope presentation.
Allocation address on a geographical basis. ÊIt is the address
allocation policy that matters.

There are a lot of ISPs which are multihomed. ÊWhat tools are
available to analyse: quantifying de-aggregation.

Policy follows reachability fate-sharing.
The more distant, the less paths you will see for prefixes
(matter of economics).

> Joel Halpern: can achieveÊbetter aggregation if you renumber...
  but if you do this depending on the aggregation of the upstreams.
> Answer: Not by the upstreams, but from a remote perspective.ÊIt is
  opportunistic and statistical. (?)
> Joel: Does not believe is practicable, but love to hear.

Aggregation not on next hop basis, but can do it on longer time scale
from longer distance/perspective.

> Marshall: Multihoming in Ireland, how does it aggregate (how do I
  interface two big guys)?
> Answer: Not only geographically but also on topological basis
  aggregation.
> Tim Shepard: It is not the case if you go further away, different
  IP prefixes are more aggregated as more close by the source.
> ?: Is this is some kind of mapping table compression through statistical
  means?  If so, the mapping table has to be deterministic because missing entries would mean black-holing traffic to some destinations.


-------------

16:30	Chairs		    Summary, Directed Discussion, Open Discussion

> Doug Montgomery: Question related with SriramÕs presentation to Lixia:
  Assuming the method is made available and shown to work, then apart from saying you do not do aggregation as part of your solution, do you think other proposals cannot benefit from this work?

> Lixia: Do we have consensus in this group about the the tasks in 
  (Lixia's) presentation: ÊFirst agree on the high level points?
> Tony: disagree 
> Lixia: smile
> Joel: do we see that there are different proposals that can benefit
  for Srirams' proposal?

> Joel: Is not comfortable with separation, but won't say we shouldn't
  do it.
> Tony Li: By default we work on everything; what have we eliminated?
> Iljitsch: Either RRG or IETF: traffic engineering or aggregation?
> Lixia: This work should be done RRG or IETF, not necessarily all in RRG.

> Tony: We should look what work and will not work, and weed out what
  does not work.
  Do we have consensus what will not work?
>ÊJoel: No!
  There is not sufficient weeded out.
> Tony: Separation won't work. we haven't seen it work.
> Lixia: Believe RRG should work on separation solution, not been
  studied sufficient.ÊOpen issues from a specific prototype implementation (LISP) is not any proof that the whole separation direction does not work.
> Dimitri: What is the conceptual framework where talk about.
 ÊIs it a document? Ê(See Lixia's last slide)
> Dimitri tries to understand what Lixia tries to propose.

> Brian Dickson: Many proposals. ÊWhat are the common requirements,
  where does it result in -> incremental deployment,
  what goes wrong if, ... -> set of requirements
  Not input requirements, but output requirements, and do we agree on the requirements. Ê(Observations, solutions, suitable for discussion.)
> Lixia: Discussion is always good; discussion so far is yet to reach
  consensus; people have different opinions.
> Thomas Narten: Sees the urge of the RRG to decide.ÊHowever there must
  be an incentive for people to work on, and to get it deployed.
 ÊWait until there is a fairly complete design.
 ÊNext we work towards small key properties (we understand) and solve
  them and then combine them.
  The small key properties can be compared and balanced. ÊInstead of
  large full architectures which are too big to compare properly.
  Individual work on proposals, but also do the architectural issues, and
  make trade-offs to make it work in the end.
> Christian: ÊAgree, look at solutions in parallel, as the ones discussed
  today in the RRG. ÊThree main approaches seems to be good to look in parallel.
> Iljitsch: LISP is going forward, id/loc separation was agreed upon.
  Lot of progress, it can be engineered. there is no competition.
  However some problems: the mapping solution, or connect by name.
  (Multipath TCP will happen anyway.)
> David Oran: made three observations.
 ÊFirst, Internet architecture is at a local optimal; can we find another
  better local optimal?
  Second, rather than talking about design approach branches, prefer reality check branch.  For example, sort out solutions that touches the hosts and solutions which are completely in the routers. can we change all hosts?
  Third, the goal of RRG reaching a recommendation by March'09 is not
  achievable, and need to renegotiate with IAB. ÊWe need to give
  advice/recommendation when ready.
> Tony: The goal of spring is set by ourselves, thus if the RRG is not
  ready for architecture recommendation, it can advice for a route to proceed in spring. So it is up to us.
  Consensus? ÊGo to the microphone.
> Lixia: If in spring we are not there yet, with the results we would 
  like to see as output, we should move up the goals and deadlines.
  Bring questions to the mailing list.
> Tony: Continue in the bar! ÊWe are kicked out the room by the hotel.
17:00	End