Subject: [rrg] rrg-design-goals-04 - we should write something much better

From: Robin Whittle <[email-masked]>
Date: Sun, 21 Nov 2010 03:26:04 +1100

As mentioned in my previous message, I think the current draft of:

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals-04

has many deficiencies.  While I was not involved in the recent
discussions about updating it, many of the criticisms I just wrote
were first posted to the list in 2007.

I voted against publishing the current draft as an RFC, because I
believe we can and should write something much better.

Despite the continued importance and the architectural fascination of
scalable routing, with global mobility for billions of individual
end-user hand-held devices there seems to be only a handful of people
still interested in the RRG's work.

This is not surprising considering the lack of encouragement of views
contrary to Tony's (and a few others') belief that the network must
not be asked to do more, or be altered in any way, and that all hosts
must be saddled with Loc/ID Separation: new protocols, more state,
more and/or longer packets etc.  Loc/ID Separation involves
unacceptable delays when establishing a new communication.  It can't
provide mobility in an acceptable fashion.  There are insurmountable
barriers to voluntarily adopting these new arrangements - and it is
only practical for IPv6.  As far as I can tell, ILNP's claims that it
will work with existing IPv6 applications are false - and I think this
probably applies to all such CES architectures.  So applications would
need to be re-written - including probably changes to some application
protocols themselves, not just the software.

Theoretical purists will be pleased by all this - but it will never be
practical or widely adopted.

Fred, I am surprised you voted in support of publishing the current
draft.  Section 3.4 states that Loc/ID Separation is "desired" and
then "required".  This means CEE: GLI-Split, ILNP, Name-Based Sockets
or RANGI - not LISP, Ivip and IRON.

The original meaning of a sentence in 3.4 was to refer also to what
some of us now call Core-Edge Separation (CES) architectures - LISP,
Ivip and IRON - and to state that if such an architecture was adopted,
that it is required to be compatible with Loc/ID Separation.  (This
sentence is now meaningless, since the way it describes CES, which was
primarily LISP when the sentence was written in 2007-04, no longer
applies to any architectures.)   So if we ignore the currently
meaningless form of this sentence and assume it means LISP, Ivip, IRON
or any other CES architecture, then 3.4 says these are required to be
compatible with ILNP etc.  This seems to be impossible.  Even if it
was possible, there would be no reason to implement both CEE and CES
approaches to the routing scaling problem.

  - Robin            http://www.firstpr.com.au/ip/ivip/

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Nov 2010 10:10:54 -0800

Robin,

> or RANGI - not LISP, Ivip and IRON.

I have to admit that I voted like a sheep on this one
instead of like a shepherd. As far as I'm concerned, the
IRON approach is the right way forward (else I wouldn't
be doing it), and if I missed something that argues to
the contrary then I voted incorrectly.

What do you say, Tony? Is this document trying to show
favoritism toward a particular approach?

Fred
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Mon, 22 Nov 2010 10:20:49 -0800

Fred,

> favoritism toward a particular approach?

Of course not.  The point is to capture our goals and articulate them as best we can.

Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Nov 2010 10:40:03 -0800

Hi Tony, 
 
> articulate them as best we can.

OK. Just the same, it looks like I am going to have to
go back now and actually *read* this document instead
of just go with the flow - my mistake!

It should also be noted that IRON is being considered
in other venues right now including softwires, intarea
and v6ops. It is of interest in those communities because
it supports IPv6/IPv4 transition *and* coexistence. The
"transition" part means "get there quickly" and the
"coexistence" part means do it once and be done for good.

IRON is a one-step solution in which we do it right the
first time - not a two-step solution in which we slap up
something temporary now then come back and do something
(presumably) better later on. (Especially if the "later
on" approach has shortcomings that the once-and-done
approach does not.)

Thanks - Fred

---

From: Robin Whittle <[email-masked]>
Date: Tue, 23 Nov 2010 05:52:13 +1100

Short version:   I plan to write my own personal "scalable routing
                 design goals" I-D - probably in the next few months.

                 Most of the people who have contributed
                 substantially to the RRG since 2007, including
                 all the LISP folks, have not been involved in
                 this discussion of goals, or in voting about it.

                 There's no hurry with scalable routing.  ILNP or
                 any other kind of Loc/ID Separation will be
                 extremely difficult to develop, since AFAIK, they
                 requires applications to be rewritten and only work
                 on IPv6.  Even if it is developed, almost no-one
                 will want to adopt it.

                 I imagine the growing de$ire for global mobility will
                 drive further progress on scalable routing - and that
                 won't necessarily involve the IETF or the IRTF.

Since Wes' message hasn't turned up on the list yet, here is what he
wrote to me and the list, followed by my reply:

On 23/11/2010 3:28 AM, George, Wes E [NTK] wrote:

