[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] drafty draft of Dublin RRG meeting minutes
Begin forwarded message:
From: Marshall Eubanks <tme@multicasttech.com>
Date: September 15, 2008 11:24:50 AM PDT
To: Tony Li <tony.li@tony.li>
Cc: Lixia Zhang <lixia@CS.UCLA.EDU>
Subject: Fwd: Request For IETF 72 WG and BOF Sessions Agenda,
Minutes, and Presentations
Do you get these ? Note that RRG is on the list.
Marshall
Thanks to Marshall who forwarded to us today this reminder for
submitting the minutes. And BIG thanks to Steven Blake and Benno
Overeinder for taking the notes during the meeting!
Today I went through the notes together with
- the presentation slides
- the RRG meeting recording
and mad various minor correction/clarification changes. Unfortunately
the recording went after after our 15:30 break, so I didn't touch much
about the notes after that break (the memory alredy faded away:(
Hope every at the meeting can help with corrections/clarifications/
additions.
this is due to the secretary on Wednesday 9/17.
Lixia
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 clearn 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
- increasng 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 inrease 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 utiliation
- 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 influenc transport path seelection 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 multipathing 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 sytem 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 utlization
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 dont fight each other
Corrollary: 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 teh 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 groun. 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 princple 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; dont 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 attemp to build resource pooling anyway
- such solutions may conflict
- multipath transport minimizees 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?
> Dmitri: is it not exascerbating 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 streamng 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 congestin 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 applicatin 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 mak 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.
> 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
occuring 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 briding 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 dont seem to have any benefit untill 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 dont 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
> 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 seperation 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 correspondant 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 facilicae 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 chane DNS
> Thomas Narten: so source really means apps here.
> Steve: move DNS furter 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 seprates 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 rendez-vous 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: Rendez-vous is outsourced, DNS is used to access
the rendez-vous server (?)
Primarily use ICNP to notify moves between 2 ends, only fall back to DNS.
Update DNS for potential new correspondants.
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 rouing, 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
rendez-vous function from home agent (MIP) to DNS?
> Steve: yes. but one big difference here is that the rendez-vous 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 suport can be doe with dynamic DNS (orthogonal to ILNP?)
ÊA separate solution to mobility?
If fast DNS you can use just with IP... just rendez-vous 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 appes 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
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.
(So no taxonomy but rather analysis of existing proposal -- ALT)
too bad that all LISP members are gone.
> Christian: isn't this (EID aggregation) an optimization for any mapping
system?
> Lixia: take NERD as a couner example: it does not require the EID
aggregation.
> Luigi: What is the complexity of such system (number of exceptions
and how to manage)?
Exceptions is another form of deaggregation -> better have aggregation
with many exceptions, rather than deaggregation with less exceptions
-> where is the sweet-spot?
Answer of Sriram: About 5 times more entries (first question). ÊThe
sweet-spot of rather one /20 with exceptions than list of /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, than there is no point in aggregations
(counting the exceptions). ÊAnd there 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? ÊIf you do provide a /16
you optimise 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 am mount of effort.
Sriram: /8 you check, not the /24, etc. ÊSomething 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 deaggregated, what could you do to aggregate the fragments?
> Sriram: Will look into this for further quantification.
-------------
Presentation by Brian Dickson
Ask for the slides to be put in IETF72 repository.
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 deaggregation.
Policy follows reachability fate-sharing.
Question the more distant, the less paths you will see for prefixes
(matter of economics).
Joel Halpern: Ê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. Ê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.
Answer: It is different. Ê
Joel: This is an experiment, show us the data analysis instead of
think it is either way.
15:40 Chairs Summary, Directed Discussion, Open Discussion
Chairs, Summary, Directed Discussion, Open Discussion
-----------------------------------------------------
Doug Montgomery: Question related with Sriram presentation to Lixia: 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 highlevel points?
Tony: disagree
Lixia: smile
Joel: do we see that there are different proposals that can benefit for
Srirams' proposal?
Question to Joel:
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.
Iljitsch : Work items for RRG... where should we work on or not?
Lixia: It is up to you, within the topics.
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 says: No!
There is not sufficient weeded out.
Tony: Separation won't work we haven't seen it work.
Lixia: We should work on this topic, not been studied sufficient. ÊOne 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 slides of Lixia.)
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
Lixia: Set of requirements and from there ...
Brian: Not input requirements, but output requirements, and do we
agree on the requirements. Ê(Observations, solutions, suitable for
discussion.)
Lixia: Discussion is always ok. ÊHowever, there is no consensus.
People have different opinions. ÊGiven this uncertainty, do we have
a solution over 5 years to solve scalability. Ê
Brian: There are solutions spaces which are inclusive and exclusive
for solutions.
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 to0 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: Three observations. ÊFirst, it may be worthwhile to
consider to do a reality test (ask ISP for real-world tests).
Second observation: Architectural things on RRG list, than practical
issues solutions that touches the host and solutions which are
completely in the routers.
Third observation: The goal of RRG advice in spring is not
achievable, and need to renegotiate with IAB. ÊWe need to give
advice/recommendation where ...
Tony: The goal of spring is set by ourselves, thus if the RRG is not
ready for architecture, 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 like to
see as output, we should move up the goals and deadlines. ÊThat is the
question and bring it to the list.
Tony: Continue in the bar! ÊWe are kicked out the room by the hotel.
17:00 End