Subject: [RRG] Long term clean-slate only for the RRG?

From: Robin Whittle <[email-masked]>
Date: Sat, 21 Jun 2008 12:59:31 +1000

Hi Tony and Lixia,

You - or at least Tony - seem to be focusing on Getting It Right for
the long-term: forever.  This surely requires a clean-slate
approach, with an entirely new routing and addressing architecture.
 Perhaps you could start with IPv6 and make radical changes along
the lines of GSE - but the result would be something quite different
from IPv6 and would involve major changes to host stacks and
applications, and I guess to TCP, UDP, SCTP etc.

The most substantial solutions to the routing scaling problem
proposed so far are:

   LISP-NERD
   LISP-ALT
   APT
   Ivip
   TRRP
   Six/One Router

These are all intended by their developers to work for both IPv4 and
IPv6 as we know them today, without any host changes - other than
perhaps minor optional changes to help work around moderate inherent
performance problems in the pull-based map-encap systems.  (I think
Six/One Router can't work for IPv4, but it is intended to.)

If you want the RRG to work solely on the Long Term Clean Slate
approach, that is fine.  While I (and I guess the other map-encap
developers) would have something to contribute to that project, it
is not an urgent project - unless perhaps you want it to be the only
solution, which would make it much more urgent.

It would take many years to devise the optimal Clean Slate approach.
 As part of doing so, you would need to incorporate transition
mechanisms which will enable the majority of end-users to be
attracted to it - even in the early days when few others use the new
system - rather than keeping going with the IPv4 (or perhaps IPv6)
Internet.

Then it would take years to create all the new protocols in detail,
write the software, get it built into existing routers and hosts,
and to create new or radically re-written applications for the new
system.  (You would need to have a plan for motivating application
programmers to make such huge investments, before many, or any,
users used the new system.)

A Long Term Clean-Slate project would be much more ambitious than
IPng - which involved minimal changes to host stacks and
applications compared to what you need to do.  12 or so years later,
that project has yet to achieve success.

I (and I guess the other map-encap folks) think that the current
IPv4 situation is important and urgent enough to warrant an IPv4
solution first, with a similar, but not necessarily identical,
solution for IPv6 to be deployed with less urgency.  (I am not
suggesting the Net will melt-down in 2014, just that we are so far
from adopting IPv6, and that IPv6 isn't that exciting, that we need
to keep IPv4 going for a lot longer so we have the decade or so it
will take to devise something adoptable and long-term scalable.)

All the map-encap proposals were described initially in terms of
IPv4, with IPv6 details to follow later.

Maybe you could get the RRG to devise a Long-Term Clean Slate you
consider promising by March 2009, but I can't imagine you will
convince many people that what the RRG devises is so promising that
no other line of research of action needs to be taken.

I think you may be able to convince some IETF folks a
"Clean-Slate-only" approach was the way forward.  However, I can't
imagine a sufficient number of end-users and ISPs would be confident
that a completely clean-slate approach would be developed, deployed
and very widely adopted in time to make it unnecessary to solve the
IPv4 and perhaps IPv6 scaling problems directly.

The parlous state of IPv6 adoption and of its transition mechanisms
shows how hard it is to migrate from IPv4 to some new network which
requires different host stack and applications, and which doesn't
connect directly to the IPv4 network.

Your new Clean Slate approach would be even harder to migrate to,
since the host stack and applications would be totally different,
not just marginally different - due to your need to devise a
completely different set of clearly separated identifiers, locators etc.

With only 9 months to go, I think the RRG needs to decide ASAP
whether we is only working on a Long-Term Clean Slate approach, or
whether we are pursuing several directions of research in parallel.

Until this is settled, I think we will often be discussing things at
cross purposes.  For instance the recent exchange between Bill and
Tony, where Bill talked about the Net as it is today, and what is
required to support end-users who can't and won't change from this
approach in the foreseeable future, while Tony seemed to be
concerned only with the Long-Term Clean Slate approach.

I suggested some text - points A, B and C - we might agree to
regarding multiple paths of research in a recent message:

  3 potential consensus questions
  http://psg.com/lists/rrg/2008/msg01574.html

Here are some other options if C can't be agreed to:

D:  No IPv4 solution - single Long-Term Solution.

    Devise single lasting solution which may be applicable
    as a major revision to IPv6 or which may require a completely
    new Internet architecture, protocols, applications etc.

E:  Devise an IPv6 solution but not an IPv4 solution.

    Work on a solution for IPv6 without major changes (this rules
    out GSE or major changes to protocol, stack, apps etc.)

    As this work progresses, decide whether this will be good enough
    for the Long Term.  Either adapt it to be so, or regard scalable
    IPv6 as the near-term solution, while we devise a separate
    Long Term Clean Slate architecture.

F:  No IPv4 or IPv6 solution.  Devise purely a Long-Term Clean Slate
    solution, which has no basis in IPv4 or IPv6.

I like Bill Herrin's comparison with the Manhattan Project.  What we
are trying to do is so far from a clear solution, yet Something
Definitely Needs To Be Done and there are many uncertainties about
what is technically possible, and what is adoptable in various
time-frames.

I think there are too many uncertainties at present not to pursue
multiple parallel streams of research.

Maybe you only want to conduct the Long-Term stream on the RRG.

 - Robin

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 22 Jun 2008 23:53:22 -0700

Hi Robin,

Below is just a quick reply based on *personal* view.
I would like to first sort out a few basic things.
- yes we want to/need to "get it right"
- a clean-slate way of thinking is to see the complete design space,
   without being constrained by what is "doable" or "undoable".
- it will take a great engineering design decision to choose
   among alternative solutions, based on the tradeoffs,
   short term vs long long term.

a few more points in line

> approach, with an entirely new routing and addressing architecture.

I am not sure what to make out of this statement.
- does it imply that such solutions would not be deployable?
- Isn't map-encap an entirely new scheme (compared to what we have  
today)?
but does it require an "entirely new addressing architecture"?

> applications, and I guess to TCP, UDP, SCTP etc.

Robin, as you saw from the exchanges, there are a number of different  
views regarding "start with IPv6" position.

I feel the most productive thing to do is to identify commonalities in  
the group.
I don't see the need to use an magnifying glass over differences or  
searching for holes in opposing views.

> The most substantial solutions to the routing scaling problem

 From architectural view, I'd identify the commonality of all the  
above as stopping topology-aggregatable prefixes at the boundary of  
edge sites, not which version of IP they may/not work with.

> ......

I failed to comprehend the above paragraph, as it seems to suggest  
long term solution and map-encap are exclusive to each other---not  
sure where this came from.

I'll save the rest for later (as it's getting close to 3AM local  
time). But I'd like to repeat myself one more time here:
- we are solving routing scalability problem here.
   we need to "do it right"
- Lets not throw "Long Term Clean Slate"  rock to others.
- exaggerating differences does not help progress.
- architectural changes and increment deployment do not have to
   be exclusive to each other.

---

From: "Marcus Brunner" <[email-masked]>
Date: Mon, 23 Jun 2008 10:00:22 +0200

Robin,

> You - or at least Tony - seem to be focusing on Getting It 
> Right for the long-term: forever.  This surely requires a 
> clean-slate approach, with an entirely new routing and 
> addressing architecture.
>  Perhaps you could start with IPv6 and make radical changes 
> along the lines of GSE - but the result would be something 
> quite different from IPv6 and would involve major changes to 
> host stacks and applications, and I guess to TCP, UDP, SCTP etc.