> Robin, enough is enough. 
> 
> tl;dr version:
> Put up or shut up. Replace "we" in your subject line with "Robin"
> 
> 
> What I see here is an email from you admitting that you've been absent from
> the discussion when we were actually reviewing the draft and making
> suggested wording changes during last call. Now you show up well after the
> extended last call and the consensus check is over, with ~7500 words about
> all of the ways that you disagree with the current draft, and more martyrism
> about opposing viewpoints being ignored and accusations of bias in the
> document and on the chair's part. Nevermind the fact that if incorporated,
> many of your comments would suggest a bias in the opposite direction since
> it's clear that you want the reader to conclude that a different type of
> solution than what is being proposed in the RRG recommendation is the
> correct one. 
> 
> Far more importantly, you're recommending a significant rewrite of a
> document that at least 12 of us consider done, with almost no proposed draft
> text to address your concerns except in section 3.5, 3.10 and your proposed
> additional sections. And as far as I can tell, you're pointing to the
> relatively low word count as part of the reason why this draft is in bad
> shape. I won't bother with a discussion about quality vs quantity, even if
> it is NaNoWriMo.
> The only thing I see to your defense is that you made these arguments in
> 2007. So by implication we should have remembered this and taken it into
> account during our review?
> 
> If you're so convinced that the current draft is in bad enough shape as to
> call one or more sections a "horror" then it's time (past time, actually)
> for you to write an individual submission design goals draft that covers
> your concerns and reflects your views on what the design goals should be.
> Perhaps if things are as you imply and there is a statistically significant
> minority whose views are being ignored or quelled by the RG chair, and the
> consensus that has been derived is self-selecting and therefore not
> representative, your alternative draft can incorporate other disenfranchised
> members' views as well.
> 
> If I were you, instead of crying "foul" yet again, I'd write it fast and
> hope that our chair is willing to indulge your tardiness instead of simply
> taking the results of the poll that show consensus among those who voted,
> and pushing this forward to IRSG as is in the name of forward progress. It
> shouldn't be hard for you to write "something much better" since as you say,
> you've been raising these concerns since 2007, you clearly have a good sense
> for how you think that the document should be structured, what it should
> cover, etc, and you're obviously prodigious at generating text. However, if
> you want me (I can't speak for the rest of the group) to seriously consider
> it as an alternative, I challenge you to make it a succinct, objective
> discussion of the problem space and design goals, and not biased towards
> your personal worldview on the matter.
> 
> Wes George

Hi Wes,

Thanks for your suggestion.

Rather than debating how I do or don't contribute to the RRG, I was
hoping you and others would debate the substance of my critique.

Do you really support the goal that the solution be either Loc / ID
Separation (ILNP etc. not LISP, Ivip or IRON) or be compatible with
Loc/ID Separation?

If so, can you or anyone else think of a way any Loc/ID Separation
architecture could work on IPv4?

Can you or anyone else think of a way it could work even on IPv6
without requiring a major rewrite of application code, and in some
cases changes to application protocols themselves?  Ran claims that
ILNP claims to be able to run with existing IPv6 apps, but when I
tried to figure out how this could be done, I decided it probably
couldn't be.  Ran didn't even attempt to show how it could be done.
Tony tried (msg07111) and gave up, commenting: "And having a name
oriented stack would be the best solution."  A Name Oriented Stack
(AKA Name Based Sockets) is a Loc/ID Separation architecture which
fully declares the need to rewrite apps, and by implication change at
least some application protocols significantly.

There is probably no greater barrier to development and adoption than
the need to move to IPv6 and rewrite all the apps.

Its not possible for me to write a document in this field which I
strongly support and have no-one think that it "reflects my biases".
The same goes for anyone else trying to do the same thing.

I can't imagine anything I write or strongly support having the
support of Tony to become some kind of alternative document under the
auspices of the RRG.  The current draft will no-doubt go on to be an
RFC.

I think it is notable that no-one from the LISP team has bothered
casting a vote:

  http://doodle.com/idw28gc26vezipv9

Likewise, where are Bill Herrin, Christian Vogt, Brian Carpenter, the
APT people (Dan Jen and Michael Meisel), Eric Fleischman, Iljitsch van
Beijnum, Noel Chiappa, Joel Halpern, Philip Eardley, Tom Vest or
Xiaohu Xu?  These are some of the people who put a lot of work into
the RRG in the past - either with their own proposal or with helpful
analysis of other peoples'.  Some are no-doubt busy or distracted, but
their absence from the debate about the Design Goals makes me think a
lot of people who really care about scalable routing have given up on
this process.

For an example of why, look no further than Tony Li's blank response
to Fred Templin's concerns about having accidentally voted for a
document which he believes (as I suggested) strongly supports (or more
likely effectively mandates) Loc/ID Separation - which he is opposed to.

Tony has spent years ignoring or deriding stuff on the list which he
doesn't like.  Consequently progress and discussion has been
constrained by his focus on the architectural purity of Loc/ID
Separation to the exclusion of all other considerations.  He has shown
no interest in the constraints we face due to the need for widespread
voluntary adoption.  Fortunately, some people stuck it out and ignored
his guidance.  Some real work was done and fresh ideas were generated.

In the next few months I plan to write an individual I-D containing a
set of design goals which make sense to me.   If the RRG still exists,
then people can discuss it, express support etc. and suggest
improvements on the list.  If the RRG list is closed, I guess people
involved in scalable routing will have another mailing list.

I agree, ideally I would do this right now.  Likewise, ideally, I
would write up the two new "Zero Overhead Tunneling" ideas as I-Ds and
revise the other Ivip I-Ds to use this instead of encapsulation.
However, I need to give priority to some other things - like earning a
living.  There's a special monk-like headspace I need to engage with
xml2rfc and write an Internet Draft.  I find that process is at odds
with all other aspects of life.

There's no tearing hurry about scalable routing.  LISP isn't getting
any closer to resolving its fundamental problems, such as with how
ITRs can decide which ETR to tunnel to.   I am sure the processes the
RRG Report will set in motion, based on the co-chairs' recommendation,
will never produce a solution that anyone wants to adopt.

ILNP or any other Loc/ID Separation architecture is a complete
non-starter.  Even if it worked on IPv4 and didn't require apps to be
rewritten, it wouldn't get very far imposing a ID->LOC lookup and
consequent extra delays on the responding hosts before they can send a
reply packet (for the many application protocols where it matters what
you send in the reply and to which host).  Likewise its reliance on
everyone adopting it before it becomes useful to users, or for
scalable routing.

There will be a growing desire for limiting the growth in DFZ routes
and for making multihoming much more accessible to smaller end-user
networks.  I think the pressure for global mobility for IPv4 will grow
much faster - and I guess that this will be the impetus for developing
a CES based scalable routing system as part of something like TTR
Mobility.

These developments won't necessarily happen in the IETF or IRTF.  A
start-up company - or the Google-zilla looking for something fresh to
chew on - could develop their own protocols, build a system of servers
and just get on with selling the service.  Hopefully all that I and
others wrote about on the list, in I-Ds and on our websites will be
regarded as public domain, and so won't be patentable.

  - Robin

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 22 Nov 2010 22:47:23 +0000

It appears that the RRG mail daemon doesn't like the way that outlook attaches my digital signature, so I disabled that for now...

> -----Original Message-----
> From: Robin Whittle [mailto:[email-masked]]
> Sent: Monday, November 22, 2010 1:52 PM
> To: George, Wes E [NTK]; RRG
> Subject: Re: [rrg] rrg-design-goals-04 - we should write something much
> better
>
[WES] Yes, I do, hence my vote in favor of publishing the design goals. I run a mobile network, so I know a thing or two about mobility schemes that use tunneled traffic and anchor points to maintain connectivity while the end host moves around without routing table updates. It works... However, the gear and encapsulation required and the scale tradeoffs to make it work are not optimal, and extending it and trying to make it scale to the rest of the Internet is exactly the wrong direction in my opinion.

> architecture could work on IPv4?
[WES] Well, based on what I read I believe that ILNP can, but I understand that you don't, nor do you buy the explanation to the contrary. I don't wish to re-debate that with you because I doubt it'll change either of our minds.

However, let me be absolutely clear: I. don't. care. whether it will work on IPv4. It's too little, too late. We're out of address space for IPv4. I can't number my 50 million mobile customers with IPv4, most emerging economies can't number their entire populace out of IPv4 the way that the current first-world countries have done, and we can't number the smart grid out of IPv4, to say nothing about the other machine-to-machine and internet of things applications that are poised to dramatically increase the steepness of the routing table growth curve. I'll concede that some of the route-scale solutions proposed here might be able to extend IPv4's useful life by allowing for segmentation and reuse of the space, but with IPv4 exhaustion likely happening in the next 3-6 months, they're not going to be implemented in time. Further, for them to be better than a NAT44(4) in that regard, they have to restore seamless end to end connectivity (and as far as you're concerned, do it without application or CPE changes).
Like it or not, IPv6 (and specifically IPv6-only) is going to be a reality. 5+ years ago it might have made sense to have a solution for IPv4, but at this point I'd rather focus on IPv6. If we get a solution for IPv4 for little incremental work, great, but I don't want to delay the work to force that issue to get resolved if we have a workable solution for IPv6.
In the normative language of the draft, I view an IPv6 solution as REQUIRED, an IPv4 solution as somewhere between DESIRED and OPTIONAL.

> cases changes to application protocols themselves?  Ran claims ... but ...
> I decided it probably
> Tony tried (msg07111) and gave up ...
[WES] As you say, you've been over this, and I'm not going to be any more successful at debating it with you than the author of the draft. You obviously believe that host changes are less possible than expecting providers like me to swallow hard and implement another round of costly infrastructure to solve this problem, and I'm not going to be able to convince you otherwise, but I'll still make my opinion known since you asked. A very significant part of the reason why IPv6 has taken so long to deploy and there is resistance to things like ILNP is that the Internet infrastructure has gotten very sclerotic and resistant to change. I'd rather not reinforce that by enabling people to continue assuming that host changes are off limits and the network providers should be solely responsible for keeping the internet working (and all the while racing each other to the bottom on prices for services).

>
> There's no tearing hurry about scalable routing.
[WES] Hi, my name's Wes, and I'm an [token] operator. You don't know me, but I work for a large-ish US-based ISP in the DFZ, and we happen to be very much interested in scalable routing... RIGHT ZARKING NOW, so that something might be implemented before we have to spend another XX million USD in a few years to buy $router_vendor's next generation linecard and memory to hold the routing table. This is especially true if we do that upgrade once or twice more only to then have to spend the same or more when someone finally gets around to implementing a route scale solution, especially if implementing the proposed solution requires the network to change instead of hosts.
So I trust you'll forgive me for not trusting your unsupported assertion on how much time we do or don't have to solve this problem.

Hopefully that explains why a number of my messages to this list have been to try to move things forward, not prolong (or worse, recycle) debate. I'd like to see some of this stuff move towards implementation phase independent of whatever politics have destabilized this group, because running code will expose all sorts of design flaws much faster than debate on an email list ever will. Having to evaluate running code and make a choice between multiple different options that exist in the output of this group is a problem that I would very much like to have, and I see no way that revisiting arguments that you've apparently been having with this group since 2007 gets us anywhere closer to that goal.

Thanks
Wes George

________________________________

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 23 Nov 2010 10:29:02 +0900

My mistake, too.

LIS rather might be stated as an option or at most a prevailing option, but
it should fairly be also stated that there are other views not supporting
the LIS argument.

Also, I'm a bit skeptic whether LIS can be any of a design goal. At most, it
can be a method to achieve the goal. There might be other methods to achieve
the same goal. Many routes to climbing up to the summit.

On Tue, Nov 23, 2010 at 3:40 AM, Templin, Fred L
<[email-masked]>wrote:

> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

-- 
DY

---

From: Robin Whittle <[email-masked]>
Date: Tue, 23 Nov 2010 20:08:10 +1100

Hi Wes,

Thanks for your reply.  In "Re: [rrg] rrg-design-goals-04 - we should
write something much better", (msg07574 in the archives, with each of
your paragraphs as one hard-to-read line) you wrote:

>> Do you really support the goal that the solution be either Loc /
>> ID Separation (ILNP etc. not LISP, Ivip or IRON) or be compatible
>> with Loc/ID Separation?

> [WES] Yes, I do, hence my vote in favor of publishing the design
> goals. I run a mobile network, so I know a thing or two about
> mobility schemes that use tunneled traffic and anchor points to
> maintain connectivity while the end host moves around without
> routing table updates. It works... However, the gear and
> encapsulation required and the scale tradeoffs to make it work are
> not optimal, and extending it and trying to make it scale to the
> rest of the Internet is exactly the wrong direction in my opinion.

OK - I recognise there are problems with tunneling due to its
overhead, Path MTU Discovery problems and the potential for one
traffic packet to be split over two or more tunnel packets, raising
the risk of data loss due to a given rate of packet loss.

Loc/ID Separation involves no tunneling.  However, as far as I know,
there's no Loc/Id Separation approach to mobility which avoids these
fundamental problems:

  1 - The MN (mobile node) can't be behind NAT.  It needs a global
      unicast address (Locator) so any other host can send it
      packets directly, and without any preliminaries.

  2 - Every time the MN (mobile node/host) changes its CoA (current
      "Care of Address" in the current system, in Loc/ID Sep.:
      "Locator") it has to do several things:

        a - Securely tell all its CHs (correspondent hosts) of its
            one or more new Locators and about which ever ones it
            has just relinquished.

        b - Securely update the centralised ID->Loc mapping system
            with the new Locator information so other hosts can
            initiate contact with it.  Depending on the design
            of the Loc/ID Sep. architecture, this may be the same
            thing as DNS or the DNS server also needs to be updated.
            (With Loc/ID Separation, every host needs a DNS entry
            as well as an entry in a potentially separate ID->Loc
            mapping system.)

