Please read and comment. These are included as text worked into the
agenda. Notes from the scribe are in [].
Regards
Marshall
Routing and Addressing (ROAP) BOF
THURSDAY, March 22, 2007
09:00 - 11:30
Congress II
(Note: This is currently listed in the agenda
as the intarea meeting.)
ADs: Jari Arkko ([EMAIL PROTECTED])
Mark Townsley ([EMAIL PROTECTED])
Chairs: Thomas Narten ([EMAIL PROTECTED])
Peter Schoenmaker ([EMAIL PROTECTED])
Mailing list:
https://www1.ietf.org/mailman/listinfo/ram
DESCRIPTION
This is an architectural discussion about future IETF work on
identifier-locator split and multi-level locator designs that may help
issues with routing scalability and be useful in other ways, in the
long term. It is BOF run within the Internet Area open meeting.
The intent of the BOF is not to immediately create a working group,
but to talk about whether a new identifier-locator split or
multi-level locator based mechanism would help routing scalability and
what the desired properties and boundaries of a new design might
be. The discussion is expected to be architectural, i.e., focus on
high level design decisions and not specific protocol bits. Assuming
that the meeting and ongoing list discussion converges on the
desirability of a new design and the properties thereof, it is
expected that a working group will be created around the IETF-69
timeframe.
Specific protocol proposals are out of scope for BOF discussion.
However, new designs are very welcome in this space and it is
important to learn how the designs work with real-life devices and
applications. It is expected that experimental specifications for
early proposals will be appear in parallel with ongoing architectural
work.
The routing scalability problem has been described in Section 7 of
[REPORT]. The causes and nature of the problem are fairly well
understood and agreed. However, there is less agreement on whether the
problem is urgent and how the growth rates in the routing table
compare to our ability to improve hardware. There is cause for
optimism with regards to the short to medium term ability to build
more scalable router architectures [SCUDDER]. Specific
discussion of the urgency of the problem (or lack thereof) is out of
scope for the BOF, however. It is nevertheless clear that the current
routing system scales according to the number of prefixes that are
also used as end system identifiers in addresses. Can the IETF develop
a model where this would not be needed? This BOF focuses on the use
of an identifier-locator split or multi-level locator design to, among
other things, improve the scalability of the routing system. Note that
such improvements are useful even if one considers the current
scalability problem to be sufficiently addressed by hardware
improvements. For instance, a design that allows the system to scale
better allows us to increase the throughput on a given amount of
hardware resources, allow easy renumbering or multihoming for more
customers than those currently capable of getting it, and so on.
The BOF also takes it as given that there are existing IETF and IRTF
designs in this space, such as HIP and SHIM6. It makes little sense to
repeat these efforts for exactly the same type of functionality. As a
result, the BOF focuses discussing what new functionality or
deployment approaches may be needed that justifies building new
mechanisms or extending the existing ones.
Finally, the BOF should take it as given that new designs need to work
for both IPv4 and IPv6 and that they need to be able to work with
existing unmodified hosts, do not change the core Internet routing
infrastructure, do not expect changes from applications, have support
for dealing with referrals, and be incrementally deployable.
Note that the above scope excludes many interesting topics and
research from this discussion. Scoping is necessary, however, to
achieve something that can reasonably efficiently be specified and
deployed in the current Internet. There are other forums (such as
[RRG]) that look further into the future, including considering so
called "clean slate" designs.
AGENDA
-----
1. Administrative (chairs, 5 min)
- notes takers
- agenda bash
- blue sheets
[TME : I missed this as I was trying to find and plug into power.]
-----
2. Scoping the BOF (ADs, 10 min)
Jari : Background - we would like to know if there is IP layer work
that should
take place. More specifically, we would like to focus on ID-locater
separation.
We would like to
- listen to the community
- gain from the last 6 months of list activity
We will have a presentation from the routing community, what their
requirements
are.
We will also have a architectural design presentation.
We can't go into bits and bytes here, looking for a higher level
discussion.
Do we need a
- network based solution ?
- host based solutions ?
- both ?
Do NATs figure in ?
If we can answer just a few of these questions, we have achieved
something.
Whatever we do needs to be deployable.
It makes sense to allow unchanged applications to continue working.
Backwards
compatibility with existing networks is similarly important.
This is a big change, but even with big things, you have to get them
deployed.
Next steps include
- continue discussion on the RAM list
- come to agreement on the scope of work and directions to be
headed.
We would like to encourage engineering ideas to be submitted as
drafts - and
also we
have the routing research group.
The difference between these is that these are works in progress - do
we have
engineering level work ahead of us, or is more research needed ?
- Why we are here?
- What's in scope?
- What's out of scope?
-----
3. Routing issues where id-loc split might play a role
(David Ward and John Scudder, 20 min)
David Ward :
I am not here to talk to you about requirements - they are not clear,
I am here
to talk to you about goals. Although we have seen a lot of interest
recently,
the routing community has been discussing this for 15 to 20 years. I
am going
to try and bring in a few new ideas.
What's critical is that we need to clearly define the problem.
We also need to discuss whether or not we need to enable new tools or
new
protocols, or remain with the tools we have today.
Two main goals :
We want the rib/fib growth to flatten or even go negative if possible.
we want the dynamics of the routing system to slow down.
Baseline preferences from Vince, David and Dino - many thanks to them
for their
work.
People who think about routing prefer a mechanism to associate an ID
with
Locator addresses.
ID's do not necessarily have to be routable.
We prefer a solution that can be incrementally deployable.
We want little or no modification of Internet infrastructure - so we
have to
live with data bases that exist today. That is primarily BGP and DNS.
We are trying to reduce the router state load.
Who is going to pay and who is going to benefit from this change ?
There is a difference between site-based and provider-based goals.
Sites need to be multi-homed. Sites needs to be connected to more
than one
provider.
Sites needs to be able to change providers.
A question is, does session survivability during the changeover ?
Sites must be able to advertise traffic engineering and service
desires -
multi-provider local balances.
Provider goals :
Network nodes need to scale in multiple ways. Need to conserve both
power
[requirements] and cost of network nodes.
In addition, the providers need to be able to maximize their
resources to
deliver cost effective connectivity.
This may not be possible with modern architecture.
Providers need to be able to prevent bad actors from hijacking their
resources.
This may be the end of the beginning of the 1980 Internet architecture.
Do we want to enable a new tools set to build network functionality ?
Issues include :
Do we want to solve
- network partitioning
- mobile ad hoc networking
- resource mapping
- service locators
- ability to have a single end-point in multiple service domains
This is a tale of two databases.
Routing Database - RIB
[second one lost]
What we see today is that there is no separation of the provider from
the site.
All endpoint state is reflected back into the global internet. We all
bear the
cost of new endpoint state.
Second there is mapping databases in the DNS. There is currently no
notion of
mapping a node to its location in the network.
So, it is interesting that the is a lack of relationship between
routing and
mapping. Both databases assume static endpoints with minimal security.
The routing community believes that we need to add a new mapping
database to
the network today.
In addition, a few other things are critical.
Margaret Wasserman : I thought that you said before that the routing
community
does not want a new mapping function ?
David : If it all possible they want to reuse the mapping functions
we have
today.
If you look at the network, tier 1 networks have acquired a number of
non-contiguous prefixes, so that they are effectively random.
Also interesting, if a site must announce more specific routes, they
may not
need to do anything but traffic engineering.
So, in summary
- We have re-chartered the RRG
- Questions include
- finding the scaling of any solutions ?
- what's the time frame necessary to solve this ?
There is a lack of clarity right now for the exact requirements, the
exact
design and thus the exact solution.
Bishop : In your baseline preference slides, the list of issues are
solved by a
number of mobility protocols. Ip mobility doesn't exist on the
Internet today.
David : This is not taking your laptop somewhere else.
Bishop : I didn't see redundancy there.
David : For sure.
Shane : You have site based and provider based goals. Speaking as a
provider, I
am much more interested in solving the site multi-homing problem than
the site
mobility problem.
My fear is that by overloading too many goals, we don't wind up
solving any
problem.
Second, the real problem is solving for multihoming - I think that
the mapping
database will really be the core problem.
This is a pretty new area.
How do we solve and scale the mapping function to provide multi-
homing is the
core problem
Chair : Clarifying questions only
Vince : There are a whole bunch of solutions that dance around the
mapping
problem - the other side is that we need an Internet architecture
that can
satisfy the drivers of this growth, such as end site multi-homing.
This can be sold as adding functionality that is needed.
Dimitri : What is the difference between a service locator and a
locator ?
David : On an end point, if I have reachability for high speed
Internet, it may
not matter.
Services associated with a locator may be a [?].
Dimitri : Domain and service domain is similar
David : Networks have overlay networks now.
? : Who is going to pay the cost for this ? Providers come in
different shades
of grey. Providers may be in the core, or towards the edge.
Some of their priorities may be different.
David : I agree with you.
? : End to end dynamics are important.
The best architectures are not so go if they hose TCP.
David : I agree
Rüdiger : The administration of the address space has to be
considered as well.
David : There have been a number of factors. It is hard to apply
policy to
random numbers.
- What properties should a solution have, if it it
is going to help routing scalability?
- Traffic engineering requirements
- Role of identifier-locator split vs. general engineering
improvements such as faster hardware
4. Architecture and design space discussion (Dave Thaler, 45 min)
Dave :
I am going talk about the design space.
Terminology : Users start with names, not addresses. Ultimately,
these are
human names.
Routing deals with locators
Security deals with identities
These may or may not be tightly bound.
Today we use hierarchical aggregation as a tool, which is broken by
- PI addressees
- Site multihoming, which injects more specifics
- Traffic engineering, which also may inject more specifics
All three of these are due to local operational state being
propagated globally.
The mobility problem, conceptually you could do mobility by routing
Or, you could (in principle) by name resolution.
But you can't.
We have to work with the existing world.
The inability of the name resolution system out there to deal with rapid
changes. Now, there is TTL, but the results of name resolution are
cached, so
they don't respect any TTL.
The second have is that people want to preserve established connections.
One trouble is you may go from being connected, to not being
connected, and back
to being connected. Will the connection survive the drop ?
A good application will try to hide this from the user.
From an application perspective, all should be transparent.
If application did this, would this be sufficient ?
No, due to real time applications.
By contrast, in Site mobility (sites changing ISPs), the primary
issue is
renumbering.
The pain of renumbering depends on how much has to change.
RFC 3582 - applies to site and host multihoming.
One name choses a set of locators to send to.
Many application (TCP) only communicate one address, and you don't
want to
rebind in the middle,
There is also a desire for location privacy.
Today, the locator is in general visible to the endpoint, unless
there is
translation.
Gregory : Is a locator and an identifier the same for privacy ?
Dave : I intended to use something more abstract.
What you are trying to hide is the locator. If they see enough they
can infer
your topology. People say, if I use NATs, all of my space needs to be
changed.
Going on, when I say managed system, is things that are frequently
updated.
Common cases
In homes : Hosts get automatically updated, gateways are basically never
updated.
In the corporate world, routers get upgraded, while hosts are updated
extremely
rarely. It is hard to do this in the corporate world.
So, how often you are updated depends on where you are looking.
It turns out that new applications tend to move to higher level APIs.
This is good for us, as these higher level APIs could be used to hide
the IP
address.
There is a trend against apps even understanding IP addresses.
Management and security systems are frequently the last and the
hardest to
change.
Unlike applications, where changes on some end points may be
beneficial, with
management systems, until you change all of them, you get no benefit.
That is
what we have learned from IPv6 experience.
Incentives : It is best that changes are only required by entities
actually
feeling the pain.
Often, only one entity (such as one end) experiences the pain and is
incented
to change.
(FOr example in Mobile IP, a endpoint many move but the web server
does not.)
It is best if solutions only require those feeling the pain to change.
Supporting referrals - one application wants to refer or redirect you to
another one.
Can you redirect by name ? Yes, but this is limited.
Applications, for example, may only cache addresses.
Also, not all applications have a name.
How is the mapping secured ?
You want to be sure, if you start with a name, you get the same
[service].
There is a name to IP address binding and a address to connection
binding
Today, DNSSec or IPsec are not really well deployed
You can
- secure per hop
- secure end to end
- or not have security.
You need a chain of trust from the name to a connection. But not all
applications know names, so you need an identifier
1.) How do we secure mappings today ?
Identifier is algorithmically derived from the identity. This Binding
is signed
by someone you trust.
2.) How do you map ?
If name == identifier, this is a no-op
3.) How you you map identifier to locations ?
- Deal with things that dynamically change
Dino : Also reachability of locators - that is different
Dave : Yes.
4.) Where do you do it ?
Vertically - application layer, network layer, below IP, etc.
Horizontally - inside the host, or out in the network somewhere
Margaret Wasserman - There are also issues of state in the network
and path
asymmetries
5.) When do you do it ?
- A priori
- On demand
- at name resolution
- at time of first packets
- forced to buffer
- this could introduce circular dependencies between routing
and lookup
- when do you get changes to the mapping ?
Implications :
If you do this in a router on demand, this implies demand on the
router from
the control plane
Will this lead to mapping tables as big and dynamic as BGP day is
today ?
If so, have you gained anything ?
Margaret Wasserman: Once you have developed the mapping function, why
don't you
replace BGP and we are done. It is almost certainly going to be as
large as
todays FIB.
Ross : Issues are the total load on the control plane, which might be
10^4th
slower than the data plane. You could really redesign routers...
Elliot : You have an issue as to what problem you are trying to solve
here.
All of these presentations have almost no data on them. [I don't like
that.]
Tim Shepherd : You went down a path assuming a ID locator separation.
Dave : These questions are for people who are assuming an ID locator
split
Elliot : There are other architectures to do this.
Jim [?] : I think that you are missing the services point of view.
Margaret : There is a referral that we don't always think about - an
example,
you might want to look on the node and get back to other nodes that are
connected to it. That is a form of referral you are not including.
Dave : Question 3 - is the identifier routable or not ? If it is not,
you may
need both ends to change.
If it is "routable" it may introduce routing state.
Question 4 : Is the ID and the locator present in the data packet ? Can
intermediate systems see the identifier or not ?
In tunneling, for example, the intermediate routers can see both
addresses if
they look inside the encapsulation.
If not, asymmetric paths may mean intermediate systems may not have
mapping
state.
Summary : Incentives are in different places os maybe there will be
complementary solutions.
- Reasons for doing an identifier-locator split
- Design alternatives
- Architectural tradeoffs
- Application impacts
- Balancing costs and benefits
- Deployment
5. Solution space (Pekka Nikander, 15 min)
Pekka : Potential benefits of the ID / locator split.
Why should we do this ?
There are lot of design choices.
Will focus on 4 aspects
- deployment, which is related to incentives
- Where to implement
- Identifier Structure
- Resolution models
If we think about deployment, one way is LISP 1 -
- Identifiers are routable, which may increase routing state
- identifiers are routable over another infrastructure.
- get mapping from the DNS
- new id-based routing system
Also, vertical versus horizontal choice
Vertical :
Within App
In IP Stack
Below IP
Horizontal :
At the application
deeper in the network
Answer may be in multiple places.
Questions :
- How do we assure uniqueness ?
- Are identifiers routable ? Globally ? Locally ?
- How do the existing or proposed solutions fulfill the different
types of needs?
- A case for one or multiple solutions?
Security Questions - self authenticating or not
How do we resolve this mapping ? Is it Query based, like DNS ?
ID router may do this.
Potential benefits :
Obvious ones :
- Stable IDs
- maybe on 2 levels
Dino : Define stable ?
PI addresses are stable
PA addresses are not
More benefits :
- Better routing tables
- may help with TE
- may help with site multihoming.
- Sub network mobility
- provide IP4 and IPv6 interoperability
Since you can change locators, some protection from DOS attacks
We have solutions with a lot of additional information.
There will be pain in the beginning, in return for gain later on.
Two distinct communities will share the pain.
Is there a way of getting these benefits by following one approach -
or do we
need more than one - 2 or more - solutions ?
6. Open discussion (45 min)
7. Conclusions and next steps (10 min, chairs & ADs)
[Question on Dave Thaler Slide 12 ]
I am afraid that the people doing control and management software
assume that
ID and locator is the same, which makes this difficult.
Eric : Is the mapping function an attractive nuisance. Some people
might want
to use it for mobility. Who will control those policies - building
another
flavor of BGP ?
Iljitsch : Both mapping databases, BGP and DNS, are about 20 years
ago. BGP
doesn't scale, DNS scales but isn't dynamic enough.
I think it is important to take this opportunity to build this from
the ground
up and not use 1980's technology. Mobility and multi-homing are
different
things.
Another thing, I think that Dave [Thaler] has a good view of what we
can and
cannot do.
[couldn't hear response well enough]
Iljitsch : We have DNS and BGP now, neither is going away. I was
saying it
makes sense to build the ID locator split from the ground up.
Pekka N. : The horizontal is how you deploy it, the vertical is where
in the
protocol stack you deploy it.
Lisa : I looked at the presentation - I thought I would hear
everyone's wish
lists
Jari : We need to focus on the requirements.
Mark : We wanted to look at the design to decide what we could
possibly do.
Margaret : I would like to see us form a working group, but I am not
sure what
the charter should be. I love the idea of an interim meeting in May.
I think that we need a solution that works for IPv4 and IPv6,
although the
service level may be different.
I am not sure where the new mapping function will come from. I think
that it is
going to require some breakthroughs.
[?] : I think that I agree with 99.9% of the presentation - which
worries me.
What we should be looking at is, where is the gap we need to address ?
Mark : Exactly - where are the gaps.
David : A number of members of the ROAP directorate are here and we
are going
to write down a description of what the problems are that we are
going to
solve.
[?] : And some kind of a gap analysis.
Ross : I think that there are some things that we agree on - I see a
lot of
people who are willing to work ion this - I see a lot of willingness.
I see a lot of this that we do not agree on - the problem we are
trying to
solve, the universe of possible solutions.
Asking a person who doesn't know what the problem who to create a
solution is
probably not a good idea.
Hard problems I see are :
Where is the mapping ? Where is this happening ? How do you align the
costs and
benefits ?
"It is about time we did."
Fred Templin : I don't think that the jackup community is loosing
sight of
mobility.
Pekka : I was just pointing out that there are these two communities.
Danny : Network or host : If you don't aim at hosts, then end to end
will be a
casualty.
Also, I do not think that there is a consensus in the routing community.
Eric : I do not know what the focus of the working group would be.
Dino : From a designers perspective - hard questions with easy
answers. I would
like like to have answers here in the spot. [When asked why, he
said :] So I
can start coding on the plane home.
- Can we use the same solutions for IP v4 and v6 ?
Dave Thaler : If possible, yes.
- Do you believe we have to have a short and long term solution ?
Jari : Yes
- Do you believe that the long term solution [LTS] should replace the
short term [STS] one ?
We cannot make operators turn the network too often.
Peter : If possible the STS should take into account the LTS
? : You have to design knowing that the short term solution will be
around
forever ?
Dave : When do you think that these need to be deployed ?
Dave Ward : I think that it is insane to assume that the short term
solution
will wither away.
Dino : A short term solution will take maybe one or two of the problem
statements to fix.
We need to be really careful that we don't have a plethora of
solutions. It is
really important that we don't have too many solutions.
Lisa : I agree with Dino We need a very clear requirements document.
Bill Shepherd : I shouted why are you asking all of these questions
and Dino
said that he wanted to start coding on the plane.
Aaron : The usual definition of IRTF vs IETF is that research is what
you do
when you don't know what you are doing.
Margaret : I have concerns - I think that there is a lot of space for
research,
but I think that designing the solutions should take place in the
IETF. They
don't have to be as open as WG in the IRTFs.
Jari : It is clear that we don't fully understand the problem - the
Directorate
will be working on the problem statement.
We need to get Dino coding. We need that experience
A quick poll - interest in an interim meeting ?
[30 people at least]
[Meeting ended a few minutes late]
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