That was my understanding too (that's why it is called Research Group). I assume it depends on the interpretation of "clean-slate".

[...]

> The most substantial solutions to the routing scaling problem 

Probably true as technical solution, there are also a set of business solutions possible (e.g., charge for the prefix announcement (-> make disaggregation more costly).

[...]

>  As part of doing so, you would need to incorporate 
> transition mechanisms which will enable the majority of 
> end-users to be attracted to it - even in the early days when 
> few others use the new system - rather than keeping going 
> with the IPv4 (or perhaps IPv6) Internet.

It typically takes already today many years until the IETF has produced a protocol specification, so a large amount of time needs to be factored in anyway. The users (not only end-users) are attracted as soon as they see a benefit for the migration cost. 

> 
> Then it would take years to create all the new protocols in 
> detail, write the software, get it built into existing 
> routers and hosts, and to create new or radically re-written 
> applications for the new system.  (You would need to have a 
> plan for motivating application programmers to make such huge 
> investments, before many, or any, users used the new system.)
> 
> A Long Term Clean-Slate project would be much more ambitious 
> than IPng - which involved minimal changes to host stacks and 
> applications compared to what you need to do.  12 or so years 
> later, that project has yet to achieve success.

Any project has to achieve success (that is not a matter of short vs. long term). 

My experience tells me, that it does not matter whether you do minimal or large changes, since you need to touch equipment anyway. Sometimes minim al changes are even a bigger problem, since they are not that obvious.

Marcus

---

From: [email-masked]
Date: Mon, 23 Jun 2008 10:39:55 EDT

In einer eMail vom 21.06.2008 05:02:19 Westeuropäische Normalzeit schreibt  
[email-masked]:

Hi Tony  and Lixia,

You - or at least Tony - seem to be focusing on Getting It  Right for
the long-term: forever.  This surely requires a  clean-slate
approach, with an entirely new routing and addressing  architecture.
Robin,
Yes !!! Be assured, myself, I am also and only focused on a long-term  
solution, i.e. on a forever scaling solution.
At the same time I never was opposed to LISP or whichever map-encap  variant 
if considered to be a near-term interim solution.By other words:  map-encap is 
definitely not the longterm solution.
Instead I am convinced that topology aggregation will become the  longterm 
solution because it would scale even if the internet became  bigger than the 
network of our roads and streets.
 
For clarity reasons, I would like to ask for using a clean taxonomy.
Obviously, the term "topology aggregating prefixes" relates to  prefixes that 
summarize DFZ-routers' addresses. I think this  only  fosters  confusion, as 
all map-encap solutions are strictly in  opposition to a Topology Aggregating 
Routing Architecture.
 
Heiner

 
Yes, it would create an even more complex status quo, but that wouldn't  have 
mattered much

LISP-NERD
LISP-ALT
APT
Ivip
TRRP
Six/One  Router

-  Robin

---

From: "William Herrin" <[email-masked]>
Date: Mon, 23 Jun 2008 11:13:57 -0400

>  without being constrained by what is "doable" or "undoable".

Lixia,

In order to be useful, a design space is always constrained by what is
or isn't doable. The clean-slate way of thinking merely excludes
compatibility with IPv4 and IPv6 from the definition of doable.

> - Isn't map-encap an entirely new scheme (compared to what we have today)?

Map-encap is not, in my opinion, an entirely new scheme versus what
exists today. All we're doing is leveraging our engineering skill with
VPNs and MPLS and evolving it a little more.

There are small number of additional points to research for map-encap.
Most notably:

1. Unaggregated RIB+MAP scalability limit in a push-based system for
cases where the maximum "normal" cost for a route/map processor (or
processing cluster) is under $10,000. (Note: RIB, not FIB)

2. User-level impact of a first-packet delay.

After that, the research is done and it's time to design a test suite
so we can have an engineering shoot-out.

> I failed to comprehend the above paragraph, as it seems to suggest long term
> solution and map-encap are exclusive to each other---not sure where this
> came from.

It came from the early recognition that when not constrained by what's
possible with IPv4 compatibility in mind, map-encap is a terrible
approach to solving the problem.

I'm convinced that an optimal clean-slate solution requires major
protocol differences at layer 4 and above. That optimal solution will
include some combination of topological address aggregation and
multiple addresses per host.

Static address assignment doesn't tend to lead to good topological
aggregation because the topology is dictated by changing business
relationships, demand curves and outages for which static addressing
can't adequately account. So in order to get topological aggregation,
we're talking about the routing protocol performing continuous
optimization of address assignments. That implies that the layer-3
address becomes ephemeral in nature, which in turn requires that we
decouple layer-4 and up from the addressing at layer 3.

I don't mean a hack decoupling like Shim6, I mean real redesign. Layer
3 IPv6 might survive but layer 4 surely won't.

IF we take a clean-slate approach to the problem.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: "James Kempf" <[email-masked]>
Date: Mon, 23 Jun 2008 09:35:31 -0700

Robin,

I haven't been following this discussion in detail, but I basically agree 
with your assessment.

There are other folks working on clean slate architectures, GENI, etc.. The 
IETF (including IRTF which isn't that far removed) should "stick to the 
knitting" and work on stuff that keeps the current Internet running well. 
And, as you mention below, fixing problems for IPv4 is much more important 
than for IPv6, because IPv4 is more widely deployed. When and if a clean 
slate architecture gains traction, it is as likely to look like the current 
Internet as the circuit switched telphone network does.

One thing that concerns me is the managability of any map and encap 
solution. I took a look at the LISP proposal a while back, and it struck me 
as raising some unique challenges for managability. That's not a reason not 
to do it, but I think that the RG should focus on "design for managability", 
i.e. that managability should be in the top ten goals for the design.

              jak

----- Original Message ----- 
From: "Robin Whittle" <[email-masked]>
To: "Routing Research Group" <[email-masked]>; <[email-masked]>; "Lixia Zhang" 
<[email-masked]>
Sent: Friday, June 20, 2008 7:59 PM
Subject: [RRG] Long term clean-slate only for the RRG?

---

From: Scott Brim <[email-masked]>
Date: Mon, 23 Jun 2008 12:51:07 -0400

>   short term vs long long term.

I like to start with a clean slate set of _requirements_ (not design) 
and then work back to what is doable short term.  That way your 
immediate actions at least lead us in a good long-term direction.

> I'll save the rest for later (as it's getting close to 3AM local time). 
> But I'd like to repeat myself one more time here:

(1) We need to do it.

(2) To the extent we can do it "right" and still satisfy (1) in useful 
time, we should.  See above as a way to do it.

On 6/23/08 12:35 PM, James Kempf allegedly wrote:
> solution. I took a look at the LISP proposal a while back, and it struck 
> me as raising some unique challenges for managability. That's not a 
> reason not to do it, but I think that the RG should focus on "design for 
> managability", i.e. that managability should be in the top ten goals for 
> the design.

Could you say more explicitly what problems you think might be there? 
For the sake of guidance for the architecture work in general.

swb

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 Jun 2008 10:02:49 -0700

> Robin,
> Yes !!! Be assured, myself, I am also and only focused on a long- 
> term solution, i.e. on a forever scaling solution.
> At the same time I never was opposed to LISP or whichever map-encap  
> variant if considered to be a near-term interim solution.By other  
> words: map-encap is definitely not the longterm solution.
> Instead I am convinced that topology aggregation will become the  
> longterm solution because it would scale even if the internet became  
> bigger than the network of our roads and streets.

And to add to this, from the beginning, none of the LISP authors felt  
that LISP was the ultimate long-term solution.

So, should the short-term map-n-encap solution be for IPv4 and the  
long-term solution be for IPv6 only? That would depart from the  
thought of having one solution for both address-families.

Could we agree that one map-n-encap solution for both IPv4 and IPv6 be  
a short-term solution while we work on a long-term solution for IPv6- 
only?

Dino

---

From: Robin Whittle <[email-masked]>
Date: Tue, 24 Jun 2008 12:30:34 +1000

I am replying to James Kempf, Scott Brim and Dino Farinacci.

My interpretation of your positions is that you do not support the
current rough consensus item, which may be up for further discussion
or a more formal vote (msg 1558).  I will call this "Paragraph T":

   http://psg.com/lists/rrg/2008/msg01535.html

T:  Our recommendation should be applicable to IPv6.  It may or
    may not also apply to IPv4, but at the very least must
    provide a path forward for IPv6.

My impression is that you might favour my proposals A, B and C:

Paragraph C would commit the RRG to pursuing 3 parallel streams of
research, implicitly with three different time-frames:

C:   There are three worthy avenues of investigation which we should
     pursue in parallel:

     1 - A solution which is optimal for IPv4 and which might be
         applicable to IPv6, but which may not be optimal for IPv6.

     2 - An IPv6 solution which may be one of:

         a - Conceptually compatible with the IPv4 solution, but
             potentially different in detail.

         b - Fundamentally different from the IPv4 solution and
             which may or may not involve major changes to the IPv6
             routing and addressing system: involving changes to
             host stacks and applications.

     3 - A clean slate solution, unconstrained by the current
         state of IPv4 or IPv6.

If the RRG achieves consensus on Paragraph C, and if we can handle
the whole discussion on the RRG list, then there is no need for my
suggestion for a separate list such as RRG-Sandbox.

However, even if we agree on Paragraph C or similar, if there are
other restrictions on the RRG list - such as not discussing
potential solutions, or deliberately avoiding technical details
(viewed by some as merely "engineering" and likely to distract from
"architecture") - then I would still suggest we have a another list.

If the RRG can't agree to C above, then I present some possible
alternatives, D, E and F - none of which I support - in:

  http://psg.com/lists/rrg/2008/msg01594.html

James Kempf wrote:

> Robin,
>
> I haven't been following this discussion in detail, but I
> basically agree with your assessment.

OK.  Thanks.

> There are other folks working on clean slate architectures, GENI,
> etc.. The IETF (including IRTF which isn't that far removed)
> should "stick to the knitting" and work on stuff that keeps the
> current Internet running well.

I agree, but I think some folks on the RRG - including perhaps Lixia
and Tony - think our role should be focused on the long term and
that keeping the current (IPv4) Internet working is not our concern.

I think this position is partly based on the notion that the IPv4
Internet is working and will keep working sufficiently well that we
don't need to do much about it - and that a long-term solution can
be developed be widely adopted soon enough for the IPv4 (and perhaps
IPv6) pain to be acceptable.

**  I think we really need to decide for or against T, C or
**  alternatives such as D, E and F as soon as possible.

> And, as you mention below, fixing problems for IPv4 is much more
> important than for IPv6, because IPv4 is more widely deployed.

I agree entirely.

There are countless billions of dollars invested in IPv4 and there
is going to be massive investment keeping it going, since all the
alternative is (initially) a separate Internet with only limited
connection to the IPv4 Internet, and with very few people connected
to it.

The momentum of IT systems is immense, and I think it is hard to
think of a greater example than IPv4 (reachability of other hosts,
compatibility with host OSes and applications).

Most end-users don't care much about the long-term or the
architectural correctness of their IT systems.  They need works
today to keep working tomorrow.

However, some regard IPv4 as a dead-end, and who are confident of
widespread adoption of IPv6 (or whatever) in time that the IPv4
routing scaling problem wouldn't be too much of a concern.  For
them, perhaps the worsening costs, lack of space, lack of
multihoming and portability etc. of IPv4 is probably a good thing -
because they think it gives impetus to the world to kick the IPv4 habit.

I have some sympathy for this utopian view.  Likewise I wish the
world would standardise on one side of the road or the other for
driving - I am dreading trying to drive on the wrong side when I
travel to the USA!

http://en.wikipedia.org/wiki/Left_hand_drive
http://users.pandora.be/worldstandards/driving%20on%20the%20left.htm

If the RRG and therefore the IETF only pursue a long-term solution,
unconcerned about the growing trouble in today's Internet (IPv4), I
think a billion or so Internet users would feel this was a utopian
vision which was well intentioned, but did not give sufficient
priority to their actual needs.

> When and if a clean slate architecture gains traction, it is as
> likely to look like the current Internet as the circuit switched
> telephone network does.

Yes.

A clean slate design will require radically rewritten applications
as well as operating systems.  It will probably involve a completely
different routing system too, with the need for new routers, new
routing protocols etc.

Properly done, a clean-slate design would support mobility and
global end-to-end QoS with a financial settlement system so
end-users (or their ISPs) could pay for reserving bandwidth.  These
would make the Internet into a reliable, well funded, global data
network for everything from ping packets cell-phone calls to
multi-gigabyte streaming HDTV and massive, robust, VPNs.

> One thing that concerns me is the managability of any map and
> encap solution. I took a look at the LISP proposal a while back,
> and it struck me as raising some unique challenges for
> managability. That's not a reason not to do it, but I think that
> the RG should focus on "design for managability", i.e. that
> managability should be in the top ten goals for the design.

LISP isn't the only map-encap scheme - a list of distinctions and
commonalities with the others is here.

  http://www.firstpr.com.au/ip/ivip/comp/

Ivip involves simpler ITRs and modularly separates the multihoming
failure detection and decision system out of the map-encap scheme,
whereas the others integrate it monolithically.  Ivip has a business
case for the OITRDs (Open ITRs in the DFZ - which support packets
from networks without ITRs) whereas there is currently no business
case for the LISP equivalent: "Proxy Tunnel Routers".

  http://psg.com/lists/rrg/2008/msg01158.html

>> bigger than the network of our roads and streets.

The quote was from Heiner Hummel, not me.

> that LISP was the ultimate long-term solution.

Likewise with Ivip - the ultimate long-term solution involves
different protocols, as Bill Herrin wrote:

  http://psg.com/lists/rrg/2008/msg01602.html

> long-term solution be for IPv6 only? That would depart from the thought
> of having one solution for both address-families.

That would involve the assumption that IPv6 could be used as a basis
for the long-term solution.  I suspect it would be better to start
afresh, which is why I proposed Paragraph C.

> Could we agree that one map-n-encap solution for both IPv4 and IPv6 be a
> short-term solution while we work on a long-term solution for IPv6-only?

I support this - if this turns out to be the best approach, then it
is covered by point 2 A of Paragraph C.

Assuming we fix IPv4 with a map-encap solution, and assuming that
the long-term solution needs to be clean-slate - not based at all on
IPv4 or IPv6 - then I think it would be good to decide:

   Although IPv6 could support a translation scheme such as
   was Six/One Router (which may have less PMTUD problems than
   map-encap, and involve less inefficiency with the overhead of
   long IPv6 encapsulating headers)  . . .

   Since IPv6 is not the long-term solution, and since we have
   figured out a fix for PMTUD already with the IPv4 map-encap
   system . . .

   Rather than have two architecturally different solutions for
   IPv4 and IPv6, we might as well use map-encap for IPv6.

Scott Brim wrote:

> I like to start with a clean slate set of _requirements_ (not
> design) and then work back to what is doable short term.

OK.  I understand from this that you support either:

  1 - Fixing IPv4 ASAP in order to give more time for IPv6 and a
      long-term solution.

  2 - Fixing IPv6 ASAP, with the intention that we can do this soon
      enough *and* make it favourable enough to get most people to
      adopt it, soon enough that the IPv4 swamp and scaling problem
      is somehow acceptable.

I support point 1 - and this is covered by Paragraph C.

I don't support point 2.  That is covered by Paragraph E:

   http://psg.com/lists/rrg/2008/msg01594.html

> That way your immediate actions at least lead us in a good
> long-term direction.

Yes - probably involving one or perhaps two intermediate solutions
to give time for a proper long-term solution.

Perhaps there is a way of designing the IPv4 or IPv6 solutions so
that they in some way support migration to the long-term solution -
or perhaps without any changes to those designs, they might be
useful for this anyway.

I had a rough go at thinking about this recently (IPv99) - assuming
a good map-encap IPv4 system, what new system might we create which
would last for the long-term but have an agreeable migration path:

  http://psg.com/lists/rrg/2008/msg01503.html

but that is far from "clean-slate" since the new system would retain
explicit support for IPv4 and has its overall address space largely
based on current IPv4 assignments.

Quoting Lixia:

>> I'll save the rest for later (as it's getting close to 3AM
>> local time). But I'd like to repeat myself one more time here:
>> - we are solving routing scalability problem here. we need to
>> "do it right"
>
> (1) We need to do it.
>
> (2) To the extent we can do it "right" and still satisfy (1) in
> useful time, we should.  See above as a way to do it.

I think this means you define a "short term" time-frame and figure
out what arguably needs to be done to protect current and
near-future (5 to 8 years maybe) end-users, and whether there is a
promising solution which would support in some way a long-term solution.

"Support" could be in the form of forming a technical basis for
migrating to the long term solution and/or by solving the near-term
problem (say 5 to 15 or whatever years) to give us more time to
concoct a genuine long-term solution with sufficient benefits and
with transition mechanisms which mean it is likely to be adopted in
the "long-term" - say 15+ years - early adoption in 2020 and
widespread by 2027 or whatever.

 - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jun 2008 16:34:58 +1200

On 2008-06-24 05:02, Dino Farinacci wrote:
...
> short-term solution while we work on a long-term solution for IPv6-only?

Clarifying question: do we have to hold our breath while
waiting for the long term solution?

But seriously - since it doesn't seem that we want to shrug our
shoulders over IPv4, and I don't see the industry being willing to
support two solutions, I don't see much choice.

   Brian

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 Jun 2008 15:35:13 -0700

> solution. I took a look at the LISP proposal a while back, and it  
> struck me as raising some unique challenges for managability. That's  
> not a reason not to do it, but I think that the RG should focus on  
> "design for managability", i.e. that managability should be in the  
> top ten goals for the design.

Thanks for your comments James. What sort of challenges are you  
referring to? Could you be more specific?

Dino

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 24 Jun 2008 07:23:05 -0700

Dino,

> a short-term solution while we work on a long-term solution for IPv6- 

Perhaps we should first agree that there is a need a *short term*
solution for both IPv4 and IPv6. The following (from Tony's e-mail
on 5/26/2008) is relevant to the discussion on whether there is
such a need:

   Well, Ross Callon has been quoted as saying that the Juniper
   implementation will have no problems up through many millions
   of routes.

   Now, conceptually, that could happen tomorrow.  However, at the
   current growth rates, that's likely to be many years.

Yakov.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Jun 2008 12:48:56 -0700

>   current growth rates, that's likely to be many years.

The routing table size problem is not the only problem. There are many  
enterprise sites that want to do low-cost multihoming, they want to be  
good citizens to the Internet and don't want to inject more specifics,  
and they want to control their ingress traffic flows.

Dino

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jun 2008 08:41:47 -0700

Robin,

I don't support IETF/IRTF working on any long term, clean slate solutions. I 
believe that the preliminary phases in which this work is now require small 
teams of creative individuals with new and quite radically different ideas. 
An environment of required consensus and "design by committee" isn't 
conducive to the kind of creative thinking that is required for such 
solutions. After all if Kleinrock, Cerf, and the rest had gone to ITU with 
the Internet in the early phase, would it have ever happened?

As for the other proposals, a solution for IPv4 is absolutely required, 
since that is what industry and society depends on, regardless of how much 
the IETF may desire that IPv6 become the basis of people's day to day 
interaction with the Internet. I'm not sure about having different solutions 
for IPv4 and IPv6. I suspect that there would be a lot of pushback from 
vendors and operators on this when it went to standardization, and I'm sure 
there would be a draft that would pop up for "IPv4-solution-on-IPv6" that 
would rapidly gain consensus and overthrow any IPv6-only solution. 
Fundamentally, vendors don't want to implement new protocols and operators 
don't want to deploy them, and they especially don't want different 
protocols in IPv4 and IPv6, though, technically, I think there is a good 
case to be made for a different IPv6 solution that leverages the longer 
address size. But I think vendors and operators really only want to take 
existing protocols and modify them, and that only when absolutely necessary.

            jak

----- Original Message ----- 
From: "Robin Whittle" <[email-masked]>
To: <[email-masked]>
Cc: "Dino Farinacci" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; "James Kempf" <[email-masked]>; "Scott Brim" 
<[email-masked]>
Sent: Monday, June 23, 2008 7:30 PM
Subject: Re: [RRG] Long term clean-slate only for the RRG?

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jun 2008 08:42:51 -0700

Dino,

Like I said, it has been a while since I looked at it. I'd have to go 
through it again and refresh my memory. Perhaps I can find some time in the 
near future to do that, right now, I've unfortunately got too much else 
happening.

          jak

----- Original Message ----- 
From: "Dino Farinacci" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Robin Whittle" <[email-masked]>; "Routing Research Group" 
<[email-masked]>; <[email-masked]>; "Lixia Zhang" <[email-masked]>
Sent: Monday, June 23, 2008 3:35 PM
Subject: Re: [RRG] Long term clean-slate only for the RRG?

> Thanks for your comments James. What sort of challenges are you  referring 
> to? Could you be more specific?
>
> Dino
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 25 Jun 2008 13:15:08 -0700

> Dino,
>
> Like I said, it has been a while since I looked at it. I'd have to  
> go through it again and refresh my memory. Perhaps I can find some  
> time in the near future to do that, right now, I've unfortunately  
> got too much else happening.
>
>         jak

This kinda reinforces your point about how a small group of people  
that are focused solely on this problem is really the most efficient  
way to get a solution to get traction.

The sort of management issues I see what LISP are:

1) There is a new namespace.
2) There is encapsulation.
3) There is a mapping database.