Similar problems apply to the current LISP approach to mobility:

  http://tools.ietf.org/html/draft-meyer-lisp-mn-04

   (This v04 version from 2010-10-25 is a month old and contains
    the first substantial changes since v00 of 2009-07-01.
    I haven't read these changes, but a quick scan of the DIFF2
    gives me the impression that it hasn't changed in ways which
    affect my critique of LISP Mobile:

     http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html )

In the Loc/ID Separation world, maybe there will be no NATs - this is
an updated version of the IPv6 Internet, not something based on the
IPv4 Internet - since no Loc/ID Separation system can work on IPv4 for
reasons including inefficient use of address space and there being no
method of conveying Loc and ID in existing packet headers.

Point 2 is more fundamental.  I argue it can't be solved and that it
is therefore better to adopt TTR Mobility, where there is a 2-way
tunnels, established from the MN to a (typically) nearby TTR, which
acts as an ETR in the Core-Edge Separation scheme (LISP or Ivip,
though I think IRON uses TTR Mobility principles already) and handles
outgoing packets too.  With TTR Mobility:

  http://www.firstpr.com.au/ip/ivip/#mobile

the MN can be behind NAT and/or on a TTR Mobile address, in any
combination and depth of recursion.

If you stick with Loc/ID Separation, or LISP-mn, then there's no way
the MN is going to be able to securely update the Locator information
in multiple CHs all round the world in a timely or efficient fashion.
 (You could offload the work to a separate server to fan out the
updates, but this raises delay and scaling problems, since only the MN
has the nonces for each session with another CH.)

Each such update needs to involve strong crypto or a nonce or similar,
since it will come to the CH from an IP address or Locator which the
MN has no previous association with or knowledge of.  Assuming the MN
has just lost one CoA (AKA Locator)and instantly gained another, user
packets from the CHs to the MN will be sent to the old CoA/Locator
until the update is completed.  Only then will traffic, such as VoIP,
be received again by the MN.

If the CH is mobile too and it changes its CoA/Locator at about the
same time, they will both have to detect this and wait for the other
host to update its DNS or ID->Loc mapping in the global mapping
system.  Then they can use this (with this mapping system, with the
likely delays and risk of query or response packet loss which is
inherent in in any global query server network) to re-establish
communications.

So, every time the MN gets a new CoA, it needs to send out a flurry of
packets to its various CHs - however this is determined.  I guess a 5
minute cache time or similar would reduce the number of CHs to
contact, but this would force all CHs to revert back to DNS or ID->Loc
global lookup to continue or start a new session if there was more
than a 5 minute break between packet exchanges.

It would be bad enough doing this from a DSL or fiber-connected
service.  Doing it via potentially slow, potentially high latency,
potentially costly and potentially unreliable 3G or GPRS radio links,
with a compact battery operated device, would be much worse.

Also, the global DNS and ID->Loc lookup systems (which may both be
done via DNS or similar) will have to update their central
authoritative server information every time the CH gets a new CoA.

These rapid changes mean that all DNS and ID->Loc queries need to go
to the one or more authoritative servers - they can't be cached at
all.  To cache them for even 10 seconds would result in a 10 second
delay in the ability of two MNs to reconnect after they both get new CoAs.

So the entire DNS and ID->Loc lookup system is global and uncachable.

The global infrastructure and the central servers get a hammering.
You can make multiple authoritative servers to spread the load and
generally shorten the delay, if the query somehow automatically goes
to the closest server.  But then you increase the workload for the
update every time the MN gets a new CoA/Locator.

I think its much better to have the MN tunnel from its one or more
CoAs to a typically nearby TTR (Translating Tunnel Router).  The MN's
address or address range is mapped in the CES system (such as Ivip or
perhaps LISP) to use that TTR as an ETR.  So only the MN->TTR tunnel
establishment, from the new CoA to the existing TTR, is required to
continue communications from the new CoA.

There's no impact on CHs at all, or on DNS, or on the CES system's
mapping database each time a MN gets a new CoA.  Only if the new CoA
is far from the current TTR - such as 1000km or more - would it make
sense for the MN (under the guidance of the TTR system) to find a new
TTR (which can be done while the old TTR is still being used) and then
to switch the mapping to the new TTR.  So mapping changes would be
very infrequent and there would be minimal effort in establishing a
tunnel to the current TTR, from the new CoA, every time the CoA changes.

This leaves us with the burden of tunneling, but typically it will be
to a TTR which is nearby.

Changes to CoA can happen very frequently, even without the MN moving.
 The 3G network might bump it to a different base-station which uses a
different IP gateway.  Base station capacity limitations or RF
propagation and interference changes might end the session.  A new,
cheaper, faster WiFi link might become available, and the MN gets a
CoA on that, including behind NAT.  Just driving past an open-access
WiFi system of a cafe could cause this.  Likewise boarding a train, or
aircraft - or driving through a tunnel, or entering a building.

There shouldn't be a flurry of updates to CHs and the mapping system
ever time a cell-phone connects automatically to a WiFi system or
whatever.  But that is what would happen with Loc/Id Separation or
LISP-mn.

I think the difficulties with tunneling are not prohibitive, but that
the problems I mentioned with Loc/ID Separation mobility and LISP-mn are.

>> If so, can you or anyone else think of a way any Loc/ID
>> Separation architecture could work on IPv4?

> [WES] Well, based on what I read I believe that ILNP can, but I
> understand that you don't, nor do you buy the explanation to the
> contrary. I don't wish to re-debate that with you because I doubt
> it'll change either of our minds.

ILNP can only work on IPv4 with some new kind of header information.
It seems that some, many or all routers in general - or DFZ routers in
particular - are not able to handle packets with new header options
with their normal efficiency.  So unless you factor in upgrading all
these routers, ILNP can't work with IPv4.  If you have a magic wand to
upgrade all the IPv4 DFZ routers, such as to recognise new packet
formats, then there's lots more things we could do regarding scalable
routing.   Loc/ID Separation would not, in my opinion, be the best
approach to take.

> However, let me be absolutely clear: I. don't. care. whether it
> will work on IPv4. It's too little, too late. We're out of address
> space for IPv4. I can't number my 50 million mobile customers with
> IPv4, most emerging economies can't number their entire populace
> out of IPv4 the way that the current first-world countries have
> done, and we can't number the smart grid out of IPv4, to say
> nothing about the other machine-to-machine and internet of things
> applications that are poised to dramatically increase the steepness
> of the routing table growth curve. I'll concede that some of the
> route-scale solutions proposed here might be able to extend IPv4's
> useful life by allowing for segmentation and reuse of the space,
> but with IPv4 exhaustion likely happening in the next 3-6 months,
> they're not going to be implemented in time. Further, for them to
> be better than a NAT44(4) in that regard, they have to restore
> seamless end to end connectivity (and as far as you're concerned,
> do it with out application or CPE changes). Like it or not, IPv6
> (and specifically IPv6-only) is going to be a reality. 5+ years ago
> it might have made sense to have a solution for IPv4, but at this
> point I'd rather focus on IPv6. If we get a solution for IPv4 for
> little incremental work, great, but I don't want to delay the work
> to force that issue to get resolved if we have a workable solution
> for IPv6. In the normative language of the draft, I view an IPv6
> solution as REQUIRED, an IPv4 solution as somewhere between DESIRED
> and OPTIONAL.

