IETF77 RRG meeting minutes
9:00AM-10:30AM  Friday 3/26

RRG co-chairs Tony Li and Lixia Zhang gave a joint presentation.  Tony started by giving a brief summary of the basic problem RRG was assigned to work on: scaling the DFZ routing system. A few well known contributing factors here:
site multihoming, Provider-Independent prefixes (that will stay), and traffic engineering induced prefix splits. In addition, there is also rising need for IP mobility support and absence of MIP deployment; it is believed (by some people) that a solution to routing scalability could solve this problem at the same time.

The common thread among among all the submitted solution proposals is route aggregation, so that we can route the entire IP space with controlled number of prefixes.  However various proposals differ in their ways to enable aggregation. One can roughly sort all the solutions into 3 broad classes based on where they stop non-aggregatable addresses:

1/ Enforce address aggregatability all the way into end hosts, so that only aggregatable addresses are used.  This implies that a N-way multihomed site will have N prefixes, and a M-way multihomed host in the site could have N*M IP addresses. These solutions require:
- protocol changes to hosts, DNS system, and site operations
  and management (to handle multiple prefixes), and 
- automated renumbering since a site may change providers. 
One great benefit from this class of solutions is no change to DFZ routing.

2/ stop non-aggregatable addresses at the border between sites and Internet core.  This class of solutions require:
- a new mapping system between site prefixes to their attachment points to the core (addresses of routers that connect sites to the core). 
- changed to either CE or PE devices, and
- packet encapsulation to cross the core (hence potential for MTU problems).

3/ can also do aggregate at different places in the network. A nice property here is making no change to hosts; they require changes to ASes, localized solutions with localized changes.

These different solutions have different impacts on different parties; some may get complicated quickly. One may also consider a combination of all the above to derive a solution.

There was a short discussion on whether it is important to sort various solutions into a few broad classes based on the mechanisms they use. One view feared about lack of convergence on this classification; another believed that the most important RRG output is a clear understanding of the design space and tradeoffs.

Nevertheless to structure this presentation a grouping of solutions is necessary. We identify 3 classes.

The first class, dubbed "transmogrification", includes NOL, ILNP, and AIS. They propose a change to the basic picture of today's network, though in totally different ways.
- NOL (Name overlay) introduces a new type of gateway NTR
  (Name Transfer Relay) which blocks the PI addresses of edge networks to scale the DFZ routing. NTRs performs address and/or port translation between blocked PI addresses and globally routable addresses, resembling today's NAT/NAPT devices.
- ILNP splits the 16-byte IPv6 address in half into locator and
  identifier, where locators are solely provider-assigned addresses and thus topologically aggregatable.  It uses DNS as mapping system and requires changes to all hosts. It also needs automated renumbering support.
- AIS is deployable by individual parties to control one’s own
  routing table size, starting from FIB aggregation at individual router, to engineered virtual aggregation within an AS, and extending to inter-AS aggregation between neighbor ASes that have deployed virtual aggregation.

There were a few comments from the floor regarding AIS: the mechanisms in AIS are very doable and some are already in use, however we want something we can live with for a long term.  AIS can be used as stop gap solution, but it is not a permanent one.

Lixia summarized the 2nd and 3rd classes of proposals. The 2nd class can be broadly called "map-n-cap" solutions, which include:
- RANGI:Routing Architecture for the Next Generation Internet.
  It is remotely similar to HIP, but with structure identifier space to
  enable ID lookup.
- LISP: Locator Identifier Separation Protocol.
  One critical issue here is the mapping system, it remains open how to make the mapping scalable, efficient, robust, and updated all at once.
- Ivip: this design shares the basic model with LISP, but with
  a fundamentally different mapping system design: Mapping changes, including those due to single host mobility, are flooded globally and instantly. This raises concern on its feasibility.
- Tunneled Inter-domain Routing (TIDR): Like Ivip, TIDR shares the basic
  model with LISP but differs in the mapping design; it uses BGP to distribute the identifier-to-locator mapping. 
- HIPv4: its distinguished features from the above include 
  the use of 2 locators and a shim layer to get away from encapsulation.
- Global Locator, Local Locator, and Identifier Split (GLI-Split):
  it shares with TIDR the use of 2 locators. Both require host changes. 
- Routing and Addressing in Networks with Global Enterprise Recursion
  (IRON-RANGER) Aggregation with Increasing Scope: this design assumes a hierarchy of recursively-nested networks, and centrally-controlled routing table at each router, doing away with any dynamic routing protocol.

The 3rd class of the proposals is a group of different mapping system designs; each of them does not represent a complete solution on its own. This group of proposals includes:
- Compact routing in locator identifier mapping system
  It uses the basic idea from compact routing design to offer
  mapping for map-n-encap class of solutions.
- LMS: Layered mapping system
  This is a hierarchical mapping system, administered independently of ISPs.
- 2-phased mapping: 
  First phase maps prefix to AS number, and second phase maps AS number to ETR address.
  A short discussion suggested that using AS number for mapping
  would be inadequate for traffic engineering support. 
- Enhanced Efficiency of Mapping Distribution Protocols (EEMDP)
  in Map-and-Encap Schemes: this proposal is not a different mapping design but a specific idea to reduce mapping entries through aggressive prefix aggregation, i.e. allowing holes in the aggregation and treating them with special handling.
- Name-Based Sockets: this one is not a mapping design
  but a change to the BSD socket to operate on FQDNs rather than IP addresses.

One closely related effort that is not mentioned in the above is Multipath TCP, which utilizes the multiple interfaces available on many or most of today's devices. It seems an important investigation to identify the relation between multipath-TCP and some of the RRG solutions, for example in ILNP, hosts in a multihomed site will have  multiple IP addresses that multipath-TCP could potentially make good use of.

One concern raised from the floor is traffic engineering support. Most solutions focused on the DFZ routing table size reduction, but perhaps did not pay adequate attention to traffic engineering support. 

The co-chairs finished the presentation with a rationale discussion:
- We must have a solution to DNZ routing scalability,
  especially considering expected IPv6 rollout.
- All of the long term solutions require major changes to hosts
  before the benefits can be observed.
- We want these major changes to represent the best possible
  changes, however major changes will take time 
- Tactical and strategic changes do not seem compatible, yet we must
  consider both.
So the co-chairs made the following 3 recommendations
- AIS as immediately deployable solution to relieve pain today;
- ILNP as the long term solution; and
- working on renumbering support.

A short open floor discussion followed the presentation.
- Whether the RRG recommendation is for architecture or
  the specific protocol: IETF may take the RRG recommendation as a starting point to work on it.
- Whether the solution should be for IPv6 only: it is up to IETF.
- What happens to RRG: when an RG finishes the working item,
  the decision will be made by IRTF chair regarding next task and new leadership.
- A question was raised regarding the RRG position on
  renumbering: today's recommendation seems taking on a different position than what was discussed a few IETFs back (that renumbering might not be effective).
- New text will be added to the RRG recommendation draft to describe
  RRG recommendation and explain the rationale behind it.

In addition to the above clarification question, there were also discussions regarding specific technical issues and general directions.
- There is a shared view among operators that the inter-domain
  virtual aggregation, as described now, is a bad idea.
- Although changing host stack is considered hard, nothing is easy.  
  Planning for the future allows us to start working on the right direction towards getting from A to Z, rather that delaying the inevitable and making the options at our disposal less and less palatable.