As for 1), it is no different than managing 2 address spaces, each in  
different VRFs. So network operators have experience with this. We  
aren't introducing anything monumentally new.

As for 2), we understand tunneling. We have seen it in so many forms  
over the last decade and a half. We know why it's good and what the  
disadvantages are. So there are no surprises here. Nothing  
monumentally new.

As for 3), the mapping database is something that has to scale on a  
grander scale that what we've seen with other mapping or caching  
databases. Some exiting ones to note are ARP, DNS, an NAT. For ARP,  
the problem is constrained to link-local usage but I have seen some  
layer-2 networks with 10^5 MACs on it. As for DNS, I think it works  
remarkably well for the grand scale it is being used for. In fact, I  
just saw an article about Paul Mock and the *25th anniversary* of DNS.  
So we can borrow some of the *simple* ideas from DNS. As for NAT, we  
have seen large NAT tables (in the places where people are connecting  
sites and SPs together). NAT has a major OpEx hit but again the  
mapping database proposals especially LISP-ALT is not really  
introducing anything monumentally new. It's just BGP over tunnels and  
you send Map-Request and return Map-Replies over this topology.

I was able to nutshell LISP-ALT in one sentence.

So I really feel that the LISP architecture is pretty much taking well- 
known technology from many places and putting it into an architecture  
so we can incrementally deploy a solution. So I think the risk of  
deploying LISP is relatively low.

Please don't get me wrong or take this the wrong way. I am not posting  
this message to do "LISP marketing", I am trying to be practical. And  
as Noel has stated, the network, as it is deployed today is messy (or  
as Peter Lothberg would say "full of spaghetti"), which calls for some  
hard decisions to be made.

Dino

---

From: [email-masked]
Date: Wed, 25 Jun 2008 17:43:39 EDT

Yakov,
Would you mind to explain what you wanted to express by what has been  called 
your law ?
It is pretty difficult, because DV-based routing does NOT  provide ANY 
topology. While favoring topology aggregation, I am in  favor of "topology which 
follows addressing", however in a well determined  sense:
that a (sparsed) topology is built/viewed based on geographical  information 
(addressing).
I would appreciate your own clarification.
 
Heiner
 
BTW: We have just reached the final, whill Russia join too?

In einer eMail vom 24.06.2008 16:28:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

Dino,

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 26 Jun 2008 06:53:50 -0700

Dino,

> The routing table size problem is not the only problem. 

Good. So, at least we seems to agree that we do not need LISP
to deal with the routing table size.

> There are many  

LISP is *not* going to reduce the cost of multi-homing. To the
contrary, LISP is going to make the cost of multihoming higher than
it is today. This is because deploying and operating additional
infrastructure/mechanisms to support LISP has its own (non-zero)
cost.

Moreover, LISP would would place this cost not only on the enterprises
that want to do multihoming, but on other parties as well (which
would result in mis-alignment of cost relative to benefits).

Yakov.

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 26 Jun 2008 10:24:29 -0400 (EDT)

> From: Yakov Rekhter <[email-masked]>

    > at least we seems to agree that we do not need LISP to deal with the
    > routing table size.

Umm, logic fault...

    > contrary, LISP is going to make the cost of multihoming higher than it
    > is today. This is because deploying and operating additional
    > infrastructure/mechanisms to support LISP has its own (non-zero) cost.

It's hard to compare the cost of that infrastructure/mechanism with the costs
of the alternatives, though, which seem to be either:

- i) PI supported by the routing (q.v. that study that person did which tried
to come up with a monetary figure for each entry in the DFZ table), or
- ii) multiple addresses per host, visible to all (which is the Shim6
approach, which has received a lot of flack).

Multi-homing, as I keep saying, is a benefit, but it's a benefit that has
costs. The only question is how large are the costs, and who's going to pay
them. So, what's your preferred method of supporting multi-homing, and why do
you prefer that one? (This is not a snarky question, but a completely serious
one.)

And here's another one that occurs to me: a lot of people seem to see the
value in separating location and identity. Do you agree this is a good move,
and if not, why not? (Again, totally seriously.)

    > that want to do multihoming, but on other parties as well (which would
    > result in mis-alignment of cost relative to benefits).

I'm not quite sure of your meaning here? Did you mean that if we adopt LISP,
all sites will wind up having to maintain mappings, even if they are not
multi-homed? (I hope it's obvious that a general identity-location mapping
system provides other benefits than just multi-homing, e.g. provider
independence).

Or did you have some other meaning of "place this cost not only on the
enterprises that want to do multihoming, but on other parties as well", e.g.
somehow part of the cost is being borne by other parts of the infrastructure,
not moved as close as possible to the entities being multi-homed? If so, could
you elaborate?

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 26 Jun 2008 10:41:10 -0400 (EDT)

> From: Dino Farinacci <[email-masked]>

    > the mapping database is something that has to scale on a grander scale
    > that what we've seen with other mapping or caching databases.

This triggered the following thought, something for people to think about:

If one signs on to the concept of 'separate location from identity', and one
also decides to support a high percentage of unmodified hosts, then that more
or less inevitably implies a network-sized (i.e. distributed) mapping database
(along with its attendent maintainence/deployment/etc costs).

That's part of the reason I was at one point enamoured of adding identity
above the internetwork layer: I worked out a TCP option that would make TCP
connections be between endpoints, and the address-endpoint mapping was
contained in the connection request - no need for a distributed mapping
database. However, it did require changing the hosts...

But if one thinks about it, it kind of makes sense that those two together
imply the need for the mapping database. I mean, if the hosts can't be
involved in providing bindings (because they don't change), and there's going
to be a new namespace, how else can one create and promulgate the bindings
involved in that new namespace, if not in a separate system?

So I can't see anyway around the location-identity-separation +
unmodified-hosts --> network-sized-mapping-database problem. Or is my brain
just not working very well today, and there's some clever solution I have
missed?

If not, people need to seriously re-examine their commitment to the principle
of separate of location and identity. Like multi-homing, it has benefits, but
it also has inevitable costs. TANSTAAFL...

	Noel

---

From: Eliot Lear <[email-masked]>
Date: Thu, 26 Jun 2008 17:01:33 +0200

> to deal with the routing table size.
You've contorted what Dino said from "routing table size is not the only 
problem" to "routing table size ISN'T a problem".  As I wrote you, IPv6 
has more than taken 14 years (and counting) to deploy, and yet you're 
making wild claims about what you'll be able to support 14 years from 
now.  Let's not do that.

> infrastructure/mechanisms to support LISP has its own (non-zero)

While it is true that deploying LISP would have a non-zero cost, you've 
once again contorted the situation.  One has to ask the question of what 
is the cost of NOT deploying LISP (or a mechanism like that).  Let's 
engage in THAT debate.

> would result in mis-alignment of cost relative to benefits).

Assuming there is no benefit to those other parties.  A big assumption.

Eliot

---

From: David Conrad <[email-masked]>
Date: Thu, 26 Jun 2008 08:32:52 -0700

Yakov,

On Jun 26, 2008, at 6:53 AM, Yakov Rekhter wrote:
> it is today.

LISP, or something like it, would reduce the cost of multi-homing  
_over the long term_.

> would result in mis-alignment of cost relative to benefits).

Would this purported mis-alignment be better or worse than PI-for- 
everybody?  Or do you have some other solution?

Regards,
-drc

---

From: "William Herrin" <[email-masked]>
Date: Thu, 26 Jun 2008 11:47:20 -0400

On Tue, Jun 24, 2008 at 10:23 AM, Yakov Rekhter <[email-masked]> wrote:
> solution for both IPv4 and IPv6.
>> at the current growth rates, that's likely to be many years.

Hi Yakov,

Current growth rates are not representative of actual demand. They've
been suppressed by the RIRs for more than a decade now, via their
refusal to assign small otherwise-routeable blocks (e.g. /24). The
suppression was initiated as a stop-gap solution at the request of the
network operators faced with what is currently an unrecoverable
systemic cost of about US $2B per year and growing.

Needless to say, that decade-long stopgap is wearing thin. We really
do an alternative.

Regards,
Bill Herrin

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Jun 2008 09:28:05 -0700

> to deal with the routing table size.

No, you didn't read the sentence carefully, I said "not the only  
problem". There is problem with any database that gets too large.  
Yakov, the vendor side of it is one thing and most of our products can  
support large tables. That's not what I'm worried about. I'm worried  
about the increase in OpEx and control plane performance for the  
operators.

> it is today. This is because deploying and operating additional

Why do you say that? Of course if the architecture is straight  
forward, the implementation can proceed to optimize on simplicity and  
ease of use.

So if you are going to say, without data, that LISP is going to cost  
more. Than I will respond and say that it will not.   ;-)

> infrastructure/mechanisms to support LISP has its own (non-zero)

Revenue source opportunity. Look at it that way. There is always a  
cost of doing something new, but if you can monetize it with the  
benefits, then it is a win.

> would result in mis-alignment of cost relative to benefits).

Say more. I don't follow. The cost of doing BGP is high for end-sites,  
but they can't control active-active connection on ingress even though  
they pay that cost. Their egress policy is done in the IGP. So what is  
BGP buying them at the site?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Jun 2008 08:14:14 -0700

> just not working very well today, and there's some clever solution I  

Noel, so I think you are stating something obvious, but just want to  
make sure you are not implying some other subtle point.

All I can see is this one way to proceed as well.

> it also has inevitable costs. TANSTAAFL...

I think the RRG has only focused on loc/id split and really hasn't  
gone into greater depth with other routing architectures. Since it is  
a research group, it should, or more strongly, it must.

Dino

---

From: [email-masked]
Date: Fri, 27 Jun 2008 12:48:27 EDT

In einer eMail vom 27.06.2008 18:00:20 Westeuropäische Normalzeit schreibt  
[email-masked]:

Dino

I completely agree.
 
I think the internet was the first dealing with route computation.  Meanwhile 
others have outperformed the IETF: route planning, car navigation. 
 
It is always harder to get from 1 to 2, than from 2 to 3, because if you  
have just one solution you may be tempted to believe that there can't be any  
other solution at all. However, the IETF does have 2 solutions: one for  
intra-domain, one for inter-domain. I am sure, DV would also work intra-domain  wise. 
But obviously Dijkstra is better than Distance Vector for intra-domain. So  
why not also for inter-domain ? I can imagine what is the quick answer, but  
research is something else. Not less, instead better than Dijkstra is  needed.
 
Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 27 Jun 2008 13:17:09 -0400 (EDT)