I agree that expansion of mobile IP to encompass the billions of
people who want and need it must involve IPv6.  (This is on the
assumption that it won't do to give all these devices simply a behind
NAT IPv4 form of connectivity.  Maybe this assumption is not true - in
which case IPv6 won't be needed.)

I guess this will enable the devices to access the IPv4 world via a
NAT box and tunneling through the IPv6 access network and mobility
system.  This rules out direct VoIP with the IPv4 world, but it would
work via an intermediate server which the MN established a tunnel to
from behind its IPv4 NAT box.

So I expect (if the above assumption is true) that IPv6 will be used
to a significant degree for mobile networks in the next 5 to 10 years.
 That would drive the service industry for mobile users to get native
IPv6 servers.  It may also drive non-commercial users to get native
IPv6 connectivity at home so they can send packets straight back and
forth between their and their cellphone (music player, PC etc.)

But giving every cell phone a global unicast IPv6 address, via any
means, including especially a mobility system which means the device's
applications use the same IP address no matter what access network
they are using, would enable each device to do direct VoIP to any
other IPv6 device.  That would reduce the wireless networks to
providers of IP connectivity, since it would be trivial to have a VoIP
application on the cellphone which communicated directly with the
stable (portable and usable via all access networks) IPv6 address of
the correspondent device.  (Phone numbers would be replaced by IPv6
addresses - or by DNS entries for these addresses.)

I am not sure there is an impetus for 3G operators to do this, since
it would enable many people to bypass their voice services, which are
presumably charged for at a higher rate than whatever they would
charge for the VoIP packets.

The impetus for global mobility is directly for the end-user's
benefit.  So I expect global mobility companies to provide such
services by TTR Mobility, even when the 3G operator doesn't want its
customers to have this.  Then again, if one 3G network prevents global
mobility and the other allows or provides it, many customers would
those the other.

I think the choice for mobility will be between:

 1 - Existing MIPv6 arrangements, which either require updated stacks
     (I think) in CHs to minimize path length problems via the one
     Home Agent, or reliance on existing stacks in CHs and the Home
     Agent, which involves potentially very long paths when the MN is
     on the other side of the world.

 2 - LISP and its current LISP-mn approach, which has the problems
     listed above, plus the fundamental problems with LISP such as
     the difficulty or impossibility of ITRs scalably determining
     which ETRs can actually get packets to the destination network.

 3 - Loc/ID Separation, such as ILNP or Name Based Sockets.  This
     will only work with CHs which have suitably upgraded stacks and
     applications.  So this is a non-starter.  Even if this hurdle was
     overcome, the recipient host will typically need to delay
     replying to the initial packet while it does an ID->Loc lookup,
     since it can't take on trust the ID and Loc values which are in
     the source fields of the initiating packet.

       http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

     Then, there are the fundamental delay and scaling problems
     mentioned above every time the MN gets a new CoA - and the
     MN not being able to use a CoA behind NAT.

 4 - TTR Mobility, with either Ivip or LISP as the CES system.
     (Or perhaps IRON, which apparently incorporates some principles
     of TTR Mobility - I haven't read the latest drafts.)

     If you choose to build or use something like Ivip, then you can
     use what I am calling ZOTv6 - Zero Overhead Tunneling for IPv6.
     This is Sampo Syreeni's suggestion and I will probably write up
     a quickie version of it for the RRG list sooner rather than
     later.  It can't work with LISP, since it doesn't carry the ITR's
     address with the tunneled packet - and LISP's protocols involve
     this and other information being sent along with the tunneled
     packet.  But it is good for Ivip since Ivip doesn't require the
     ETR to know the address of the ITR which is tunneling packets to
     it.

     ZOTv6 is for the ITR -> ETR tunnel.  You still need to use one
     of a variety of (typically encrypted) two-way encapsulation-based
     tunnel techniques for the MN <--> TTR tunnel, which the MN always
     establishes, including from behind NAT or from a TTR Mobility
     provided address.

     ZOTv6 requires an elaboration for the management of the ETR and
     more complex mapping data.  But for Ivip, the ITRs are not
     having to choose between multiple ETRs, so the ITR's job is still
     quite simple, compared to what a LISP ITR would have to do.

     ZOTv6 and the quite different ZOTv4 I have developed, inspired by
     Sampo's most insightful suggestion, both involve some Path MTU
     Discovery gotchas.  For packets below a certain globally agreed
     length, there's no extra work to be done.  For packets which are
     longer than this - say longer than 149x bytes - the ITR must
     initiate a brief two-way protocol with each ETR it is sending
     packets to - when a packet is being sent which is longer than
     the already established minimum MTU to that ETR, but not above
     any maximum which has been established so far.  This is a PITA,
     but I can see a way of doing it.  The ITR and ETR occasionally
     communicate to manage the ITR's estimate of PMTU to the ETR.
     This enables the whole system to handle jumboframes (~9k byte
     packets) across the DFZ if and when this becomes possible.

>> without requiring a major rewrite of application code, and in
>> some cases changes to application protocols themselves?  Ran
>> claims ... but ... I decided it probably couldn't be.  Ran didn't
>> even attempt to show how it could be done. Tony tried (msg07111)
>> and gave up ...

> [WES] As you say, you've been over this, and I'm not going to be
> any more successful at debating it with you than the author of the
> draft. 

I don't recall Ran debating it.  Nonetheless, the claim that ILNP
works with existing IPv6 apps was accepted by most people, myself
included, until I tried in July this year.  The claim persists,
despite my objections, in the soon to be RRG Report:

http://tools.ietf.org/html/draft-irtf-rrg-recommendation-15#section-12.1.2

    ILNP can be implemented such that existing applications (e.g.
    applications using the BSD Sockets API) do NOT need any changes
    or modifications to use ILNP.

> You obviously believe that host changes are less possible
> than expecting providers like me to swallow hard and implement
> another round of costly infrastructure to solve this problem, and
> I'm not going to be able to convince you otherwise, but I'll still
> make my opinion known since you asked. A very significant part of
> the reason why IPv6 has taken so long to deploy and there is
> resistance to things like ILNP is that the Internet infrastructure
> has gotten very sclerotic and resistant to change. 

Yes - its the world's most entrenched IT system and its big feature is
the ability to communicate between any hosts.  This has taken a hit
with NAT, with behind-NAT hosts being second-class citizens which are
not able to communicate directly with each other - but they can still
communicate with any server on the IPv4 Internet.

Trying to introduce changes to the existing system, including using
the IPv6 Internet instead, leads to all sorts of difficulties which
mean most users won't bother and will soldier on with IPv4 as it is today.

> I'd rather not
> reinforce that by enabling people to continue assuming that host
> changes are off limits and the network providers should be solely
> responsible for keeping the internet working (and all the while
> racing each other to the bottom on prices for services).

In an ideal world *perhaps*, we could convince all the people who
write software for PCs, cellphones etc. to write new versions of their
programs to handle a new stack API and a new set of basic Internet
protocols.  This would be a very tall order indeed, since they would
need to test and maintain their code to work with and without a new
kind of stack, operating with their own code and other programs in
remote machines which both did and didn't have the new features and
which did and didn't run on a host with the new stack.  This would be
a complete nightmare.

"*perhaps*" means if we somehow were convinced that the initial delays
and other overheads inherent in Loc/ID Separation were a price worth
paying for its benefits (msg07017).

It also means deciding the generally longer delays and less efficient
operations required by Loc/ID Separation when the MN changes its
Locator are acceptable.

To use TTR Mobility, you don't need new routers.  You, or someone
else, needs to develop a bunch of protocols and software to implement
them.  The ITRs, ETRs/TTRs and mapping system can all be done with
COTS servers.  These functions don't need to be done by Cisco/Juniper
routers.  You would also need to develop tunneling and management
software for each particular type of mobile device your customers use.
 Assuming your routers, mobile networks and mobile devices can do
IPv6, it "just" needs a lot of software development.  Competent
programmers could figure it out from reading the TTR Mobility and Ivip
stuff.  You don't need to wait for the IETF.  Hopefully my exposure of
this stuff means none of it can be patented - or that such patents
would not hold up in court.

> [WES] Hi, my name's Wes, and I'm an [token] operator. You don't
> know me, but I work for a large-ish US-based ISP in the DFZ,

Sprint - indeed a large operator!

> and we
> happen to be very much interested in scalable routing... RIGHT
> ZARKING NOW, so that something might be implemented before we have
> to spend another XX million USD in a few years to buy
> $router_vendor's next generation linecard and memory to hold the
> routing table. 

OK.  Let me write something better:

   With the current pace of RRG official recommendations, LISP
   development and the likely impossibility of testing and developing
   ILNP or any other Loc/ID Separation architecture to the point where
   anyone might make a serious investment in deploying it, I would
   say there's no urgency this month or the next, and probably not
   next year or to 2013 or so, to actually come up with a detailed
   set of protocols and operating code which genuinely solves the
   scalable routing problem, for IPv4 or IPv6, including especially
   providing proper global mobility with generally VoIP-compatible
   response times and typically short path lengths.

   This is because there's no way LISP, ILNP or whatever will actually
   be seriously invested in or committed to in a way which will
   impose costs on users.

   In that time, the IPv4 DFZ will grow, and perhaps grow more rapidly
   than in the last 5 years, despite the imminent 2nd Great
   Depression.

   I am not sure how close your routers are to hitting a wall with
   the IPv4 DFZ's 330k routes:

       http://bgp.potaroo.net/

   but as long as they can cope with 600k routes, then I guess you
   should be fine for another 4 or 5 years.

   There's no way the IPv6 DFZ routing table is going to become
   too large for your routers in the foreseeable future - say in the
   next 10 to 15 years.  (Unless the limitation is the total number
   of IPv4 and IPv6 routes - in which case the problems can't be
   separated and my analysis would be different.)

   As long as you and a bunch of other operators are running mobile
   and DSL/fiber access networks, there's no significant problem with
   the number of IPv6 DFZ routes growing beyond 50k or 100k or
   whatever.  The only scaling difficulty would arise if there were
   lots of end-user networks (EUNs) wanting, getting and advertising
   their own IPv6 PI prefixes AND if you really wanted or needed to
   exchange packets with those EUNs. There would need to be a lot of
   such EUNs doing this before the problem got to the 200k, 300k, 600k
   or whatever level where I assume you begin to hit limits with the
   routers.

   That growth in EUNs advertising PI prefixes has nothing to do with
   mobile or DSL/fiber access networks, even with billions of
   customers.  You might have part of your 3G/4G network supporting
   50 million customers, each with one device.  But it will only
   involve one or a few prefixes in the IPv6 DFZ.  So I can't see how
   3G/4G ISPs alone will ever cause the IPv6 DFZ routing table to
   grow to a problematic size.

   The only reason in the foreseeable future (to 2020) I can see for
   large numbers of EUNs wanting IPv6 connectivity is to serve the
   growing millions of mobile users on the necessarily IPv6 mobile
   networks Sprint and other such companies will presumably be
   deploying.   (This is on the assumption that you can't sell a
   mobility service with purely behind NAT IPv4 connectivity - and
   that you really must have a global unicast IPv6 address for each
   MN.  I am not convinced this assumption is true or will become
   true in the foreseeable future.)

   So my sense of there being "no tearing hurry" is this:

      It doesn't matter much whether I devote my life to developing
      Ivip drafts and software in the next year or two, since there's
      no chance that ILNP (or any other Loc/ID Separation architecture
      or LISP will be developed to the stage where some networks or
      users might make a big investment in them.

      So when the time is right, people will discover, or re-invent,
      TTR Mobility and Ivip.

      If I thought the IETF could mandate a change to LISP, or to
      ILNP etc. and that this mistaken (IMHO) decision would be
      binding on all Net users and so disastrously wrong and costly,
      then I would say there is a big hurry right now to raise
      awareness of what is wrong with these approaches, in part by
      fully developing something better (Ivip & TTR Mobility, in my
      view, or IRON, or whatever it is which someone thinks is
      better.)

   However, this statement in general about there being no tearing
   hurry about scalable routing, including mobility, is just for my
   vision of architecture developers in the next year or two.

   Companies such as Sprint need to plan now what they will be doing
   in 2016 to 2020.  So there is a hurry for them.

   Likewise anyone who wants to develop a commercial TTR-style
   global mobility service.  There's no standards or technical
   impediment to creating such a service today, for IPv4 or IPv6.
   The customers would pay a TTR company for a TTR service and use
   any access network at all, including one or more 3G providers,
   free WiFi services and their own WiFi extensions of home DSL /
   fiber / HFC for their Internet access.

   There could be multiple TTR companies, each with their own global
   network of TTRs, their own tunneling software for different types
   of MNs, their own DITRs at the globally dispersed TTR sites.
   Each such network could operate with its own private protocols,
   without any reference to IETF standards for scalable routing.

   For a number of reasons it would be better if they used common
   protocols - but a bunch of such services could co-exist
   perfectly well, even if they all used their own code and their
   own unique protocols.  Any customer of such a company could have
   their stable IP address wherever they go, and there would be
   generally optimal paths to all other hosts, including those on the
   same and on other TTR systems.

> This is especially true if we do that upgrade once
> or twice more only to then have to spend the same or more when
> someone finally gets around to implementing a route scale solution,
> especially if implementing the proposed solution requires the
> network to change instead of hosts. So I trust you'll forgive me
> for not trusting your unsupported assertion on how much time we do
> or don't have to solve this problem.

OK - I apologise for writing something which implies that you and
companies such as yours shouldn't be concerned about scalable routing
any time soon.

I think the best approach is TTR Mobility with Ivip.  While perhaps it
would make sense to have existing or future Cisco/Juniper routers
doing some of the work, I think that in the initial stages and
probably in the long-term future, COTS servers, including blade
servers, will be a much better set of devices to perform the ITR, ETR,
TTR and mapping server functions.

So I think you don't need to spend a cent on upgrading your routers to
achieve what I have in mind.

> Hopefully that explains why a number of my messages to this list
> have been to try to move things forward, not prolong (or worse,
> recycle) debate. I'd like to see some of this stuff move towards
> implementation phase independent of whatever politics have
> destabilized this group, because running code will expose all sorts
> of design flaws much faster than debate on an email list ever will.

I agree.  I would be really happy if you and other people with your
expertise and responsibilities took a close look at TTR Mobility and
Ivip and let me know, privately or in a list such as this, what you think.

I have outlined what I regard as show-stopping problems with LISP,
LISP-mn and Loc/ID Separation of all kinds, including ILNP - and I
don't think these critiques have been refuted.   As far as I know, TTR
Mobility is the only way of doing global mobility, for IPv4 or IPv6,
with lightweight VoIP-friendly fast responses to new CoAs, and with
generally optimal path lengths.

TTR Mobility could work quite well with LISP, even if its mapping
system was quite slow to update all the ITRs.  It would work better
with Ivip, and I will soon write up ZOT - how Ivip can work with
ordinary packets, using ordinary routers, no longer than the original
traffic packet, in the ITR -> ETR tunnels.  ZOT can't work with LISP -
and LISP ITR->ETR/TTR tunneling for IPv6 involves a complete outer
IPv6 header, a UDP header and a LISP header.  This is a lot of
encapsulation overhead, especially for a VoIP packet which only
carries 20 bytes or so.

> Having to evaluate running code and make a choice between multiple
> different options that exist in the output of this group is a
> problem that I would very much like to have, and I see no way that
> revisiting arguments that you've apparently been having with this
> group since 2007 gets us anywhere closer to that goal.
> 
> Thanks Wes George

I would welcome your feedback on TTR Mobility and Ivip.

Its counter-intuitive that valuable solutions might come for free from
some bloke in Australia you haven't met, rather than the Cisco or
Juniper folks who you have paid millions or billions of dollars to for
their essential and generally excellent routers.  But until someone
shows that my proposals contain fatal flaws, this counter-intuitive
notion hasn't been disproven.

  - Robin

---

From: Toni Stoev <[email-masked]>
Date: Tue, 23 Nov 2010 11:29:40 +0200

Robin, can you please synthesize a short version of this?

---

From: Robin Whittle <[email-masked]>
Date: Tue, 23 Nov 2010 21:18:49 +1100

Hi Toni,

> Robin, can you please synthesize a short version of this?

Sorry, I can't.  Scalable routing and mobility is a complex field and
I am discussing several things in the detail I think is required.

 - Robin

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 23 Nov 2010 15:02:39 +0200

Hi Wes,

think you are referring to my I-D and thus I feel an obligation to response.

You are right, my I-D focuses on IPv4 - simply for the reason that it
is what is implemented today and also after considering one
requirement in the design goal which is incremental deployability.
Nevertheless, the same architecture can be applied with IPv6 addresses
- but how to do the transition from IPv4 and where are the incentives
to move from IPv4 to IPv6 from e.g. enterprises point of view? Moving
to IPv6 is a forklift upgrade, enterprises' homegrown or customized
applications needs to be ported and that is very expensive.

I also share your concerns about IPv4 depletion, it might be too late
for hIPv4 to get deployed. But I think you will not stop to sell IPv4
based services within 3-6 months - it seems that the ISPs are forced
to deploy Carrier Grade NAT solutions (unfortunately), simply because
of the customer demand. The IPv4 community is very large and too large
to be ignored by any service provider (carrier or content) - thus
there will be no killer application for IPv6, startups will not get
funding if they deploy solutions only for IPv6.

The problem here is very similar as with multi-homing, once you get
your solution in place it is no longer your problem - i.e. if I have
an IPv4 address (or multi-homed solution) and can be part of the IPv4
community, why should I care and invest in technology that will do no
good for me - especially with all the financial problems in the old
economies.

The question is, how much more time will CGN and e.g. LISP by us?
And if time is running out, well, the architecture is basically the
same - the only difference is 32x32 bit address space versus 64x64 bit
address space. IMHO, it is not about IPv4 versus IPv6 or CES versus
CEE.

Patrick

.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Nov 2010 07:09:59 -0800

See below for my comments on sections 3.4 and 3.5:

Fred

3.4.  Decoupling location and identification

   Numerous sources have noted that an IPv4 address embodies both host
   attachment point information and identification information.  [IEN1]
   This overloading has caused numerous semantic collisions that have
   limited the flexibility of the Internet architecture.

FLT >> OK.

   Therefore, it
   is desired that a solution separate the host location information
   namespace from the identification namespace.

FLT >> Not OK. Change to: "Therefore, it is desired that a solution
FLT >> provide the host with an identification and/or endpoint address
FLT >> that remains stable even if the location change. 

   Caution must be taken here to clearly distinguish the decoupling of
   host location and identification information, and the decoupling of
   end-site addresses from globally routable prefixes; the latter has
   been proposed as one of the approaches to a scalable routing
   architecture.  Solutions to both problems, i.e. (1) the decoupling of
   host location and identification information and (2) a scalable
   global routing system (whose solution may, or may not, depend on the
   second decoupling)

FLT >> OK.

   are required and it is required that their
   solutions are compatible with each other.

FLT >> Not OK. I think Robin is right that we will not see a
FLT >> combination of disparate solutions such as ILNP+IRON both
FLT >> being deployed in conjunction. What is quite possible, however,
FLT >> is a combination of IRON+HIP since HIP is only instrumenting
FLT >> the hosts and can be used perfectly well over an IRON network.
FLT >> Still, why would such a combination be *required* when it may
FLT >> not actually even be desireable in all cases? Suggested change
FLT >> is to replace the above phrase with the phrase: "are possible."  

3.5.  Scalable support for mobility

   Mobility is the capability of a host, network, or organization to
   change its topological connectivity with respect to the remainder of
   the Internet, while continuing to receive packets from the Internet.
   Existing mechanisms to provide mobility support include

   1.  renumbering the mobile entity as it changes its topological
       attachment point(s) to the Internet;

   2.  renumbering and creating a tunnel from the entity's new
       topological location back to its original location; and

FLT >> Strike the phrase "renumbering and". Renumbering would
FLT >> imply that the end system's endpoint address changes
FLT >> when in fact it is only the end system's locator address
FLT >> that changes. This is true for both MOBIKE and Mobile IP,
FLT >> and also applies to the kinds of mobility solutions
FLT >> associated with the CES architectures.

   3.  letting the mobile entity announce its prefixes from its new
       attachment point(s).

   The first approach alone is considered unsatisfactory as the change
   of IP address may break existing transport or higher level
   connections for those protocols using IP addresses as identifiers.
   The second requires the deployment of a 'home agent' to keep track of
   the mobile entity's current location and adds overhead to the routers
   involved, as well as adding stretch to the path of inbound packet.
   Neither of the first two approaches impacts the routing scalability.
   The third approach, however, injects dynamic updates into the global
   routing system as the mobile entity moves.  Mechanisms that help to
   provide more efficient and scalable mobility support are desired,
   especially when they can be coupled with security, especially
   privacy, and support topological changes at a high-rate.

FLT >> OK.

   Ideally,
   such mechanisms should completely decouple mobility from routing.

FLT >> Not OK. It should be perfectly OK for mobility to interact
FLT >> with the routing system as long as the routing churn is
FLT >> localized and minimized. Strike this sentence.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 23 Nov 2010 15:47:11 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Templin, Fred L
> Sent: Tuesday, November 23, 2010 10:10 AM
> To: RRG
> Subject: [rrg] Comments on rrg-design-goals-04
>

> FLT >> localized and minimized. Strike this sentence.

[WES] I disagree with your recommendation here Fred, but for purely semantic reasons. http://wordnetweb.princeton.edu/perl/webwn?s=ideal
Absent any other considerations, that is, ideally, the proper solution is to decouple mobility from routing. In a more practical implementation (ie not a completely ideal one), it might be ok for mobility to interact as you are saying, but I don't think that the sentence as written says that this is prohibited, only that it's not the most preferable implementation.

Wes George

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Nov 2010 10:51:00 -0500

I appreciate your taking the time to read the document carefully.
However, I am confused by most of your requested changes.
The changes seem to reflect some (there is plenty of disagreement) 
conclusions that folks have reached during the course of the IRTF RRG work.
But the document is not the goals for some new set of work.  It is the 
goals we roughly agreed on early on.  The purpose of publication is for 
the historical record, not to drive some new set of work.  New work will 
have to define its own goals.

I am also confused by your comment on the description of the existing 
mobility solutions.  I am pretty sure that there exist solutions with 
the properties enumerated in the document.  Given that existing 
solutions, while they may have implicit notions of identity, do not have 
a clear distinction, I do not see the problem with describing the 
existence of solutions which use renumbering and tunnelling.  We could, 
perhaps, debate which solutions have that property.

Yours,
Joel

On 11/23/2010 10:09 AM, Templin, Fred L wrote:
> FLT>>  OK.
> FLT>>  Not OK. Change to: "Therefore, it is desired that a solution
> FLT>>  provide the host with an identification and/or endpoint address
> FLT>>  that remains stable even if the location change.
>
> FLT>>  OK.
> FLT>>  Not OK. I think Robin is right that we will not see a
> FLT>>  combination of disparate solutions such as ILNP+IRON both
> FLT>>  being deployed in conjunction. What is quite possible, however,
> FLT>>  is a combination of IRON+HIP since HIP is only instrumenting
> FLT>>  the hosts and can be used perfectly well over an IRON network.
> FLT>>  Still, why would such a combination be *required* when it may
> FLT>>  not actually even be desireable in all cases? Suggested change
> FLT>>  is to replace the above phrase with the phrase: "are possible."
>
> FLT>>  Strike the phrase "renumbering and". Renumbering would
> FLT>>  imply that the end system's endpoint address changes
> FLT>>  when in fact it is only the end system's locator address
> FLT>>  that changes. This is true for both MOBIKE and Mobile IP,
> FLT>>  and also applies to the kinds of mobility solutions
> FLT>>  associated with the CES architectures.
>
> FLT>>  OK.
> FLT>>  Not OK. It should be perfectly OK for mobility to interact
> FLT>>  with the routing system as long as the routing churn is
> FLT>>  localized and minimized. Strike this sentence.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Nov 2010 07:52:15 -0800

And just in time for the holidays, for those who would like
a litte extra security with their scalable routing and
mobility solution...

Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, November 23, 2010 7:30 AM
To: [email-masked]
Subject: I-D Action:draft-templin-ironmike-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IRON and MOBIKE
	Author(s)       : F. Templin
	Filename        : draft-templin-ironmike-00.txt
	Pages           : 11
	Date            : 2010-11-23

The Internet Routing Overlay Network (IRON) is a new routing and
addressing architecture based on encapsulation of inner network layer
packets within outer network layer headers using a non-broadcast,
multiple access (NBMA) virtual interface model.  The IKEv2 Mobility
and Multihoming Protocol (MOBIKE) allows a Virtual Private Network
(VPN) client to keep a connection to a VPN gateway active across
multiple network points of attachment or while moving from one
network point of attachment to another.  This document examines the
similarities between IRON and MOBIKE, and observes that they are
addressing the same fundamental networking objectives but with
differing signaling mechanisms and differing security properties.  It
further proposes ways in which the basic MOBIKE model could be
extended through adoption of IRON architectural constructs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-templin-ironmike-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 23 Nov 2010 16:34:58 +0000

> Patrick Frejborg
> Sent: Tuesday, November 23, 2010 8:03 AM
> To: George, Wes E [NTK]
> Cc: RRG; Robin Whittle

> think you are referring to my I-D and thus I feel an obligation to
[WES] well, I was being more general, but I do appreciate your response.

> applications needs to be ported and that is very expensive.
[WES] The concept of IPv6 = forklift upgrade and therefore won't happen is FUD, pure and simple. Yes, there will be equipment replacements required, and yes some kit will *never* support IPv6. But ultimately, there is a period in time after which most equipment purchased will support IPv6. In my own network, I had to wait 2 years for a lot of our existing EOL hardware to be replaced for other reasons (because it was out of memory or didn't support IPv4 features we needed). Organically, as the new hardware was deployed, I had support for IPv6, and didn't have to spend a bunch of money forklift upgrading my network to get it. So it's about timing - waiting for the technology refresh that is going to happen independently of IPv6. (n.b. I do realize that this is splitting hairs, but it makes a difference because it's taking advantage of an investment we had to make anyway instead of forcing a new one for something that doesn't generate much in the way of incremental revenue)

As I said in my message to Noel, IPv6 is a foregone conclusion. IPv4 doesn't scale to all of the things for which we need to have IP addresses today, let alone in the future, except with NAT. NAT by nature, especially multiple layers as in NAT444 makes IPv4 a second-class citizen. This is not to say that IPv4 is going to go away anytime soon, but what you're talking about is a long-tail problem. Right now, we have to make any IPv6-only things out there talk to the IPv4-only internet because that's the majority, so we either do NAT64 or run them dual-stack. In another year or two, enough things will be dual-stack that IPv6 only connectivity won't be a major issue, especially within certain communities of interest. And similar to when we started sticking gateways in front of SNA implementations to make them speak TCP/IP, we'll stick gateways in front of a rapidly shrinking pile of old kit with obsolete IPv4-only network stacks so that they can reach the rest of the IPv6 world.

> But I think you will not stop to sell IPv4
> to be ignored by any service provider (carrier or content)
[WES] No, we're not going to stop supporting IPv4 before it makes sense to do so. However, CGN and its variants are stopgap measures until IPv6 support is there, not a means to indefinitely prolong IPv4. They don't scale,  they don't work with every application, and the less of them that we have to use, the better. As I've been telling people who cling to legacy IPv4-only installed base as a reason to focus on CGN or other IPv4 extension methods as anything but a temporary, necessary evil - how long is it really acceptable to assume that obsolete equipment should be able to connect to the network as it evolves? In the US, we have a lot of obsolete mobile phones (including some non-replaceable embedded OnStar modules in cars) that have no network to talk to because there is no longer an analog GSM network, we have a bunch of analog TVs that can't get signal with rabbit ears anymore, etc. I don't understand why we continually try to shield end users from the unfortunate concept that their kit does eventually become obsolete and need to be upgraded to continue providing the same service. Even worse, we try to force network providers to invest in solutions to perpetuate this, thereby shifting the cost.

> thus there will be no killer application for IPv6,
[WES] Disagree. Fully functional end-to-end Internet is IPv6's killer application. While it's true that your average home broadband user, and even many enterprises really don't care whether their service is delivered over IPv4, IPv6, or Avian Carrier, they do want it to work. And based on what I'm seeing from ISPs who have been testing things like NAT444, the increasingly subpar service that IPv4 will provide as we run out of addresses will serve as an incentive to move to IPv6, even if it means that they have to buy a new widget to do it.

>startups will not get
[WES] Again, FUD. Turned the other way, if they develop only for IPv4, I wouldn't fund them because they have no viable business plan for long-term growth. I've been hearing that the US may start requiring companies to include IPv6 readiness in their business risk in their 10K filings, underscoring the notion that IPv6 is a requirement if you want to have a business that grows. Yes, it may not make sense for the next Facebook to be IPv6 only today, but definitely dual-stack, and there are plenty of places where IPv6-only does make sense, and that will continue to increase.
> if I have
[WES] See above regarding killer app. I concede that enterprises who already have enough IPv4 space may be slow to adopt IPv6 in their enterprise by comparison to the growth markets, but they have people who want to be able to work from home on a VPN, or work via a wireless device. You sure that's going to work through NAT444?
Any business that wants to communicate with China, India, Africa, etc, or provide services in the smart grid/Machine2Machine environment, or the mobile network should be implementing IPv6. One of the primary deployments of LTE in the US *requires* IPv6, even for internal services like IMS, and IPv4 is only used when necessary. Another mobile carrier in the US has publicly stated several times at places like NANOG and IETF mailing lists - "My devices are going IPv6-only. I'm going to be running NAT64 to reach IPv4 content. So you can either support IPv6, or I'll support it for you. Wouldn't you rather have control of how your service performs towards my customers?"
And I think our colleagues in Beijing were quite clear about China's plans for IPv6. Should I go on?

Wes George

---

From: Tony Li <[email-masked]>
Date: Tue, 23 Nov 2010 08:58:56 -0800

Fred,

Thank you for your comments, but the last call for the document closed on Nov. 12.

Tony

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 23 Nov 2010 13:08:55 -0800

>>    Ideally, such mechanisms should completely decouple mobility from routing.
>>
>> FLT >> Not OK. It should be perfectly OK for mobility to interact FLT 
>> >> with the routing system as long as the routing churn is FLT >> 
>> localized and minimized. Strike this sentence.

>[WES] I disagree with your recommendation here Fred, but for purely semantic reasons. 
>http://wordnetweb.princeton.edu/perl/webwn?s=ideal
>Absent any other considerations, that is, ideally, the proper solution is to decouple 
>mobility from routing. In a more practical implementation (ie not a completely ideal one), 
>it might be ok for mobility to interact as you are saying, but I don't think that the 
>sentence as written says that this is prohibited, only that it's not the most preferable implementation.

If one spends time in MANET networks as I do, mobility and routing are the same thing. By contrast, if one spends time in so-called mobile networks, the mobile entity moves in reference to a comparatively stable infrastructure. In the latter case, communications latencies are reduced for the moving entity if a feedback mechanism exists to update the routing infrastructure to a more current point of attachment. However, as Fred Templin stated, this needs to be done in such a manner that it does not impact routing convergence.

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Tue, 23 Nov 2010 21:09:37 +0000

> Sent: Tuesday, November 23, 2010 4:08 AM
> Subject: Mobility, Loc/ID Separation, ILNP, LISP-mn, TTR Mobility, IPv4
> & IPv6
> 
[WES] Welcome to my nightmare and the resulting paradigm shift about to hit
the mobile industry. IP bit carriage is already becoming a commodity on the
wireline network, as services are primarily over the top. The ISP is
becoming today's power company. We don't care where the power comes from, as
long as you deliver it reliably and cheaply. The challenge is to make money
in said commodity business, which means driving out costs. Mobile operators
may protest and kick and scream, but given the bill of goods that they're
selling - ubiquitous access to the "cloud" and high-bandwidth, always on
applications (that are provided by a third party) on new fancy devices that
go well beyond a telephone, the days of a walled garden are numbered, at
least in my opinion. 
Never mind the fact that there are incentives to keep mobile to mobile
traffic as local as possible, rather than carrying it back to some anchor
point and back out to the same tower. Even if there are still gateway and
setup functions provided by the mobile carrier, end to end connectivity has
benefits. 

> would not hold up in court.
[WES] Well, ultimately that's true of a lot of these proposals, that
competent programmers could build an implementation and no one needs to wait
for the IETF. However, I'm not a programmer, and I don't have a passel of
them at my disposal nor the funds to bankroll them, so it ends up falling to
those who came up with the idea to seek support among like-minded folks,
either in the research or vendor development community to get an
implementation stood up as a proof of concept. So much like many inventions,
the key is now to convince some "investors" to help you implement so that
you can show how good of an idea it is, instead of just being convinced of
it yourself.

>    separated and my analysis would be different.)
[WES] Many modern routers no longer specify IPv4 vs IPv6 in their scale
targets because they assume you'll be running both. They talk about the
entire routing table, and if there are things like TCAM or memory slots,
IPv4 takes one slot, IPv6 takes two, so it's dependent on how many of each
you have together. Sure, running single stack will improve the scale of the
one routing table considerably, but it's still a finite resource. Keep in
mind that many edge routers are also holding huge L3VPN routing tables (as
big as or bigger than the global table), so some may realistically be
nipping at that magic 1M route threshold in a year or two.
 
> The only scaling difficulty would arise if there were
[WES] Unfortunately that's exactly what is happening. Every time I turn
around, especially in the RIR community, the refrain is "renumbering sucks,
we have plenty of IPv6 space, so give me PI space so that I don't have to
ever do it again, even (especially) when I want to tell my upstream ISP to
get stuffed." Further, in an attempt to make IPv6 deployment as attractive
and easy as possible, RIRs are always toying with some new idea about how
they might make it easier for people to get PI space, up to and including
proactively assigning a block to every ASN in the table. Those who bring up
concerns about routing table slot usage are usually handed the old chestnut
"$RIR doesn't create routing policy, we just assign addresses, so that's not
our concern."
Even if we stay with PD, multihoming and TE mean that deaggregation is
pretty much expected. I agree that the growth rate will be less than with
IPv4, but it's still a consideration. If anything, it just gives us a more
realistic timeframe to get a fix implemented, rather than resetting the
clock for when we should start worrying about it.
>    grow to a problematic size.
[WES] There's some truth to that. However, as I've mentioned here before,
this scale issue does go beyond the DFZ, and when you start looking at the
amount of routes you carry internally prior to being able to announce that
aggregate to the rest of the DFZ, the design and how much aggregation you
can do regionally becomes a concern.
 
> notion hasn't been disproven.
[WES] It's not counter-intuitive. Vendors didn't always rule the IETF, and
many good ideas are the result of "some bloke." However at this point,
running code is the method by which to prove or disprove any of these
implementations, as I would hope that people far smarter than me have
already looked at these in great detail over the last 2-3 years and
identified the theoretical issues and corner cases and potential fatal
flaws. Put simply, it's been debated to death now, and I expect that you've
refined the basic design as much as you will be able to as a result of those
conversations. Everyone on the list who maintains that an identified flaw in
a given implementation isn't actually fatal and that critics just need to
understand the implementation better can be vindicated by showing test
results from a sample implementation, no matter how rudimentary.

Wes George

---

From: Robin Whittle <[email-masked]>
Date: Wed, 24 Nov 2010 12:34:01 +1100

Hi Toni,

I can't condense what I wrote without making a mess of it, but here is
what my original message concerns.

This is to let you know whether you might be interested in spending 20
minutes or so reading and thinking about the message itself:

  http://www.ietf.org/mail-archive/web/rrg/current/msg07587.html

Please don't debate the following text, since it is inadequate on its
own.  I haven't yet read Wes' response.

  Wes George wrote to challenge my assertion that there's no
  tearing hurry regarding scalable routing.  He wrote that he
  was concerned about his company - Sprint - having to pay $$$
  and go to much trouble before long to upgrade their routers
  to cope with the growth in the "DFZ routing table" - shorthand
  for the number of routes advertised in the interdomain routing
  system.  The problem growth is with IPv4, but the same thing
  could in principle happen with IPv6.

  He also wrote that he saw no option but to use IPv6 for future
  large mobile phone networks.

  He also wrote (in my interpretation) that he was hopeful or
  expectant that instead of ISPs having to keep spending money
  to keep the Internet running, in part due to scaling difficulties,
  that application and stack programmers would work to make
  hosts operate in new, more scalable, ways.  This would alleviate
  the huge expenses ISPs face for new routers or whatever every
  few years and so reduce what they need to charge customers.
  I stated why I believe this hope to be completely unrealistic.

  I replied by narrowly qualifying the scope of my "no tearing
  hurry" assertion and agreeing with him about there being an
  urgent need (in the context of the next 5 to 10 years) for
  scalable routing solutions, in particular regarding mobility.

  Subject to an assumption, which I am not at all sure is correct,
  I agreed with him that IPv6 would soon be widely used in 3G
  mobile "phone" (and whatever else these things do) networks.

  The assumption is that operators will find it easier or better
  to sell a service with native IPv6 connectivity, presumably with
  a tunnel to an IPv4 NAT box, to do dual stack but with the IPv4
  connection behind NAT, than to provide a purely behind NAT IPv4
  service.  I am agreeing with his statement that there's not
  enough IPv4 space to support the continuing expansion of 3G etc.
  mobile networks in a manner where each device gets it own global
  unicast IP address.  That said, I wonder whether 3G networks
  provide global unicast addresses in general.  Are many or most
  of them providing NATed IPv4 addresses at present?

  I discussed my understanding of the mobility options for IPv6 -
  including those which are proposed but yet to be developed:

     1 - MIPv6 - which Wes mentioned he did not favor
     2 - Loc/ID Separation, such as ILNP
     3 - LISP-mn
     4 - TTR Mobility (my proposed architecture) with Ivip or LISP

  I discussed why I believe 2 and 3 are completely inadequate and
   tried to interest him in 4.

  I also discussed the potential growth in the number of IPv6 DFZ
  routes, and queried whether the limit for routers was the total
  number of routes for IPv6 separately from IPv4, or whether the sum
  of the two was more important.

   - Robin

---

From: Robin Whittle <[email-masked]>
Date: Wed, 24 Nov 2010 12:56:40 +1100

I am responding to Fred about the text of the draft and to Joel about
whether the forthcoming RRG Design Goals RFC is intended as an
historical document.

Hi Fred,

>    global routing system (whose solution may, or may not, depend on the

but this phrase is meaningless now:

    the decoupling of end-site addresses from globally routable
    prefixes

I am sure that at the time this was written, April 2007, that this was
intended to describe LISP and any other similar architecture.  At the
time, LISP had no Proxy ITRs (PITRs, PTRs) and so the DFZ routing
table had no prefix which covered the addresses used by EUNs (end-user
networks).  So the phrase had its intended meaning when it was first
written.

In December 2007, LISP adopted PTRs, which advertise one or more
large (short number of fixed bits) prefixes each of which covers the
address space used by multiple EUNs.  This means that one or more of
these PTRs will attract packets sent to these EUNs from a network
without ITRs, and will tunnel them to the correct ETR.  I introduced
the same concept in June 2007 for Ivip, with the intention it also be
applied to LISP.

The above phrase doesn't apply to any architecture I can think of,
since Ivip, LISP and I assume IRON ensure that all of the new scalable
class of EUN address space is advertised in the DFZ so packets from
non-upgraded networks will be tunneled to the EUNs.

> FLT >> not actually even be desireable in all cases? 

I entirely agree.

> FLT >> Suggested change

I am not sure what you are suggesting, but the requirement of Loc/ID
Separation is wrong, in my view, as is any requirement that the chosen
architecture be compatible with Loc/ID Separation.

> FLT >> localized and minimized. Strike this sentence.

I agree.  "Routing" is never defined, but it arguably includes not
just the existing routing system but whatever ITRs, ETRs, DITRs/PTRs
and TTRs are added by Ivip or LISP, or whatever devices in IRON
provide comparable functions.

The draft seems to be based on the assumption that the routing system
can never scale, even by adding something like LISP, IRON or Ivip to
it - and/or that adding anything to it is inherently undesirable.
Therefore, it requires Loc/ID Separation: making the hosts do all the
extra work for multihoming, inbound TE, portability (of Identifiers)
and mobility.

Hi Joel,

You wrote, in part:

> But the document is not the goals for some new set of work.  It
> is the goals we roughly agreed on early on.  The purpose of
> publication is for the historical record, not to drive some new
> set of work.

I disagree with your assertion that this forthcoming RRG Design Goals
RFC is intended as some kind of historical document - a record of what
we were thinking.  There's nothing about this in the draft and I don't
recall Tony stating anything to this effect.

The fact that the design goals draft was not updated or widely
discussed between July 2007 and November 2010 doesn't mean that most
or all RRG participants accepted the draft -00 of July 2007 as their
design goals.

I responded to the draft on the basis that it should be the best set
of design goals the RRG can produce in late 2010.

  - Robin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Nov 2010 21:22:08 -0500

I could be confused.  However, as far as I know, the RRG was not 
chartered to produce a design goals document for some other body to use.
So, while I can understand wanting to produce a design goals document 
for some hypothetical piece of future work,
1) without knowing what that future work is, I do not see how it is 
meaningful to produce a set of goals for it
2) I do not see how this research group can claim to produce such a 
thing within its charter.

Our current activities are focused on wrapping up our charter.
Creating a new charter for a successor research group is a very 
different task.  What it would, could, should, or might be I do not 
claim to know.

Yours,
Joel

On 11/23/2010 8:56 PM, Robin Whittle wrote:
...

---

From: Patrick Frejborg <[email-masked]>
Date: Wed, 24 Nov 2010 14:52:21 +0200

> [WES] The concept of IPv6 = forklift upgrade and therefore won't happen is FUD, pure and simple. Yes, there will be equipment replacements required, and yes some kit will *never* support IPv6. But…

[PF] What you are saying is true, most of the infrastructure is in
place and ready for IPv6 - but for enterprises there is a lot of
applications that needs to be ported and that is an expensive
operation.

> As I said in my message to Noel, IPv6 is a foregone conclusion. IPv4 doesn't scale to all of the things for which we need to have IP addresses today, let alone in the future, except with NAT. NAT b…

[PF] I agree with you, the legacy IPv4 will not scale - either NAT444.
Once an end users gets behind CGN there are several options
- it might work depending on which services are used
- if it is a nightmare then the end users switches to IPv6, depending
which services are available over IPv6 or switches to an ISP that
offers better IPv4 connectivity
- make use of a IPv4/IPv6 application layer gateway, something similar
as a B2BUA in the SIP world