>> I can't see anyway around the location-identity-separation +
    >> unmodified-hosts --> network-sized-mapping-database problem. Or is ..
    >> there's some clever solution I have missed?

    > just want to make sure you are not implying some other subtle point.

No, no, just what it says: if we want to have both i) separation of location
and identity, and ii) unmodified hosts, then we necessarily have to have a
network-sized mapping database.

My point was that, if my thinking is correct (and if it's not, can someone
please point out where I've gone wrong), it's not reasonable to
simultaneously say 'I want location/identity separation' and also say 'I
don't want to change existing host software' and 'I think a big mapping
database is not feasible'. If you want the first, one of the next two _has_
to give; the only question is _which_.

I phrase it in high-level terms, not in terms of any particular proposal, to
make clear that it seems to me to be a fundamental limitation. If I am
confused, can someone please straighten me out!

If not, then I think it would be interested to have people hum on i) do we
want location/identity separation, and, if 'yes', ii) do we a) change hosts,
or b) accept the need for a network-sized mapping database - making clear, at
the time we ask i), that it implies having to make a choice at ii).

    > I think the RRG has only focused on loc/id split and really hasn't gone
    > into greater depth with other routing architectures.

Ah, I don't consider the location/identity split a 'routing architecture'.
It's an ancillary aspect of the overall system architecture, one which has at
best some influence on particular desired operational goals having to do with
routing (e.g. provider independence).

To me, routing architectures are about things like 'what entity choses the
path the packets flow along', and 'how are those paths computed', 'what data
does that computation need', 'how is that data distributed', etc.
network-sized-mapping-database.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 27 Jun 2008 13:29:16 -0400 (EDT)

> From: [email-masked] (Noel Chiappa)

    >> LISP is *not* going to reduce the cost of multi-homing. ... This is
    >> because deploying and operating additional infrastructure/mechanisms
    >> to support LISP has its own (non-zero) cost.

    > the alternatives .. seem to be either:
    > - i) PI supported by the routing .. or
    > - ii) multiple addresses per host, visible to all
    > ..
    > Multi-homing .. is a benefit, but it's a benefit that has costs. The
    > only question is how large are the costs, and who's going to pay them.
    > So, what's your preferred method of supporting multi-homing, and why do
    > you prefer that one?
    > ..
    > a lot of people seem to see the value in separating location and
    > identity. Do you agree this is a good move, and if not, why not?

These weren't pro forma questions, or rhetorical devices. I am genuinely
interested to hear from people with divergent views, because if there's an
erroneous judgement somewhere, I'd like to hear about it. (And my mind is not
set in concrete - e.g. I have in the past supported ii), but have been told
that it's a non-starter.)

If Yakov's too busy with other stuff to respond, is there anyone else who'd
like to answer either one?

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Jun 2008 13:46:18 -0400

Comments in line:

Noel Chiappa wrote:
...
> confused, can someone please straighten me out!

Sounds right to me.  If there is going to be a split, someone has to 
deal with the relationship between the parts.  If the network is dealing 
with that relationship, then that is a large mapping database.  If the 
host is dealing with it, then the host is changing (and may or may not 
need a large mapping database.)

> the time we ask i), that it implies having to make a choice at ii).

It seems to me that separating out the way the communication system 
looks at the identity of the communicating parties and the way it looks 
at the location of those parties is a useful improvement in the system.
I am willing to accept host changes, if that is what it takes to get 
there.  (In fact, to really introduce the notion of identity there 
probably have to be host changes.  Identity ought to be constant across 
the interfaces the host uses to talk as much as across the interfaces 
the containing site uses to talk to the core.)

> network-sized-mapping-database.

I think that the question of whether the system has separate notions of 
identity and location is an important architectural question.  (I use 
"system" because it is quite possible to construct approaches where the 
identity is above transport, or is an opaque object used by transport, 
rather than being below transport.  Also, I use system because I do not 
think it is either practical or effective to try to re-architect the IP 
layer and its forwarding without looking at things around it, and 
possibly making some changes there too.)

---

From: David Williamson <[email-masked]>
Date: Fri, 27 Jun 2008 11:26:34 -0700

> to give; the only question is _which_.

I agree.  The first statement implies either host changes, or some sort
of network wide mapping.  As an operator, I'm feeling a bti stuck by
this quandry, though.  I definitely want the loc/id split, since that
seems like the most direct way forward to avoid the scaling problem.
On the other hand, large scale host changes seem difficult and tiem
consuming.  And I have serious concerns about how we move from the
current routing regime to something that depends on a network wide
database.  If you operate a service where reliability and reachability
are key, that transition period could be extremely painful, and may not
be possible without further impact to the scaling problem (by carrying
a full set of conventional routes *and* handling some sort of
map-and-encap protocol at the same time, for example.)

Perhaps it's a lack of imagination, but I seem to find myself in a maze
of twisty passages every time I head down this path.  I'd like to
explore scaling alternatives for the routing system that aren't tied to
loc/id splits, but I have thus far failed to figure out what that might
possibly be.

I think you nailed it in terms of the dependencies.  I just don't like
them.

-David

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 27 Jun 2008 12:22:08 -0700

Dave,

> LISP, or something like it, would reduce the cost of multi-homing  

Since as Dino said in his e-mail "none of the LISP authors felt  
that LISP was the ultimate long-term solution", LISP may
not matter over the long term, and therefore it really does not
matter whether LISP will reduce the cost of multi-homing _over the
long term_.
  
> everybody?  

Could you point me to any document that shows that mis-alignment
with LISP would be *significantly* less than with what we have today ?

Yakov.

---

From: "William Herrin" <[email-masked]>
Date: Fri, 27 Jun 2008 15:26:02 -0400

> to give; the only question is _which_.

Noel,

I also agree with this statement.

I note that it is predicated on the assumption that routing is
required to follow business relationships. If routing was allowed to
follow some more-aggregable criteria (e.g. geography) the statement
might not be true. However, I agree that routing is required to follow
business relationships.

Regards,
Bill Herrin

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 27 Jun 2008 12:35:38 -0700

Dino,

> about the increase in OpEx and control plane performance for the  

Wrt OpEx how exactly does LISP going to reduce it, and who are the
parties that are going to see that reduction ?

Wrt control plane performance, what are the problems that LISP is
going to solve ? And if there are already existing solutions to
these problems, then why LISP's solution is better ?

Yakov.

---

From: [email-masked]
Date: Fri, 27 Jun 2008 17:09:48 EDT

In einer eMail vom 27.06.2008 19:19:18 Westeuropäische Normalzeit schreibt  
[email-masked]:

If not,  then I think it would be interested to have people hum on i) do we
want  location/identity separation,

I certainly won't hum on i) we want location / identity separation but I  
would certainly hum on the separation between routing to the egress node and  
selecting the egress user at the egress node. The first part should be DONE  
RIGHT, as has been expressed my many people, which, by the way, requires a  strict 
 separation from the second part, i.e.  from  selecting of the egress user at 
the egress node.
 
Heiner

---

From: [email-masked]
Date: Fri, 27 Jun 2008 17:19:56 EDT

In einer eMail vom 27.06.2008 21:27:17 Westeuropäische Normalzeit schreibt  
[email-masked]:

Regards,
Bill Herrin

Bill, sorry, this is non-sense. Routing is required to get the packet to  the 
egress router.
E.g. along the shortest path. E.g. while conveying to policy/QoS  constraints.
 
Heiner

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 27 Jun 2008 14:25:15 -0700

Noel,

> and if not, why not? (Again, totally seriously.)

Sure, it is "a good move" provided that the cost is zero :-)

On a more serious note, you asking a wrong question. Here are some
of the more relevant questions to ask: (a) what are the benefits
of separating location and identity, (b) who is going to benefit
and who is going to bear the cost (both in the short and in the
long term), (c) could one benefit with only a partial deployment,
etc...

Yakov.

---

From: [email-masked]
Date: Fri, 27 Jun 2008 17:53:51 EDT

In einer eMail vom 27.06.2008 20:28:28 Westeuropäische Normalzeit schreibt  
[email-masked]:

Isn't a look at Google map helpful,e.g.showing a path from New York to San  
Francisco. If you scroll from the start to the destination at reasonably close  
zoom you will realize that, in comparison, the internet with e.g. 210 k DFZ  
-routers is  very very very small. And yet has this scalability problem !??  
IMO, Google ashames IETF.  The loc/id-split gets close to the problem, but  
still fails. It  is one part to get to the egress router, another one  to get 
from there to the egress user, and it is not the network layer's business  to 
care about    session layer's identifying points. There, I  guess, there is no 
problem. The problem is inside the network layer.
 
Heiner

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 27 Jun 2008 14:59:34 -0700

Dino,

> sites and SPs together). 

There is an important difference between NAT tables and LISP. NAT
table is a cache, but this cache is populated based only on the
information *local* to the NAT. In contrast, caches on LISP routers
can not be populated based only on the information local to the
routers, but require to acquire this information over the network.

> NAT has a major OpEx hit but again the  
> introducing anything monumentally new. 

Wrt "NAT has a major OpEx hit", the (very wide) deployment of NATs
should give you a hint that its benefits (significantly) outweight
its cost. And what matters is not whether one claims that it is "a
major OpEx hit", but that the experience showed that its benefits
justify its cost.  And yes, I know that some folks have a knee jerk
reaction when they hear the word "NAT".

> It's just BGP over tunnels and  

Here are few more management issues that you may consider:

4) Use of cache based routers, and not just cache-based routers, but 
   routers where the information needed to populate the forwarding 
   cache is not present on the routers.

5) Routers using of ICMP to determine reachability.
  
Btw, the above is by no means complete...

Yakov.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Jun 2008 10:20:47 +1200

On 2008-06-28 09:59, Yakov Rekhter wrote:
...
> reaction when they hear the word "NAT".

I think one of the undiscussed properties of NAT is that its OpEx
hit is disguised. We don't know how many help desk calls are a result
of undiagnosed NAT side-effects and we don't know how much end-user
time is wasted due to NAT state loss resulting in dropped sessions.
We do know that one help desk call wipes out a year's profit on
that subscriber, so I suspect that the hidden OpEx hit is quite
significant.

Unfortunately this doesn't change Yakov's argument, unless these
hidden costs can be measured and made explicit in customers' and
ISPs' books.

    Brian

---

From: "William Herrin" <[email-masked]>
Date: Fri, 27 Jun 2008 19:15:04 -0400

> might not be true. However, I agree that routing is required to follow

Apperantly I explained myself very poorly. Let me take another stab at it.

I used a trick here that often helps me see more sides of a problem: I
turned it upside down. I took the object as a given and looked for
things that would make it false.

Given: Any routing solution must either make changes to the host
software or maintain a big mapping database.

Query: What would make this statement false?

1. If we don't separate location and identity then this statement is
false because there is no map database, just a routing database.

2. If we find an algorithmic way to map identifiers to locations then
we'll have a map algorithm instead of a map database.

Such an algorithm has been proposed: geographic aggregation of IP
addresses coupled with geographic routing of those aggregates. The
scheme would require neither changes to the host nor a big mapping
database.

However, geographic routing violates a basic assumption: that the
routing must follow the business relationships between the various
entities. A is not permitted to send packets to B by way of C who has
no direct or indirect business relationship with either A or B.

If X follows from Y and Y follows from Z then X follows from Z. The
host-change-or-big-database statement would be falsified if we were
permitted to design a protocol that did not follow the business
relationships between the parties using it, even if we do a LOC/ID
split.

That's not exactly a shocking insight. Since it was the only other
falsifier I found that wasn't either completely absurd or already
covered, it seemed worth pointing out.

Anyway, having determined that Noel's statement is falsifiable and
having found nothing that might reasonably falsify it, I agree with
statement.

Regards,
Bill Herrin

---

From: David Conrad <[email-masked]>
Date: Fri, 27 Jun 2008 17:41:26 -0700

Yakov

> matter whether LISP will reduce the cost of multi-homing _over the

Sure it does.

Once you have separated the end point from how you get to the end  
point, you have much greater flexibility in re-architecting the  
"getting to the end point" part.  Regardless of whether LISP is the  
exact solution used in the long term, the fact that you have moved  
from something that you yourself have explained in great detail (back  
in 1996) is not scalable to something that will allow arbitrary  
scaling will reduce costs in the long term.

That is unless you've figured out how to flat route 128 bits...

Regard,
-drc

---

From: [email-masked]
Date: Sat, 28 Jun 2008 05:01:30 EDT

In einer eMail vom 28.06.2008 02:43:46 Westeuropäische Normalzeit schreibt  
[email-masked]:

Once you  have separated the end point from how you get to the end  
point, you  have much greater flexibility in re-architecting the  
"getting to the  end point" part.

This is truly a break-thru recognition after years of RRG activity where  
SEPARATION / SPLIT was focused on the wrong entities.
 
Heiner

---

From: David Conrad <[email-masked]>
Date: Sat, 28 Jun 2008 07:07:21 -0700