About SNA, I still see applications using SNA encapsulated inside
TCP/IP, simply because it is too expensive to port the application to
the "new world".

> [WES] No, we're not going to stop supporting IPv4 before it makes sense to do so. However, CGN and its variants are stopgap measures until IPv6 support is there, not a means to indefinitely prolong…

[PF] Have a look on the financial situation in the old economies (the
U.S. and Europe)

> [WES] Disagree. Fully functional end-to-end Internet is IPv6's killer application. While it's true that your average home broadband user, and even many enterprises really don't care whether their s…
 [PF] Yes, but what I had in mind is an extended IPv4 where 32 bits
are reserved for the core and 32 bits are reserved for the edges -
happens to be the same size as IPv6, i.e. 64 bits (prefix space). The
old devices can still use IPv4 for internal communications with legacy
applications, once a device needs to communicate outside the edge
network it needs to use the 64 bit address space, which is backwards
compatible with the legacy IPv4 address space. No NAT, no tunneling
nor locator rewriting with the help of an identifier is mandatory
though those technologies can be used if desired.

Patrick

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 25 Nov 2010 12:47:46 +0900

On Wed, Nov 24, 2010 at 9:52 PM, Patrick Frejborg <[email-masked]>wrote:

> though those technologies can be used if desired.

At least, there's one who like this, the 'unprofessional' me.