Yakov,

On Jun 27, 2008, at 2:25 PM, Yakov Rekhter wrote:
> (a) what are the benefits of separating location and identity,

To state the obvious, by divorcing the identity from the location, you  
allow that identity to "easily" change location.  Conceptually, the  
benefits of such a split would include:

- end users/sites having multiple providers (multihoming) without  
having to participate in the locator routing system
- end users/sites changing from one provider to another over a long  
time period (i.e., changing ISPs)
- end users/sites changing from one provider to another over short  
time periods (i.e., mobility, depending on how the mapping is performed)
- ISPs being able to rearrange network topology without significantly  
impacting network users
- ISPs being able to migrate to IPngng without significantly impacting  
network users
- removing the need for end users/sites to renumber (ever again)
- reducing or removing the need to assign end user/sites address space  
in a hierarchical manner
- avoiding the need of ISPs and end users/sites to deal with  
potentially multiple layers of NAT

There are probably other benefits I'm forgetting right now.

> (b) who is going to benefit and who is going to bear the cost (both  
> in the short and in the

> long term),

Both end users/sites and ISPs would benefit (see above).

There are multiple costs that would need to be born, varying depending  
on implementation.  In general, there would be the capital cost of the  
deployment of ITR/ETR devices or redeployment of network stacks.   
There would also be the cost of implementing, managing, and  
distributing the locator/identifier mappings, potentially including  
the cost of the mapping device(s).  In non-capital costs, depending on  
how the mapping was implemented, you would have either increased  
latency for at least the first packet in a new transaction (in a  
"pull" model) or increased traffic and memory requirements (in a  
"push" model).

There are probably other costs I'm forgetting right now.

> (c) could one benefit with only a partial deployment,

I suppose it depends on what you mean by partial deployment.  One can  
imagine scenarios where you have incremental deployment amongst  
cooperating ISPs, but one of the hardest problems to solve is how you  
have asymmetrical deployment (that is, where an end/user site has  
migrated to the new system and wants to communicate with an end/user  
site that hasn't yet migrated).  Obviously, NAT deals with the  
asymmetrical deployment problem, but brings with it its own costs.

> etc...

While I agree that a cost/benefit analysis needs to be done, I think  
it worthwhile to keep in mind the alternatives.  The alternatives (as  
far as I am aware) are:

a) PI for everyone
b) NAT

I hope you'll agree that alternative (a) alone is not scalable in the  
long term.  One can imagine a scenario where you have a universe of  
NATs connected via PA assigned end points, however I'd argue this is  
actually a locator/ID split where the IDs are not globally unique.

Am I missing an alternative?

Regards,
-drc

---

From: "William Herrin" <[email-masked]>
Date: Sat, 28 Jun 2008 12:25:47 -0400

On Sat, Jun 28, 2008 at 10:07 AM, David Conrad <[email-masked]> wrote:
> While I agree that a cost/benefit analysis needs to be done, I think it
> worthwhile to keep in mind the alternatives.  The alternatives (as far as I
> am aware) are:
>
> a) PI for everyone

David,

If I understand your meaning here, I'd describe this as "BGP PI for
Everyone => Randy Bush's $10M routers."

> b) NAT
>
> I hope you'll agree that alternative (a) alone is not scalable in the long
> term.  One can imagine a scenario where you have a universe of NATs
> connected via PA assigned end points, however I'd argue this is actually a
> locator/ID split where the IDs are not globally unique.

I disagree with characterizing NAT as an alternative. NAT's likely
contribution to the routing problem is already represented in the
status quo. Unless you're aware of a clever new way to use NAT to
relieve routing pressure that isn't an obvious non-starter?

> Am I missing an alternative?

Two more:

1. Status Quo.

We continue to suppress table growth at the RIR level. Users continue
to spend uncounted manhours on renumbering tasks. Users continue to
lose productivity to address-state issues (e.g. spam filtering). The
indirect cost due to the BGP table size continues to creep northward,
helping squeeze out smaller ISPs. Mobility remains cumbersome. IPv6
without NAT remains nonviable because of the interior server
renumbering problem.

2. New IP layer-4 protocols and change everything up to layer 7.

Suppose that in addition to propagating routes, the routing protocol
also performs optimization of address assignments. That is, it
dynamically instructs "downstream" systems to change their addresses
in a manner that improves address aggregation "upstream."

In a perfect hierarchy you'd get perfect topological aggregation. The
internet is not a perfect hierarchy, so in order to still get good
aggregation you have to draw some line between systems large enough
that they won't accept renumbering requirements from their peers and
systems smaller than that which accomplish multihoming by acquiring
multiple address sets from each upstream hierarchy.

The only way to combine the two effectively is to remove identity from
layer 3 addressing altogether so that layer 3 addressing only reflects
the current locations within the topology.

That means you rebuild layer 4 to get node identity from some other
source than layer 3 and you propagate that change up the stack to
layer 7.

Regards,
Bill Herrin

---

From: David Conrad <[email-masked]>
Date: Sat, 28 Jun 2008 11:10:39 -0700

Bill,

> Everyone => Randy Bush's $10M routers."

Yep.

> relieve routing pressure that isn't an obvious non-starter?

The idea I've heard repeated is along the lines of the following  
scenario:

a) IPv4 address space becomes more expensive as the free pool exhausts
b) People with IPv4 space realize they can use NAT, renumber to  
private space, and sell off their IPv4 holdings.  This results in all  
an ISPs customers only needing a single PA address each.  The ISP can  
also offer a hosting service in which multiple customers share a  
single IP address in a virtual host web/smtp/whatever farm (each  
service being an additional cost, of course).
c) ISPs buy up the freed up IPv4 address space and use it to assign  
single public addresses to their customers.  Given the use of NAT,  
renumbering impact is limited to the ISP, thus it is feasible that  
ISPs can trade address blocks with each other in order to obtain  
larger contiguous blocks and reduce announcements.

In the end of this scenario, you have something that looks a bit like  
a final-state loc/id split albeit asymmetric instead of map-encap  
symmetric. Scaling concerns are greatly reduced (although not  
eliminated as 4 billion doesn't go as far as it used to).  Multi- 
homing (of a sort) is implemented by having multiple addresses from  
different providers on the CPE NAT box and playing stupid DNS games  
(e.g., short TTLs and dropping A RRs when connectivity failure is  
detected).

>> Am I missing an alternative?

I might argue that this isn't stable in the long term due to the way  
RIR policies are defined.  We've already seen a tendency towards PI- 
for-everyone at all of the RIRs.  I expect this to get better rather  
than worse over time.  However, I agree that it is an alternative,  
albeit perhaps only in the short-term.

> 2. New IP layer-4 protocols and change everything up to layer 7.

Agreed, although I'd hope that a new IP would implement some form of  
loc/id split.

Regards,
-drc

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 28 Jun 2008 11:58:41 -0700

> routers, but require to acquire this information over the network.

If we continue the NAT trend to connect ISPs together, it will no  
longer be local.

> reaction when they hear the word "NAT".

I was referring to how it could be used. There are parts of the world  
where they cannot get addresses so they implement multi-level NATs to  
solve the problem. In these cases, there is a huge OpEx cost.

>   cache is not present on the routers.

That is what LISP-ALT does.

> 5) Routers using of ICMP to determine reachability.

ICMP can help but by itself it not sufficient due to filtering. The  
main spec says that ITRs certainly should process ICMP unreachables  
when they are received.

> Btw, the above is by no means complete...

Add when you like.

> Yakov.

Thanks,
Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 28 Jun 2008 12:12:01 -0700

> matter whether LISP will reduce the cost of multi-homing _over the

But what if it does? Do you really want to play crystal ball and make  
such a bet?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 28 Jun 2008 12:18:41 -0700

> parties that are going to see that reduction ?

1) You can move BGP out of CPE routers. Cost goes down for sites when  
they don't have to worry about complex protocols.

2) You don't have to renumber sites ever again.

3) The level of indirection gives sites the freedom to change service  
providers if they are not satisfied with service or want to try a new  
service.

4) Sites can optimize on their CapEx by deciding how their egress  
*and* ingress traffic flows exit and enter the site, respectively.

> going to solve ? And if there are already existing solutions to

Look at the presentation we gave at the last RRG. We have stated the  
goals so many times.

> these problems, then why LISP's solution is better ?

End sites have told us they want to be good Internet citizens and not  
inject more specific routes into their attached ISPs. They'd be  
willing to deploy LISP for this sole purpose. They have to justify the  
cost of their links so today they have no choice.

Another very important point is that the expertise for running BGP in  
a multi-home site is not there, so sites have to out-source at huge  
costs so they can use their 2 ISP links.

We developers can implement the LISP protocol where it is nearly plug- 
and-play. That will reduce their out-sourcing costs.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 28 Jun 2008 12:32:52 -0700

> network-sized mapping database.

Okay, thanks for clarification.

> to give; the only question is _which_.

Well, I think you are right. That is the way I see it.

> the time we ask i), that it implies having to make a choice at ii).

Right.

>> gone

That is the reason I call a solution like LISP more shorter-term in  
the grand scheme of things.

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 28 Jun 2008 17:05:22 -0400

On Jun 28, 2008, at 3:12 PM, Dino Farinacci wrote:

> But what if it does? Do you really want to play crystal ball and  
> make such a bet?
>

Long before Alan Greenspan, someone said "There is nothing as  
permanent as the temporary."

That is not a bet I would like to make.

BTW, it might amuse people to see that SOHO multihoming is in slashdot  
today.

http://ask.slashdot.org/article.pl?sid=08/06/28/1728224

Regards
Marshall

---

From: Scott Brim <[email-masked]>
Date: Mon, 30 Jun 2008 09:32:05 -0400

On 6/28/08 3:32 PM, Dino Farinacci allegedly wrote:
>> Ah, I don't consider the location/identity split a 'routing
>> architecture'.  It's an ancillary aspect of the overall system
>> architecture, one which has at best some influence on particular
>> desired operational goals having to do with routing (e.g. provider
>> independence).
> 

How long is "short term"?  It would be great to start with a clean slate 
and produce a stupendous architecture, but we have an installed base, 
and besides which our ideas of what makes an architecture stupendous can 
change dramatically over time.  The problems are scaling and stability. 
  We want to solve them in a way that will sustain Internet growth, in 
multiple ways, for our foreseeable future, and will allow easy 
deployment of a new architecture when that one gets tired [cite: 
Feynman].  I think at least some of the ideas on the table can satisfy 
these requirements.  So if "short-term" means "until the Internet 
changes beyond what we currently conceive of" then I agree.

Scott

---

From: Scott Brim <[email-masked]>
Date: Mon, 30 Jun 2008 09:38:53 -0400

> in a manner that improves address aggregation "upstream."

Did you ever see Paul Francis's PIP?

---

From: "William Herrin" <[email-masked]>
Date: Mon, 30 Jun 2008 09:58:50 -0400

On Sat, Jun 28, 2008 at 2:10 PM, David Conrad <[email-masked]> wrote:
> The idea I've heard repeated is along the lines of the following scenario:
>
> b) People with IPv4 space realize they can use NAT, renumber to private
> space, and sell off their IPv4 holdings.  This results in all an ISPs
> customers only needing a single PA address each.  The ISP can also offer a
> hosting service in which multiple customers share a single IP address in a
> virtual host web/smtp/whatever farm (each service being an additional cost,
> of course).
> c) ISPs buy up the freed up IPv4 address space and use it to assign single
> public addresses to their customers.  Given the use of NAT, renumbering
> impact is limited to the ISP, thus it is feasible that ISPs can trade
> address blocks with each other in order to obtain larger contiguous blocks
> and reduce announcements.
>
> In the end of this scenario, you have something that looks a bit like a
> final-state loc/id split albeit asymmetric instead of map-encap symmetric.
> Scaling concerns are greatly reduced (although not eliminated as 4 billion
> doesn't go as far as it used to).  Multi-homing (of a sort) is implemented
> by having multiple addresses from different providers on the CPE NAT box and
> playing stupid DNS games (e.g., short TTLs and dropping A RRs when
> connectivity failure is detected).

Hi David,

That boils down to: economic pressures recover PI space and reduce the
AS to announcements ratio. DNS games solve the small-player
multihoming problem.

I'll take the latter part first: operationally, DNS games for
multihoming has been demonstrated to be inadequate. The past decade
has seen the opposite movement: where services tolerant of spreading
load to multiple IP addresses like http and DNS itself have been
pulled back inward via things like anycasting and load balancers which
make multiple web servers appear under the same address. Things like
DNS SRV records which were supposed to help avoid this are virtually
unused. Customer rejection of DNS for resilience and local traffic
engineering is unambiguous.

That's not to say that DNS has been useless in this space. Services
like Akamai prove otherwise. However, DNS's positive impact has been
limited and very application dependent.

For the first part, I'd point out that the number of existing PI
assignments actually routed on the Internet is not sufficient to make
the problem equation meaningfully different. Further, the economic
pressures are all wrong for it happen: ISPs and Universities are poor.
Contractors are rich. The pressure will be to roll the residential
users of your /16 into several /24's fronting NATs and then sell the
other /24's in the /16 to small-but-well-funded projects that
absolutely-must-have reliability and can easily afford another $10k to
$50k to get it.

At the very least, this NAT approach is less likely to be valid than
the status quo.

>> 1. Status Quo.
>
> I might argue that this isn't stable in the long term due to the way RIR
> policies are defined.

I'd like to agree but the numbers point the other direction. My best
guess is that under the status quo the IPv4 route table will finally
stabilize somewhere between 6M and 8M prefixes. The /24 restriction
can't be effectively eliminated under the status quo. With /24 as the
longest announceable prefix, the theoretical maximum number of routes
is 33M but the conditions which would push routes to more than 25% of
that max are fantastically improbable.

IPv6 could add an effectively unbounded addition to that, but unless
it gains a heck of a lot of momentum from somewhere, ditching
bare-on-the-wire IPv6 to keep your router costs down remains an easy
choice.

The point is that 8M prefixes is actually doable under the status quo
approach. It would keep all the negative factors of the status quo and
gain some additional indirect cost but it's within the bounds of
doable.

> Agreed, although I'd hope that a new IP would implement some form of loc/id
> split.

Subnet mask is a kind of LOC/ID split as well. Let's not broaden to
the LOC/ID-split concept to a point where it doesn't usefully describe
anything.

IMO, LOC/ID split means a layer-3 change so that the layer-3 node
identity is structurally separate from the network location. Things
like map-encap and ermpi6 ( http://bill.herrin.us/network/ermpi6.html
) qualify as LOC/ID split.

I suggest that's conceptually different than removing ID from layer 3
altogether so that the layer-3 addressing represents -only- network
location while node identity is established at a higher layer in the
stack.

Regards,
Bill

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 Jun 2008 07:34:41 -0700

> How long is "short term"?  It would be great to start with a clean  
> slate and produce a stupendous architecture, but we have an  
> installed base, and besides which our ideas of what makes an  
> architecture stupendous can change dramatically over time.  The  
> problems are scaling and stability.  We want to solve them in a way  
> that will sustain Internet growth, in multiple ways, for our  
> foreseeable future, and will allow easy deployment of a new  
> architecture when that one gets tired [cite: Feynman].  I think at  
> least some of the ideas on the table can satisfy these  
> requirements.  So if "short-term" means "until the Internet changes  
> beyond what we currently conceive of" then I agree.

I view short-term versus long-term in this context not based on the  
length of time the solution will suffice but what should start first  
with a bit more urgency and what should have more think time and not  
be as time critical to start.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Tue, 1 Jul 2008 18:33:51 -0700

[Catching up...] 

|    > I think the RRG has only focused on loc/id split and 
|really hasn't gone
|    > into greater depth with other routing architectures.
|
|Ah, I don't consider the location/identity split a 'routing 
|architecture'.
|It's an ancillary aspect of the overall system architecture, 
|one which has at
|best some influence on particular desired operational goals 
|having to do with
|routing (e.g. provider independence).
|
|To me, routing architectures are about things like 'what 
|entity choses the
|path the packets flow along', and 'how are those paths 
|computed', 'what data
|does that computation need', 'how is that data distributed', etc.
|network-sized-mapping-database.

As has been remarked before, routing and addressing are fundamentally
inseparable, and indeed our charter is to explore both routing and
addressing architectures.  To my mind, a locator/identifier split is a major
change in the addressing architecture that will fundamentally change the
scalability of the routing subsystem.

If folks have other tricks up their sleeve that result in improved routing
scalability, that's certainly most welcome.

Tony

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 2 Jul 2008 09:17:01 -0400 (EDT)

> From: "Tony Li" <[email-masked]>

    >> I don't consider the location/identity split a 'routing architecture'.
    >> It's an ancillary aspect of the overall system architecture
    >> ..
    >> To me, routing architectures are about things like 'what entity choses
    >> the path the packets flow along', and 'how are those paths computed',
    >> 'what data does that computation need', 'how is that data
    >> distributed', etc. 

    > routing and addressing are fundamentally inseparable

True, but addressing is just one aspect of a routing architecture - O() 20%
of the whole, I'd say.

    > a locator/identifier split is a major change in the addressing
    > architecture that will fundamentally change the scalability of the
    > routing subsystem.

Removing identification functionality from the routing-names makes their
assignment, etc, potentially more tractable. However, at the end of the day,
even with indentification functionality removed, you still have to figure out
lots of other things about routing-names: how you're going to assign them
(e.g. do they get renumbered automatically as topology changes, etc, etc);
how, and by whom, do abstraction naming boundaries get set; etc, etc. So
moving identification elsewhere isn't even the whole answer on routing-names,
let alone all of routing.

Look, I'm not trying to be a drip (although I'm probably succeeding all too
well). I just don't want us breaking our arms patting ourselves on the back.
Agreeing that we need separate namespaces for location and identity is nice,
but not exactly earth-shaking progress - altough in the I* these days, maybe
it actually is. :-(

	Noel

---

From: Peter Sherbin <[email-masked]>
Date: Wed, 2 Jul 2008 08:20:34 -0700 (PDT)

> As has been remarked before, routing and addressing are
> fundamentally inseparable...

It seems right but what is the basis for that statement? Does anyone has a mathematical formula that proves it?

Thanks,

Peter

--- On Tue, 7/1/08, Tony Li <[email-masked]> wrote:

> From: Tony Li <[email-masked]>
> Subject: RE: [RRG] Long term clean-slate only for the RRG?
> To: "'Noel Chiappa'" <[email-masked]>, [email-masked]
> Date: Tuesday, July 1, 2008, 9:33 PM
> [Catching up...] 
>

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 2 Jul 2008 11:59:35 -0400 (EDT)

> From: Peter Sherbin <[email-masked]>

    >> inseparable...

    > It seems right but what is the basis for that statement? Does anyone
    > has a mathematical formula that proves it?

Addresses (routing-names) are the data that path-selection (routing) works
on. As such, they are inherently inseparable.

	Noel

---

From: Scott Brim <[email-masked]>
Date: Wed, 02 Jul 2008 12:10:46 -0400

> on. As such, they are inherently inseparable.

I have trouble seeing them as tightly bound.  Routing is mechanisms for 
passing around information in support of path discovery and selection. 
The information is about routing-names but the form of those names has 
only limited influence on the information about those names that needs 
to be transferred, and even less on the mechanisms by which it is 
transferred or used.  ??

Scott

---

From: Robert Bonomi <[email-masked]>
Date: Wed, 2 Jul 2008 15:41:20 -0500 (CDT)

> From [email-masked]  Wed Jul  2 11:15:43 2008
> Date: Wed, 02 Jul 2008 12:10:46 -0400
> From: Scott Brim <[email-masked]>
> To: Noel Chiappa <[email-masked]>
> CC: [email-masked]

Here we go with the terminology problem -- specifically the multiple,
overlaid, meanings attached to the symbol "address".   <sigh>

'Routing' is _not_ bound to the 'identifiers' used to specify destination
objects.

"Routing" _is_ inextricably bound to a location-specifying attribute of
the object which the 'identifier' _names_.

In present-day IP routing object label called the "IP Address" is used 
both as the identifier, and as the location-specifying attribute.

_Internal_ routing within a single network is closely, if not inextricably,
bound to the unique label that specifies the object's location on the
network -- thhe "IP address".

*External* routing is not so constrained.  One can use _any_ attribute of
the object that is sufficient to uniquely identify the specific network
to which it is connected.  One could easily build an '_external_ routing 
protocol/technology' that uses "AS numbers" as the 'where to go' specifiers. 
Use currently-existing routing technology _within_ an AS, but for traffic 
_leaving_ the AS -- and the obvious place to implement this is _at_ the AS 
border -- look up the "destination AS" for the destination 'address' and 
forward to the "next-hop AS" for that destination AS. 

Implementation details: One could (a) record the  source/dest AS in a new 
'transit packet' header, and use that, now embedded, "locator" information 
for all subsequent routing until the packet is delivered to the destination 
AS -- where the transit header would be stripped, and the 'local' routing 
protocol then used to reach the actual destination location.  *OR*, one could 
(b) do the 'destination location to servicing AS' lookup at each router, to 
get the destination AS, and select the 'next AS' based on that.  Approach (b) 
would appear to be prohibitively expensive, based solely on a very superficial 
look.  Approach (a) is little different in cost from any existing tunnelling
and/or encapsulation methodology, and should be workable and feasible.
This is, functionally, a map-and-encapsulate, using the AS no. as the locator.

---

From: "Tony Li" <[email-masked]>
Date: Wed, 2 Jul 2008 13:58:06 -0700

|Agreeing that we need separate namespaces for location and 
|identity is nice,
|but not exactly earth-shaking progress - altough in the I* 
|these days, maybe
|it actually is. :-(

Agreeing that we need separate namespaces is far less significant than
agreeing on *how* we are going to separate those namespaces and preserve
functionality.  That would definitely be significant forward progress.

Tony

---

From: Scott Brim <[email-masked]>
Date: Wed, 02 Jul 2008 17:18:35 -0400

> both as the identifier, and as the location-specifying attribute.

... if the routing-name has such a location-specifying attribute.  I 
suggest that 128.84.253.16 has no location-specifying attribute of its 
own.  It is only routing mechanisms that discover/provide information on 
where it might be.  Granted there are some ways of constructing 
routing-names that build location information into them (for use by 
routing), but the current IP address is not one of them.

> network -- thhe "IP address".

But it doesn't specify the object's location.

---

From: "Tony Li" <[email-masked]>
Date: Wed, 2 Jul 2008 14:41:42 -0700

|> In present-day IP routing object label called the "IP 
|Address" is used 
|> both as the identifier, and as the location-specifying attribute.
|
|... if the routing-name has such a location-specifying attribute.  I 
|suggest that 128.84.253.16 has no location-specifying attribute of its 
|own.  It is only routing mechanisms that discover/provide 
|information on 
|where it might be.  Granted there are some ways of constructing 
|routing-names that build location information into them (for use by 
|routing), but the current IP address is not one of them.

More semantics...  A locator is simply a token assigned to a particular
topological location.  You are correct, the routing mechanisms discover and
distribute that assignment.  It is a correspondence to topology, not a
specification of the topology.

Are we done with the nits yet?

Tony

---

From: "William Herrin" <[email-masked]>
Date: Wed, 2 Jul 2008 17:42:45 -0400

Noel,

That rather depends on the architecture. If you take the tack I posted
about recently (ephemeral locater-only addresses at layer 3), address
assignment, deprecation, revocation and reassignment becomes more like
80% of the routing protocol's job. The rest looks a lot like other
routing protocols now but with a fraction of the routes due to very
effective address aggregation.

> on. As such, they are inherently inseparable.

Layer-3 addresses presently describe two characteristics of the
endpoint: its network location and its identity. In a clean slate
environment, it is not obvious to me that path-selection need know
anything about the identity part; it need only know about one of the
network locations.

If you take identity out of layer 3 entirely and insist that layer 4
use the layer-3 IP address no more than layer 3 uses the layer-2 MAC
address, a lot of really interesting things become possible in the
routing/addressing space.

It occurs to me as we talk about splitting locaters from identity, we
may be saying that OSI layer 3 is conceptually wrong. We need to
establish a node identity somewhere beneath the transport layer but
above the routing at the network layer. Is there a layer missing
between 3 and 4?

Regards,
Bill Herrin

---

From: [email-masked]
Date: Thu, 3 Jul 2008 03:49:45 EDT

In einer eMail vom 02.07.2008 23:43:24 Westeuropäische Normalzeit schreibt  
[email-masked]:

Right. I'd call it "learning from the postman".A letter isn't checked at  the 
ingress postal office whether it is deliverable or not (whether the receiver  
has or has not moved to some other place). Instead it is forwarded to the 
egress  postal office without such checking. No attempt is made neither as to  
inform, world-wide, any postal office when someone moves to another  place. 
Every year many new residential areas are going to be developed, but  no postman 
has ever complained about an (increasing) scalability problem.
 
Heiner
 
PS: The RRG may invite Dublin's postmen and ask them for advice. However,it  
might happen that they can't provide good advice.The reason: They might be  
confused after getting a quick update about the last year's RRG-mailinglist  
discussion :-)

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 3 Jul 2008 10:28:15 +0200

----- Original Message -----
From: "Noel Chiappa" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 26, 2008 4:41 PM
Subject: Re: [RRG] Long term clean-slate only for the RRG?

> (along with its attendent maintainence/deployment/etc costs).
Mulling this over, I think that the answer is not quite, at least theoretically.
That is, you need to translate between location and identity, and calling those
two numberspaces for the purposes of this (I know, others will call them one
numberspace), then a database is one way and gives you full flexibility as to
how the translation is done.  But an algorithm, such as a hash, could translate
between a numberspace containing a  24/32/64/128 bit identity and numberspace
with a 22 bit locator (assuming that FIBs will handle an entire number space of
22 bits, or even 23,  in future).

Of course, it is the distribution of numbers within the identity numberspace
that makes it unlikely that such an algorithm would yield a suitable result but
who knows?

Or put differently, there is another constraint, which you have not stated, on
the distribution of numbers in the identity numberspace, and their allocation to
organisations such as ISPs, that means a network sized database is probably the
only answer, but, as has been said before, this is a research group.

Tom Petch

---

From: "William Herrin" <[email-masked]>
Date: Thu, 3 Jul 2008 15:45:58 -0400

On Thu, Jul 3, 2008 at 3:49 AM,  <[email-masked]> wrote:
> inform, world-wide, any postal office when someone moves to another
> place. Every year many new residential areas are going to be developed, but
> no postman has ever complained about an (increasing) scalability problem.

Heiner,

I'm not sure that speaks to the question. Let me borrow your analogy:

Line 1: William Herrin
Line 2: 3005 Crane Drive
Line 3: Falls Church, VA 22042
Line 4: United States

Your point is that a post office in Dublin need not know about 3005
Crane Drive. It need only get the mail to the US. The first post
office in the US need not know about Crane Drive either; it need only
get the mail to the post office for 22042. The post office for 22042
does, however, need to know how to get to 3005 Crane Drive.

While that's undoubtedly true, all of lines 2 through 4 are used for
path selection at various stages of the letter's trip. As Noel said,
they are inherently inseparable from the path selection process.. I
could not, for example, tell the post office in Dublin to deliver a
letter to "3005 Crane Drive, United States" or "Falls Church VA,
United States."  It wouldn't reach me.

-MY- point was that Line 1 need not be there at all. It is an
identifier which serves no role in the routing. If you get line 1
wrong or leave it off entirely your letter will still get to me.

Line 1 is valuable for other purposes. I generally round-file letters
addressed to "Current Resident" and I wouldn't want to accidentally
open someone else's mail. However, there is no inherent reason that
"William Herrin" must be a part of the address. It would be just as
functional if I found it on a second envelope enclosed in the first.

This is important, because as it turns out, letters address to:

Line 1: William Herrin
Line 2: 6857 Lafayette Park Drive
Line 3: Annandale, VA 22003
Line 4: United States

will ALSO get to me, albeit a little more slowly. The person with my
identity is reachable at multiple locations each of which can be
described in a manner close enough to a hierarchy to be efficient.

Regards,
Bill Herrin

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Jul 2008 17:04:00 -0400

> wrong or leave it off entirely your letter will still get to me.

It's a port selector.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Jul 2008 17:23:50 -0400

The analogy between street addresses and packet addresses for routing 
has MANY weaknesses.
Street routing relies on the fact that connectivity is highly meshed. 
And that streets are generally free for anyone to use.
Further, street routing relies on the fact that there is a human being 
who can learn and adapt his behavior, if the basic routing fails.  If 
you can not get to your destination from the obvious exit from the 
highway, you can get back on, and try another exit.  or even call for 
help as to how to get to the destination.  Packets are not so 
intelligent.   (Tunnels and lookup tables approximate many of these same 
techniques.  But they are not the same as having a human at the wheel of 
a car.)  The many interesting reports of people driving into trouble 
because the nav system said to do something foolish are indicative of 
what happens if you try to use a street oriented routing system without 
an intelligence in place.

Yes, once could imagine a world in which connectivity is mandated and 
maintained such that street-like routing will work.  But unless we want 
to change the regulatory and business structures of base IP 
connectivity, we do not live in that world.
(If we are willing to make that degree of change, something like compact 
routing becomes far more interesting, as that requires explicit and 
predictable resource sharing.)

Yours,
Joel

---

From: [email-masked]
Date: Thu, 3 Jul 2008 17:58:08 EDT

In einer eMail vom 03.07.2008 21:47:51 Westeuropäische Normalzeit schreibt  
[email-masked]:

Heiner,

Line 1: William Herrin
Line 2: 3005 Crane  Drive

Correct

Correct

And this is precisely MY point, too:-)
Ignore line 1 before the letter hasn't reach the egress post  office.
(maybe we should "invent"  MPLS-2 :-).