A further exploration I might do is name the nodes, not the interfaces like
now, with the IPv4 addresses... which way you might not like.

Anyway, I support this core-edge decoupled addressing.
-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 25 Nov 2010 13:20:27 +0900

I don't think decoupling mobility from routing should be listed as a design
requirement. I don't think we can eliminate the possibility of routing
inherently providing mobility.

On Wed, Nov 24, 2010 at 12:47 AM, George, Wes E [NTK] <
[email-masked]> wrote:

> [WES] I disagree with your recommendation here Fred, but for purely
> semantic reasons. http://wordnetweb.princeton.edu/perl/webwn?s=ideal
> Absent any other considerations, that is, ideally, the proper solution is
> to decouple mobility from routing. In a more practical implementation (ie
> not a completely ideal one), it might be ok for mobility to interact as you
> are saying, but I don't think that the sentence as written says that this is
> prohibited, only that it's not the most preferable implementation.
>
> Wes George
>
> This e-mail may contain Sprint Nextel proprietary information intended for
> the sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete all
> copies of the message.
>

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 25 Nov 2010 13:22:29 +0900

In that case, please just close the discussion and freeze the document on
your discretion.

On Wed, Nov 24, 2010 at 12:51 AM, Joel M. Halpern <[email-masked]>wrote:

> goals we roughly agreed on early on.  The purpose of publication is for the
> historical record, not to drive some new set of work.  New work will have to
> define its own goals.
>
> mobility solutions.  I am pretty sure that there exist solutions with the
> properties enumerated in the document.  Given that existing solutions, while
> they may have implicit notions of identity, do not have a clear distinction,
> I do not see the problem with describing the existence of solutions which
> use renumbering and tunnelling.  We could, perhaps, debate which solutions
> have that property.
>
> Yours,
> Joel
>
>

-- 
DY

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 25 Nov 2010 16:47:14 +0200

> now, with the IPv4 addresses... which way you might not like.

I need to look into that, currently my day work is interfering too
much but this topic is on my to-do list

> Anyway, I support this core-edge decoupled addressing.

Thanks!

And just to clarify for Wes and others, the edge address no longer
need to be globally unique - in the interim version it needs to be
regionally unique but in long term it is only unique in the local edge
network. RC 1918 changed the Internet architecture quite a lot and why
not change the addressing scheme so that it describes better the
Internet that we today have in place - that is what physics and math
formulas do, i.e. they describe natural phenomenons and not creating
them ;-)

Patrick

---

From: Toni Stoev <[email-masked]>
Date: Fri, 26 Nov 2010 01:38:31 +0200

> much but this topic is on my to-do list

Toni Stoev likes this.