Line 1: William Herrin

will ALSO get to me, albeit a little more slowly. The person  with my
identity is reachable at multiple locations each of which can  be
described in a manner close enough to a hierarchy to be  efficient.
I can imagine similar situations:Routing to the egress node based on lines  
2-4 combined with line 1 ="to all residents there"
 
Heiner

---

From: [email-masked]
Date: Thu, 3 Jul 2008 18:07:03 EDT

In einer eMail vom 03.07.2008 23:05:12 Westeuropäische Normalzeit schreibt  
[email-masked]:

It's a port  selector.

Scott,
You have in mind the id from the loc/id-split, that's why you say port. But  
this is not correct. Line 1 indicates how to get, from that "egress  node", to 
the receiver.(whatever this egress node is: the true egress node,  or some 
egress-CE node, or some egress-PE node)
 
Heiner

---

From: [email-masked]
Date: Thu, 3 Jul 2008 18:27:09 EDT

In einer eMail vom 03.07.2008 23:25:53 Westeuropäische Normalzeit schreibt  
[email-masked]:

This is why we should do research: to do packet !!! routing better than is  
the current practice as you describe.

Yes, once could imagine a world in which connectivity is  mandated and 
maintained such that street-like routing will work.  But  unless we want 
to change the regulatory and business structures of base IP  
connectivity, we do not live in that world.
The postal address with street number, street, zip,... is only an analogy.  I 
do not propagate postal addresses
for packet routing.

I have read those papers about compact routing. There I learnt about  
"stretch":-(
I think I can provide much better routing algorithms and concepts (btw,  also 
to improve ipfrr significantly).
But if you want, then my "topology aggregation" is also somehow "compact  
routing" :-)
 
Heiner

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jul 2008 10:36:06 +1200

> Street routing relies on the fact that connectivity is highly meshed.

And just to be clear, BGP4 routing is not highly meshed. I happened
to look at the potaroo.net data yesterday.

86.3% of active autonomous systems are purely originators of
routes (stubs), 13.4% also provide transit, and 0.3% are pure
transit systems. 42% of autonomous systems originate only one prefix.

    Brian

---

From: [email-masked]
Date: Thu, 3 Jul 2008 18:48:13 EDT

In einer eMail vom 04.07.2008 00:37:29 Westeuropäische Normalzeit schreibt  
[email-masked]:

> Street routing relies on the fact that connectivity is  highly meshed.
I do not understand what these 2 sentences mean.

Brian

Also, the internet is a very very small network compared with the network  of 
the roads and streets.
But, see above, I do not understand. For an algorithm I doesn't matter  
whether the network is tightly meshed or lesser meshed.It would only matter, if  
there were no single mesh at all.
 
Heiner

---

From: "William Herrin" <[email-masked]>
Date: Thu, 3 Jul 2008 19:00:02 -0400

> (maybe we should "invent"  MPLS-2 :-).

No, no, a thousand times no. My point was NOT that you can ignore line
1 until condition X. My point was that you can remove line 1 from the
envelope -completely- and the postal routing system still delivers the
letter correctly.

Drawing the analogy back to it's origin, my point was that in a
clean-slate system, node identity doesn't belong at layer 3. It
belongs above layer 3, either in a layer 3b or in layer 4. ONLY
network location belongs in layer 3. And network location is a
fundamentally ephemeral thing; it changes constantly with your node's
geographical movement and with the the ups and downs of the network's
interconnections.

As for MPLS, who wants to argue that MPLS -is-not- a map-encap protocol? Not me.

On Thu, Jul 3, 2008 at 6:36 PM, Brian E Carpenter
<[email-masked]> wrote:
> And just to be clear, BGP4 routing is not highly meshed.

I wonder what percentage of streets are cul-de-sacs?

Last month, thunderstorms took out power to about a quarter of
Northern Virginia. With most of the traffic lights out and not enough
police to direct traffic, the commute home was horrid. After averaging
about a mile an hour down one street, I pulled out my laptop and GPS
to try to find some neighborhood roads that would get me there. No
such luck: all the turns that didn't dead-end just ended up right back
on the same street.

On Thu, Jul 3, 2008 at 5:04 PM, Scott Brim <[email-masked]> wrote:
> [Postal address line 1 is] a port selector.

You may be right. Perhaps our problem with scalable routing is that
we've allowed layer-4 identity to leak into layer 3. Fix the layer-4
problem and a clean layer-3 routing/addressing solution comes into
focus.

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 04 Jul 2008 13:06:56 +1200

> there were no single mesh at all.

I'm sure that statement is true as a matter of graph theory. But we're
concerned here with scalability of practical distributed routing
algorithms, and meshiness has a big impact on aggregation. Since the
relatively small amount of meshiness seems to be a result of the
interaction of BGP4's design with the free-market economics of ISPs,
it isn't a parameter we can tune at will. (I think that's the basic
problem many people have with NIRA or *any* geographic scheme - it
seems to assume arbitrary meshing in a given geography in order to
scale well, and the Internet isn't like that.)

    Brian

---

From: [email-masked]
Date: Fri, 4 Jul 2008 04:30:34 EDT

In einer eMail vom 04.07.2008 03:09:29 Westeuropäische Normalzeit schreibt  
[email-masked]:

For an  algorithm it doesn't matter  

Brian

Well, an architecture is more than a single aspect and "my" architecture is  
not based on DV like BGP but based on Dijkstra and even on better usage of  
Dijkstra. You may  utilize geographic data for the sake of DV as well, but  this 
is not my thinking at all. More general: You may utilize  geographic  data in 
many ways - in more as well in less obvious ways.
 
The mentioned little meshiness is due to the fact that the intra-domain ISP  
network is not adequately integrated into the inter-domain view (or better  
said: not at all).
 
Again, architecture is more than one aspect and research should start by  
questioning the old paradigms.
Is Distance-Vector sacrosanct or not ? 
 
Another analogy :-)
Modern soccer is  "one-touch-only ball forwarding". What about  
"one-touch-only packet forwarding" ??!!
 
Heiner

Heiner

---

From: [email-masked]
Date: Fri, 4 Jul 2008 09:29:19 EDT

No, no, a thousand times no. My point  was NOT that you can ignore line
1 until condition X. My point was that you  can remove line 1 from the
envelope -completely- and the postal routing  system still delivers the
letter correctly.
ok. Nevertheless there are certain interesting points on the delivery path,  
which are worth to think about.

As for MPLS, who wants to argue that  MPLS -is-not- a map-encap protocol? Not 
me.

You are absolutely right. Properly done there were no need for a label  
distribution mechanism (LDP). A wrt to routing useful data would already be  there, 
without distribution.

Huuh.

Maybe this is an additional problem.
 
Take care Bill while commuting,
Heiner

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 4 Jul 2008 07:55:44 -0700 (PDT)

-MY- point was that Line 1 need not be there at all. It is an
identifier which serves no role in the routing.

It sure does as long as there are more than one person living at the same address. The selection does not stop until it reached the "end". This is why defining the end point is critical. It will help with setting all of the identifier properties.

Thanks,

Peter

--- On Thu, 7/3/08, William Herrin <[email-masked]> wrote:

> From: William Herrin <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Date: Thursday, July 3, 2008, 3:45 PM

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 4 Jul 2008 11:04:26 -0400

It is not clear to me how any of this discussion helps routing  
research for the Internet.

Regards
Marshall

On Jul 4, 2008, at 10:55 AM, Peter Sherbin wrote:

> It sure does as long as there are more than one person living at the  
> same address. The selection does not stop until it reached the  
> "end". This is why defining the end point is critical. It will help  
> with setting all of the identifier properties.
>
> Thanks,
>
> Peter
>
>

---

From: Peter Sherbin <[email-masked]>
Date: Fri, 4 Jul 2008 08:23:41 -0700 (PDT)

> It is not clear to me how any of this discussion helps
> routing research for the Internet.

Would you please present a formal step by step research process, where it start, what is the final goal, the action items list, progress log, etc.? IMO the starting point for any construct is setting fundamental building blocks. In this particular case that would be a clear definition of basic networking elements. While people refer to a lot of terms as "loaded" there is an opportunity to adjust existing definitions for purposes of this research.

Thanks,

Peter  

--- On Fri, 7/4/08, Marshall Eubanks <[email-masked]> wrote:

> From: Marshall Eubanks <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], "William Herrin" <[email-masked]>, [email-masked], [email-masked]
> Date: Friday, July 4, 2008, 11:04 AM
> >>>> endpoint: its network location and its
> identity.
> >> In a clean slate
> >>>> anything about the identity part; it need
> only
> >> know about one of the
> >>>> network locations.
> >>>
> >>> ingress postal office whether it is
> deliverable or not
> >> (whether the receiver
> >>> has or has not moved to some other place).
> Instead it
> >> is forwarded to the
> >>> egress postal office without such checking. No
> attempt
> >> is made neither as to
> >>> inform, world-wide, any postal office when
> someone
> >> moves to another
> >>> place. Every year many new residential areas
> are going
> >> to be developed, but
> >>> no postman has ever complained about an
> (increasing)
> >> scalability problem.
> >>
> >> Heiner,
> >>
> >> I'm not sure that speaks to the question. Let
> me borrow
> >> your analogy:
> >>
> >> Line 1: William Herrin
> >> Line 2: 3005 Crane Drive
> >> Your point is that a post office in Dublin need
> not know
> >> about 3005
> >> Crane Drive. It need only get the mail to the US.
> The first
> >> post
> >> office in the US need not know about Crane Drive
> either; it
> >> need only
> >> get the mail to the post office for 22042. The
> post office
> >> for 22042
> >> While that's undoubtedly true, all of lines 2
> through 4
> >> are used for
> >> path selection at various stages of the
> letter's trip.
> >> As Noel said,
> >> they are inherently inseparable from the path
> selection
> >> process.. I
> >> could not, for example, tell the post office in
> Dublin to
> >> deliver a
> >> letter to "3005 Crane Drive, United
> States" or
> >> "Falls Church VA,
> >> -MY- point was that Line 1 need not be there at
> all. It is
> >> an
> >> identifier which serves no role in the routing. If
> you get
> >> line 1
> >> wrong or leave it off entirely your letter will
> still get
> >> to me.
> >>
> >> open someone else's mail. However, there is no
> inherent
> >> reason that
> >> "William Herrin" must be a part of the
> address.
> >> It would be just as
> >> functional if I found it on a second envelope
> enclosed in
> >> the first.
> >>
> >> This is important, because as it turns out,
> letters address
> >> to:
> >>
> >> Line 1: William Herrin
> >> will ALSO get to me, albeit a little more slowly.
> The
> >> person with my
> >> identity is reachable at multiple locations each
> of which
> >> can be
> >> described in a manner close enough to a hierarchy
> to be
> >> efficient.
> >>
> >> Regards,
> >> Bill Herrin
> >>
> >>
> >> -- 
> >> William D. Herrin ................
> [email-masked]
> >> [email-masked]
> >> to unsubscribe send a message to
> [email-masked] with
> >> the
> >> word 'unsubscribe' in a single line as the
> message
> >> text body.

---

From: "William Herrin" <[email-masked]>
Date: Fri, 4 Jul 2008 11:38:47 -0400

On Fri, Jul 4, 2008 at 10:55 AM, Peter Sherbin <[email-masked]> wrote:
> same address. The selection does not stop until it reached
> the "end". This is why defining the end point is critical. It will help

Not so! Once the letter has reached the address, folks at the address
are allowed to open the letter and make further decisions based on
what's inside, handing it to a human being, the trash can or even back
to the post office with a new address.

On Fri, Jul 4, 2008 at 11:04 AM, Marshall Eubanks <[email-masked]> wrote:
> It is not clear to me how any of this discussion helps routing research for
> the Internet.

Follow the logic chain:

A. -IF- topological address aggregation was practical, the route
scalability problem could be readily solved by aggregating routes
based on the address aggregation.

B. Topological address aggregation would be practical -IF- any
endpoint's layer 3 address could be routinely and recursively
reassigned by the "upstream" routers through an address assignment
protocol without disrupting layer 4 AND the node could sensibly handle
multiple defaults with multiple source addresses via a routing policy
protocol.

C. An ephemeral address which changes without disturbing layer 4 would
be possible -IF- the node identity value used by layers 4 and above
WAS NOT derived from the layer 3 address. In other words, make layer 4
treat the layer 3 address the way layer 3 treats the layer 2 address.

Therefore, we can solve the scalability problem through topological
address aggregation -IF- we remove -identity- from protocol layer 3.

So, the relevance of the discussion about the name (line 1) in a
postal address is this: The name (identity) obviously isn't needed for
the post office to successfully route the letter. Routing still works
if your name isn't present on the envelope. If the same is true of
network packets in a hypothetical architecture (and it should be) then
we can solve the layer 3 routing problem by changing how the layer 4
protocols determine a node's identity.

After all, I'm not "3005 Crane Drive," I'm "William Herrin." And the
post office can deliver mail to "3005 Crane Drive" without knowing
whether it's intended for "William Herrin." Fix how layer 4 handles
host identity and the layer-3 routing system no longer needs to manage
a large database.

Of course, layer 4 now needs to manage a large map from identities to
their current locations, but we've already seen that well handled by
(insert drum roll) DNS.

Regards,
Bill Herrin

---

From: [email-masked]
Date: Fri, 4 Jul 2008 12:30:09 EDT

In einer eMail vom 04.07.2008 17:38:59 Westeuropäische Normalzeit schreibt  
[email-masked]:

After  all, I'm not "3005 Crane Drive," I'm "William Herrin." And the
post office  can deliver mail to "3005 Crane Drive" without knowing
whether it's  intended for "William Herrin." 

..and may even do so as long as "3005 Crane Drive" exists - even after  
"William Herrin" has moved to another place!
 
Heiner

---

From: "William Herrin" <[email-masked]>
Date: Fri, 4 Jul 2008 13:51:03 -0400

> "William Herrin" has moved to another place!

That's a problem for the layer-4 retry algorithm. Finding someone who
has moved isn't really layer 3's job. Layer 3's job is just getting
the packet to the specified location.

-Bill

---

From: "William Herrin" <[email-masked]>
Date: Fri, 4 Jul 2008 13:51:03 -0400

-Bill

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 7 Jul 2008 05:16:41 -0700 (PDT)

Yes and there is a consensus on that, right?

Thanks,

Peter

--- On Fri, 7/4/08, William Herrin <[email-masked]> wrote:

> Cc: [email-masked], [email-masked], [email-masked]
> Date: Friday, July 4, 2008, 11:38 AM
> all. It is an
> Fix how layer 4 handles

---

From: "William Herrin" <[email-masked]>
Date: Mon, 7 Jul 2008 10:00:35 -0400

> Yes and there is a consensus on that, right?

Peter,

It is a testable hypothesis that hasn't been disproven.

This is a research group, yes? For this branch, there aren't yet any
questions for which consensus would be an appropriate tool.

Regards,
Bill Herrin

---

From: [email-masked]
Date: Mon, 7 Jul 2008 12:46:16 EDT

Peter,
I think, I did outline MY kind of clean-slate solution which is based  on 
topology aggregation and NOT on topology address aggregation (in the shortest  
email-thread possible). I expressed why I can't display all of the solution at  
the moment but I was clearly pointing out that the scalability problem is an  
immanent problem of the DV- and address aggregating concept. I also launched 
the  postal delivery service discussion as to demonstrate this, i.e. that 
forwarding  inside much bigger networks while using another paradigm would never 
have this  problem. Hereby, it seems that my position has been understood.
 
drc wrote, not long ago:

IMO: Excellent, particularly, if said in view of my solution. 

Heiner 

In einer eMail vom 07.07.2008 14:19:07 Westeuropäische Normalzeit schreibt  
[email-masked]:

Thanks,

Peter

---

From: Scott Brim <[email-masked]>
Date: Thu, 10 Jul 2008 07:09:52 -0400

> As for MPLS, who wants to argue that MPLS -is-not- a map-encap protocol? Not me.

There are some noticeable differences, mainly that the (current)
map-and-encap schemes use IP routing and forwarding as they are today.
There is no setup phase for encapsulating a packet, and a core
forwarder does not discriminate between an encapsulated packet and a
non-encapsulated packet.  With MPLS, forwarding depends on
pre-establishment of a path.  Labels have no topological significance
and are not forwardable until the per-label forwarding behavior is
installed in the nodes along a path.  They don't aggregate.

---

From: "William Herrin" <[email-masked]>
Date: Thu, 10 Jul 2008 08:22:03 -0400

On Thu, Jul 10, 2008 at 7:09 AM, Scott Brim <[email-masked]> wrote:
> non-encapsulated packet.

Scott,

Distribution of the routes to the decapsulation nodes is a setup phase
radically different in the overview than distribution of an MPLS
label?

>  With MPLS, forwarding depends on

As we're finding to our chagrin, neither to IP addresses.

Regards,
Bill Herrin

---

From: Scott Brim <[email-masked]>
Date: Thu, 10 Jul 2008 08:31:54 -0400

> radically different in the overview than distribution of an MPLS

Indeed.  It has nothing to do with installing state in intermediate
forwarders.

---

From: [email-masked]
Date: Thu, 10 Jul 2008 09:04:48 EDT

In einer eMail vom 10.07.2008 14:23:35 Westeuropäische Normalzeit schreibt  
[email-masked]:

Scott,

But geographical labelling does, and, it does NOT need any  distribution 
mechanism.
Heiner

Regards,
Bill Herrin

---

From: "William Herrin" <[email-masked]>
Date: Thu, 10 Jul 2008 09:46:39 -0400

Scott,

I must be completely missing your point. That statement parses like
nonsense to me. Of course both MPLS and layer-3 routing protocols both
install state in intermediate forwarders. For MPLS, the state is the
action to take on the top label (generally moving the packet in a
particular direction). For a routing protocol like BGP, the state is
the direction in which to move packets whose destination address falls
within given prefixes.

Regards,
Bill

---

From: "Tony Li" <[email-masked]>
Date: Thu, 10 Jul 2008 10:59:04 -0700

|> Indeed.  It has nothing to do with installing state in intermediate
|> forwarders.
|
|I must be completely missing your point. That statement parses like
|nonsense to me. Of course both MPLS and layer-3 routing protocols both
|install state in intermediate forwarders. For MPLS, the state is the
|action to take on the top label (generally moving the packet in a
|particular direction). For a routing protocol like BGP, the state is
|the direction in which to move packets whose destination address falls
|within given prefixes.

Bill,

MPLS requires that you install state _per tunnel_ on intermediate
forwarders.  In other packet based tunnelling protocols, this is not
necessary.

Both MPLS and normal L3 protocols require routing state on intermediate
forwarders.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Thu, 10 Jul 2008 15:21:19 -0400

> Both MPLS and normal L3 protocols require routing state on intermediate

Hi Tony,

I'm still not following the distinction.

I thought the way MPLS worked was along these lines:

Router A announces, "I know what to do with label 555." This label is
distributed to the rest of the systems speaking MPLS. Any packets they
see where the top label is 555, they forward them in the direction
they consider optimal to reach router A.

Router A then speaks a routing protocol (e.g. BGP) to router B. There
are multiple MPLS routers in between the two but routers A and B are
speaking BGP directly to each other. Router A tells router B: "Any
IPv4 packets you want to send to me, label them 555 and move them
through MPLS."

As a result, router B can move packets to router A without the
intervening routers needing the full BGP table. They only need to know
label 555.

But that's map-encap in a nutshell. You map multiple discontiguous
address spans into a single label that represents those spans' shared
exit point. You then route through the intermediate (core backbone)
nodes on the (presumably) much smaller number of labels. Whether that
label is part of a completely different protocol (MPLS) or just a new
address in the same protocol, the map-destination-to-a-label,
encapsulate and route-on-the-label process is semantically the same.

Have I grossly misunderstood how MPLS works? What's the story?

-Bill

---

From: "Tony Li" <[email-masked]>
Date: Thu, 10 Jul 2008 15:01:16 -0700

Hi Bill, 

|Have I grossly misunderstood how MPLS works? What's the story?

You have one model of how MPLS operates.  However, another very common
deployment of MPLS is for TE purposes.  In this type of scenario, routing
protocols are deployed natively and their information is used for path
computation.  Note that path computation need not be (and frequently isn't)
simply just 'best effort'.  A signaling protocol is then used to go
hop-by-hop along the computed path and establish explicit state for each
LSP.  Again, this is significantly different than 'normal' tunneling (e.g.,
GRE) where only the endpoints hold tunnel state.

Now, obviously MPLS does meet the 'encap' requirement, and for any tunnel to
be effective, there is some mapping that directs traffic down the tunnel, so
to be liberal, one could say that 'map-and-encap' is fulfilled.

However, in a more strict interpretation, I would claim that map-and-encap
architectures require a global mapping function that maps destination
addresses to tunneled next hops and creates two namespaces: one inside the
tunneled virtual topology and one underneath the tunnels.

MPLS, when used in a TE scenario, is more general than that in that it does
not create a separate namespace and it need not map soley on destination
addresses.

As always, this is a subtle semantic distinction, and the result really
depends on your definition of 'map-and-encap'.  While I love arguing
semantics, I greatly prefer to simply select a common agreed on definition,
make it semantically clear, and then move on.  If further concepts need
clarification, adding to the terminology is typically not a significant
issue.

Regards,
Tony

---

From: "William Herrin" <[email-masked]>
Date: Fri, 11 Jul 2008 00:46:30 -0400

> tunneled virtual topology and one underneath the tunnels.

Tony,

Fair enough. The definition of map-encap has been expanding to a
rather liberal scope recently. Perhaps we should seek a stricter
definition.

Though I wonder if there's a reason why we shouldn't strive to make
our map-encap system as expansively capable in the inter-domain scope
as MPLS is in the intra-domain scope.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Fri, 11 Jul 2008 00:06:25 -0700

|Though I wonder if there's a reason why we shouldn't strive to make
|our map-encap system as expansively capable in the inter-domain scope
|as MPLS is in the intra-domain scope.

We certainly could, but that would seem to be well beyond the requirements
that we currently have set before us, not to mention even further beyond
where we have rough consensus.

Tony