Subject: [rrg] Solution space summary: rejection phase

From: "William Herrin" <[email-masked]>
Date: Tue, 23 Dec 2008 22:20:53 -0500

Draft #6 of the Summary of Routing Architectures discussed in the RRG
is now available at:

http://bill.herrin.us/network/rrgarchitectures.html

With this version, the draft is closed to additions. I now ask you to
propose rejecting particular strategies or strategy variants on the
grounds that they are in some way unacceptable.

Changes from draft 5 to draft 6:

* Strategy A now has method group A5: how we route RLOCs in the Internet core.
* References to "layer 4" changed to "layer 4/5" in order to express
that we're looking at both transport and session semantics, not just
transport semantics.
* A3b specifies that the analysis element is not necessarily under the
control of a particular party.
* A4, statements to the effect "IPv4 is abandoned" are changed to "Use
a different A4 variant for IPv4"

Although the draft is formally closed to additions, I'm still willing
to add things where there is really no doubt they belong there. I may
ask you to demonstrate a consensus on the mailing list that they
belong first. I'll be as even-handed as I can. Please don't take me to
task, either for adding something late or for asking you to
demonstrate consensus.

PHASE TWO: REJECTION

Robin, now it's time to tell us why everything but Strategy A won't work. ;-)

I'd like to ask everyone to nominate strategies, strategy variants or
even phrases in a particular sentence for rejection. Maybe you think
it can't work. Maybe you think it fails to address the problem.
Whatever your reason, post it and call for a strong consensus.

What is strong consensus? Strong consensus means that:

A) Folks bother to express an opinion. If 3 people agree and nobody
else expresses an opinion, that isn't a consensus.
B) Almost nobody disagrees. If 20 people say yes and 10 people say no,
that's a weak consensus. If 20 people say yes and 2 people say no,
it's a strong consensus.

I ask you to restrict nominations to the specific words that are in
the document. I know that seems obvious, but I don't want anyone to
get mad when I refuse to act on a proposal like, "We should reject
anything that doesn't deal with XYZ problem." If you think XYZ problem
is important, pick the strategies and strategy variants that you think
fail to address it and nominate them for rejection instead.

As we achieve consensus on the rejections, I will reorganize the
document to reflect that we believe those approaches should be
abandoned, along with a few words about why.

I'll try to move to phase 3 in the second half of January. In phase 3
I'll seek consensus on which of the remaining strategies are promising
enough to merit engineering work in the IETF.

In another message, I'll call for the rejection of "Strategy F: Do
nothing." You're welcome to copy the format of that message. You're
also welcome to use a format of your own, as long as everybody clearly
understands exactly what part of the document you propose to reject
and opinions clearly express whether they intend that the document
component be rejected or not.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Stefanos Harhalakis <[email-masked]>
Date: Sat, 27 Dec 2008 01:07:11 +0200

Hello there,

> http://bill.herrin.us/network/rrgarchitectures.html

I'm new to this list/area (so be gentle :-) and I've just read the above page.

I find it weird that while the title is "Routing table size problem" there is 
a lot of talk about mobility (plus other things like PMTUD (?)). Even though 
those are real-world problems, I see that you're trying to address them at 
the same time. AFAICT from the document, this complicates things a lot.

For example, criticism #1 for strategy B seems only related to mobility and I 
see it as a problem no matter how routing works (except perhaps from an 
unknown-yet very-special case).

>From what I understand from the document, if there is ever a GUID/SID/LOC 
breakup, the core routing will only deal with LOC, while the TCP (strategy B, 
criticism 1) will have to do with SID. Also, shouldn't firewalls have to work 
with GUIDs instead of LOCs ? (strategy B, criticism 2)

Finally, some comments: 

for Strategy E: Assuming that managers, politics and economy will efficiently 
solve a technical issue that IETF and technicians can't, seems somehow... 
well... wrong... :-)

for Strategy F: 6000$ per year per prefix seems like a small amount. Some 
spam/chain letters cost a lot more per day or even per hour. A 2002 study [1] 
showed that for that year, spam costed 8.9 billion dollars in US only [1]. 
Many TCP implementations send 4 bytes of NOPs in every packet, which should 
add to a lot more than the 6000$ per year. Not very efficient compression of 
the google logo at its main page may cost more. The list of examples can grow 
really long. Most probably the cost of whatever transition is decided will be 
more than those 6000$ may sum for the next 30+ years. So, I propose that cost 
isn't considered as the main reason to make such a change and thus assume 
strategy F as correct but not adequate.

Hope the above helps.

[1] http://www.d-silence.com/feature.php?id=257
_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: Robin Whittle <[email-masked]>
Date: Mon, 29 Dec 2008 22:24:40 +1100

> Robin, now it's time to tell us why everything but Strategy A won't work. ;-)

I am calling for strong consensus on rejecting all strategies but A.

Strategy B

  This is a host-based solution.  There are two reasons I believe
  this should be rejected.

  1 - The most important and fundamental reason is that it pushes new
      responsibilities to every host on the Net - and that these
      responsibilities concern things which happen in the network -
      the DFZ, the ISP(s) and perhaps the border routers of each
      end-user network.

      Making every host responsible for solving these problems
      involves greater complexity in every host and additional
      flow of packets to and from hosts in order to perform
      these new functions.  This adds complexity and cost to
      all hosts and is a particular cost burden on hosts with
      narrow, expensive, links - such as any host on a radio
      link.

      The unreliability and delays inherent in slower - especially
      radio - links will impact the ability of these hosts to
      perform these functions.  So the extra management traffic and
      the dependency on that traffic will be particularly burdensome
      for any radio-linked host.

      Most fundamentally, it is pushing the solution to a network
      problem to hosts.  I think this is wrong in principle, as well
      as having obvious practical problems.  One reason it is wrong
      in principle is that a single change in the network could be
      handled by a much smaller number of active elements, via
      a Strategy A solution, than the potentially boundless number
      of hosts which would have to handle it in a Strategy B
      solution.

      More here:

        Fundamental objections to a host-based scalable routing
        solution
        http://www.irtf.org/pipermail/rrg/2008-November/000271.html

  2 - The host changes which are requires are incompatible with the
      need for a scalable routing solution to be introduced easily
      and with substantial immediate benefits for all those who
      adopt it.

      It is agreed AFAIK that we can't force the solution on anyone.
      So we need to develop something which most end-user networks
      (and their ISPs - or potentially all networks and all hosts)
      will want to adopt.  They will only adopt it if it provides
      substantial immediate benefits over their costs and risks.

      Host changes - especially changing APIs and applications -
      are extremely hard to implement.  AFAIK, the benefits of
      Strategy B only occur when both hosts in a session have
      the upgrades.  Consequently, assuming the benefits are
      substantial (I might argue they are not), early adopters
      only get slight benefits, since only a small fraction of
      sessions, on average, are with other hosts with the
      upgrades.

      I could write more about this, but I think it should be
      obvious to anyone that there is no way we can make a
      solution attractive to everyone who needs to deploy
      Strategy B, due to the inherent difficulties rewriting
      applications and due to the initially very limited
      proportion of hosts which will have the upgrades.

      A further argument along these lines is that even if
      90% of hosts were upgraded, Strategy B would provide
      benefits on average to only 90% of sessions.  I think
      many people would find that too low when it concerns
      multihoming.  By contrast, some Strategy A schemes enable
      benefits to 100% of sessions (LISP PTRs, Ivip OITRDs) -
      since they do not require any changes in the other host
      or that host's network.

Strategy C

   Despite a decade or two to research such things, no-one has
   come close to devising a routing system which could serve
   the needs of the interdomain routing system, as BGP does
   today, and which could scale to handling the number of
   prefixes we need to solve the routing scaling problem.

   Although we have no clear target, I think there would be
   consensus that the scalable routing solution needs to
   provide multihoming, TE (and I think "portability) to
   at least several hundred million end-user networks.

   Since there is no sign of a routing system which could
   scale to this number of advertised prefixes - including
   by souping up BGP in some way - I suggest we should form
   a strong consensus to reject this strategy.

   Further arguments include there being no chance we could
   introduce a new routing system without prohibitive
   disruption, and that some of the most discussed alternatives
   (geographic aggregation) do not respect the business needs
   of ISPs.

   One of the LISP folks pointed me to a critique of "compact
   routing":

      On Compact Routing for the Internet
      Dmitri Krioukov, kc claffy, Kevin Fall, Arthur Brady
      ACM SIGCOMM CCR, v.37, n.3, p.41-52, 2007

   which may be relevant in deciding to reject Strategy C.

Strategy D

   This involves souping up the FIBs of routers.  The routing
   scaling problem might at some time involve FIB costs and
   performance, but now and in the foreseeable future, the
   scaling problem relates to the undesirability of trying
   to make the global BGP control plane work with the
   number of prefixes required (hundreds of millions) to
   provide (with current techniques) the multihoming, TE
   etc. needs of end-user networks in the future.

Strategy E

   This is not a proposal which solves the problem to anything
   like the degree we need to solve it.  Its primary effect would be
   to create a different set of barriers to end-user networks gaining
   multihoming, TE etc.  Currently the barriers are enforced by
   making it hard to get PI address space and by discouraging
   end-user networks from advertising too many prefixes in the DFZ.
   With this proposal, they may be able to get PI space more easily,
   but they would need to pay to advertise it, by the prefix.

   The money would compensate ISPs who pay for the larger DFZ
   routers and this would to some extent allow more prefixes to
   be advertised before the ISPs faced unreasonable cost burdens.

   However, this is just throwing money at the problem.  Without
   fundamental changes, the current BGP-based interdomain routing
   system will never cope reliably with hundreds of millions of
   end-user network prefixes, or with the rate of change in the
   way they are advertised in order to provide TE and multihoming.

Strategy F

   We should reject this, because (I believe) at least one of the
   Strategy A schemes is a good solution to the problem.

   - Robin

---

From: Lan Wang <[email-masked]>
Date: Mon, 29 Dec 2008 11:09:42 -0600

> I am calling for strong consensus on rejecting all strategies but A.

I agree with the reasons listed below for rejecting all strategies  
but A.  Our HotNets 08 paper listed some of the same objections to  
Strategy B.

Lan

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Dec 2008 09:59:19 +1300

> http://bill.herrin.us/network/rrgarchitectures.html

I believe it's pretty easy to reject C, D, and E for the reasons
summarised in draft #6.

As far as G goes:

> Strategy G.
> 
> Make everybody attach to only one ISP using IPv6 and the ISP's single set of PA addresses. (Actual result of RFC 1887 § 4.4.3)
> 
> Major criticisms:
> 
> Tried it.

This strategy ("Make everybody attach to only one ISP") was never
seriously proposed. The IPv6 plan has been based since ~1996 on multiple
PA prefixes per site (and therefore multiple addresses per host), which is
suggested by section 4.4.2 of RFC1887. That's still the plan of record
for IPv6.

RFC1887 never had any authority anyway - it was essentially a WG discussion
document.

So, we can certainly reject G, because it doesn't work, but please don't
assert that it was ever recommended for IPv6.

    Brian

---

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 09:40:56 +1100

Hi Lan,

Thanks for this:

> I agree with the reasons listed below for rejecting all strategies but A.

You wrote:

> Our HotNets 08 paper listed some of the same objections to Strategy B.

  Towards a Future Internet Architecture: Arguments for Separating
  Edges from Transit Core

  Dan Jen (UCLA), Lixia Zhang (UCLA), Lan Wang (University of
  Memphis), Beichuan Zhang (University of Arizona)

  (HotNets-VII) Calgary, Alberta, Canada October 6-7, 2008
  http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

This paper contrasts "separation" of end-user networks from the core
(by network centric mechanisms) with "elimination" of end-user
networks from the core, by means of each network (probably each host)
having addresses from each ISP.  I understand that "elimination" is
typically proposed in terms of new host responsibilities and functions.

  - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Dec 2008 11:57:11 +1300

> http://bill.herrin.us/network/rrgarchitectures.html

Grossly oversimplifying, strategy B is unworkable for IPv4
and very close to the plan of record for IPv6.

Robin has been eloquent about the problems with this strategy,
and I think that for legacy hosts those arguments are undeniable.
But people don't seem to have really absorbed that IPv6 stacks,
and applications updated to use them, already work with multiprefix
PA address assignments. This is a form of B. The negative aspect
is that transport sessions will fail when there's an address change.
There are measures that can correct that, long term and step by step.

The other point about this approach to strategy B is that it doesn't
break strategy A, if a little care is taken. That's because B is
really not a change in the IP model and is pretty much orthogonal
to the routing system. (Actually, that's exactly why it emerged as
the deployment model for IPv6.)

So, my conclusion is to forget about strategy B as far as IPv4
is concerned, but treat it as orthogonal to strategy A as far as
IPv6 is concerned. That doesn't mean the RRG has to do anything
about it, except bear in mind that IPv6 already supports a form
of strategy B, and move on.

    Brian

---

From: "William Herrin" <[email-masked]>
Date: Mon, 29 Dec 2008 18:51:32 -0500

>> I am calling for strong consensus on rejecting all strategies but A.

I respectfully disagree. I believe there are useful solutions to be
had in strategies A, B, D and E. Here's why:

Although strategy B may have more up-front deployment issues than
strategy A, we'll tend to get a better result in the long term by
tackling the problem at its root as strategy B does. Strategy A comes
at the problem from the side, creating a slew of nasty subproblems,
like with PMTUD. I have no opinion as to whether strategy A or
strategy B is a better solution overall, or even a better starting
point. I do believe both efforts would benefit from seeing both
through engineering and then letting the market choose.

As discussed months ago, parallel processing of the RIB combined with
techniques to compress the FIB as contemplated by strategy D would
extend the useful upper bound of routes in the BGP RIB by at least one
and possibly two orders of magnitude. Though this does not extend
multihoming as far as some of us would like, it does usefully extend
it with far less difficult deployment issues than either Strategy A or
Strategy B.

Although strategy E is loaded with political minefields, the technical
portion of its implementation is both trivial and fully backwards
compatible. Strategy E resolves the most serious routing scalability
problem, that of keeping the Internet core stable. While it would be
nice to solve the other multihoming problems, the only critical one is
core stability. I question the wisdom of throwing this approach away
prior to demonstrating market acceptance of an alternative.

Would anyone object to me assuming that those in favor of rejecting
all but strategy A also favor proposals to reject each of the others
individually?

Regards,
Bill Herrin

---

From: "William Herrin" <[email-masked]>
Date: Mon, 29 Dec 2008 19:13:48 -0500

> and very close to the plan of record for IPv6.

Hi Brian,

I hate to be a pest, but does this mean you favor eliminating strategy
B from consideration? Or oppose?

I respect that your views on the subject are complex and that you
would choose to ask and answer a more subtle question. But I didn't
ask a subtle question.

> break strategy A, if a little care is taken.

There are also forms of strategy A that can evolve into strategy B
over the long term. Architect your ITR so that the pushed data load
doesn't render it unreasonable to place the ITR on the end-user's PC
and then build the ETR dumb. With the session knowledge not available
to the network ITR, the host ITR can make a better decision. Over time
it becomes a standard part of the stack.

> PA address assignments.

Name three such applications. No points for layer-7 multihoming or
applications which are obscure even within the IPv6 community.

I'm not the IPv6 expert that you are Brian, but your statement does
not reflect operations-level reality.

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Dec 2008 14:01:20 +1300

Bill,

> B from consideration? Or oppose?

Quoting Joel:

  "So I would hate to see either A or B declared out of bounds for this community."

But it is my opinion that B is a lost cause for IPv4. If someone can write
a proposal that proves that wrong, I'd be delighted.

Below...

> applications which are obscure even within the IPv6 community.

Huh? No credit for stuff that works?

Look, IPv6 stacks all, or almost all, support RFC3484 address
selection. That means that *any* application upgraded to use the
IPv6 socket API works with multiple PA-prefix based addresses.
So I think you can make your own list. How many of them have
impeccable retry logic when an address fails I don't know,
however. That takes a lot of testing.

> not reflect operations-level reality.

What are you referring to there? (Off list if you prefer.)

    Brian

---

From: Steven Blake <[email-masked]>
Date: Mon, 29 Dec 2008 21:03:23 -0500

> http://bill.herrin.us/network/rrgarchitectures.html

What about Strategy H: Everybody uses NAT?

It's worth a discussion at least.

Regards,

// Steve

---

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 13:35:01 +1100

Hi Bill,

You wrote:

> tackling the problem at its root as strategy B does. 

Even if there were no difficulties deploying Strategy B host changes,
I would argue against B for the reasons listed here:

> Strategy A comes at the problem from the side, creating a slew of
> nasty subproblems, like with PMTUD.

I don't agree with your view that a network based solution (Strategy
A) is unnatural, "from the side" or whatever or that the root cause
of the routing scaling problem is a lack of functionality in the
hosts.  I believe your current problem statement is biased towards
the notion that the solution lies in adding responsibilities to hosts
(Strategy B).  I suggest extra text to make a more comprehensive
problem statement without such biases:

  http://www.irtf.org/pipermail/rrg/2008-December/000525.html

I don't agree with the view that providing multihoming, TE and
portability by adding functionality to the network (DFZ, ISP routers
and end-user CE routers) is unnatural or undesirable.

There are considerable problems with Path MTU Discovery in any
map-encap scheme: LISP, APT, TRRP and the map-encap modes of Ivip.

Six-One Router doesn't have PMTUD problems - though I think this is
not a good solution, since it is only for IPv6 and since it only
provides benefits if both networks are upgraded.

If we can do modest firmware upgrades to DFZ routers, then Ivip
doesn't need to go through its transitional map-encap phase, and
could be deployed from the outset using forwarding, via modified IPv4
and IPv6 headers:

  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf
  http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw
  http://www.firstpr.com.au/ip/ivip/ivip6/

So it is not true to say that all Strategy A proposals have PMTUD
problems.

Also, I think the PMTUD problems are solvable:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/

If, for some reason, we can't initially deploy an Ivip-like solution
with forwarding, then map-encap must be used at first.

Unless someone can point out fundamental problems with my IP4 and
IPv6 forwarding proposals, I will continue to believe that the
long-term best solution is a network based one (Strategy A), using
forwarding, rather than encapsulation.

So I think that the only use for encapsulation is to get a routing
scaling solution going before we could upgrade all the DFZ routers.

Since I am reasonably confident that the functions to be upgraded are
all in firmware (or will be in DFZ routers at the time we plan to
introduce the solution, say 2013 or so) I am reasonably confident
that with a bit of work at Cisco and Juniper (are there any other
manufacturers of DFZ routers?) the routers could all be upgraded by
the time we implement the solution.  Depending on the placement of
ITRs and ETRs, some or many internal routers need to be upgraded too
- but this is only for ISPs which adopt the solution.

> I have no opinion as to whether strategy A or

OK.  I still think it is fundamentally wrong to have hosts involved
in multihoming, especially mobile hosts with slow, expensive,
unreliable links - when at least one of the network-based Strategy A
proposals can solve the problem, without requiring any new host
functionality or management traffic burden, and while providing
substantial immediate benefits for early adoptors.

Brian wrote:

  http://www.irtf.org/pipermail/rrg/2008-December/000577.html

that the Strategy B host-based solutions are orthogonal to Strategy A
network based solutions.

I agree with this in some ways, and that the strategy B proposals are
unsuitable for IPv4.  However, if a Strategy A solution is the
solution, then we don't need any other.

Brian wrote that Strategy B is "very close to the plan of record for
IPv6".  Maybe so, but I think it is not close enough for our
purposes.  In particular, the Strategy B proposals (which so far are
not well documented) provide session survivability in a multihoming
service restoration setting, while basic IPv6 does not.

SHIM6 provides multihoming session survivability, but it does not
provide it in the the network centric manner which most end-user
networks want and need.  Nor does it provide portability of address
space - there would be major disruptions, costs etc. whenever
selecting a new ISP, not least regarding where IP addresses appear in
ACLs and other places inside and outside the end-user network.

I have no objection if some people want to develop new host
functions, protocols, APIs and suitably updated applications for such
hosts.  They would presumably remain backwards compatible with
existing hosts.

My point is that the RRG will not find a better solution to the
routing scaling problem within the Strategy B set of possibilities,
than in the Strategy A set, for reasons including:

1 - Strategy B doesn't work for IPv4. (There's not enough space
    to give every end-user network a slice of space from each of
    its ISPs' space.)

2 - Strategy B only delivers substantial benefits (robust
    multihoming for all or almost all communications) after all, or
    almost all hosts have upgraded stacks, APIs and applications.
    Ignoring the prohibitive difficulties in deploying these changes,
    this still has the major problem that be adopting Strategy B
    as a routing scaling solution, we force every host,
    including mobile hosts with slow, expensive, unreliable,
    last hop links to:

       Carry extra stack and probably application code complexity
       to do all the work for multihoming, TE and whatever so-far
       not invented approach gives the same ease of changing ISPs
       as portable address space.

       Carry extra management traffic which is required to
       perform these functions (thereby increasing costs and/or
       reducing the capacity available for user traffic).

       Make all user communications dependent on the successful
       and rapid conveyance of this management traffic.

Strategy B involves:

  1 - Forced migration of most end-user networks (and therefore
      almost all hosts and Internet services) to IPv6 - before
      the IPv4 routing scaling problem becomes unacceptable.

  2 - Forcing extra complexity, burdens and reduced performance
      into all hosts.  These may be a minor concern for a PC
      with a fast Internet connection, assuming the management
      traffic is to local destinations.  However, the management
      traffic is likely to be to the correspondent hosts.  It
      involves a major cost burden and/or performance degradation
      on any host with limited computational resources and/or
      with a slow, costly and unreliable last-hop link.

If we had no other alternatives, I guess we would pursue Strategy B.
 However, we have Strategy A alternatives, for both IPv4 and IPv6,
which have none of the problems just mentioned, including (Ivip with
forwarding) no PMTUD or packet overhead problems.

So I think it is OK for someone to pursue Strategy B if they wish.
Its just that Strategy B is not the way forward for solving the
routing scaling problem.  I suggest we eliminate it from further
consideration.

> it with far less difficult deployment issues than either Strategy A or

There is no mention in Strategy D or any other strategy for "parallel
processing of the RIB".

I think trying to split up the RIB into multiple CPU systems, each
with its own RAM (since RAM bandwidth is the problem, more than raw
CPU power, now we have 4 and 8 core CPU chips) is a nightmare.

Programming multiple computers to share a complex set of tasks like
this is costly, error-prone and will drive up the cost of all DFZ
routers, which is one of the things we need to avoid, if at all possible.

I thought most people agreed that FIBs are not the limiting factor in
DFZ routers today, or in the foreseeable future.

The costs and CPU and RAM limitations of the BGP implementations are
a serious problem, especially for routers with many neighbours.
Also, there are fundamental difficulties with the stability of the
whole BGP control plane.  For instance, with more and more prefixes,
a single outage causes changes in best path for more and more
prefixes, resulting in a greater flurry of messages, delays in
processing these, problems with stability of the entire network etc.

Are you suggesting we not reject Strategy D, or that we create a new
strategy involving FIB improvements and multiple CPU&RAM handling of
the RIB for all DFZ routers (or at least those with many neighbours),
while retaining BGP as it stands, with perhaps some incremental
improvements?

> prior to demonstrating market acceptance of an alternative.

Strategy E does not solve the routing scaling problem.  It does not
provide for more end-user networks having multihoming, TE or
portability except due to the marginal effects of such users paying
ISPs collectively to install bigger routers to handle marginally more
prefixes in the DFZ.

I suggest we reject it as a solution.  If we fail to find a solution,
or if the solution which the IETF adopts, develops and promotes is
not widely enough accepted, or fails technically, then Strategy E is
one of the possible outcomes.  However, it is not a solution.

> all but strategy A also favor proposals to reject each of the others

I support rejection of B, C, D, E and F, individually or collectively.

  - Robin

---

From: "William Herrin" <[email-masked]>
Date: Mon, 29 Dec 2008 21:49:00 -0500

> and end-user CE routers) is unnatural or undesirable.

Hi Robin,

As it happens, I don't agree with that view either. I think strategy A
is pretty good and it plays to our very solid experience with
tunnelling and VPNs.

I do, however, think it's premature to discard other approaches that
stand a reasonable chance of solving the problem. Strategy A has not
yet proven itself in market-accepted running code. When it has, the
other approaches can be retired.

> I support rejection of B, C, D, E and F, individually or collectively.

What about G?

Regards,
Bill Herrin

---

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 13:54:20 +1100

Hi Bill,

> it becomes a standard part of the stack.

What you describe is similar to Ivip's ITFH (ITR Function in Host).
However:

1 - ITFH is not intended to become a standard part of the stack of
    all hosts.  It is purely an option which may be used when:

    a - The host is not behind NAT. (ITRs need to be easily reachable
        by their upstream query server when the query server sends
        the ITR an update to some mapping.  This could be done with
        the ITFH host behind NAT, but it is not part of the current
        plan.)	

    b - The host has sufficient RAM and CPU resources to perform the
        ITR functions.  (This is a lot easier with forwarding,
        than with encapsulation, since with forwarding there are no
        PMTUD problems to solve).

    c - In the case of forwarding, the internal routers of the
        end-user network and ISP are all capable of handling the
        modified IPv4 or IPv6 headers.

    d - The extra management traffic - mapping requests, replies
        and mapping updates - is not a problem.  This makes it
        generally undesirable to make any host an ITFH host if
        it is on a slow, unreliable, costly link, as are most
        devices operating over a radio link.

2 - The current plan is for the ITFH function to be quite independent
    of the IP stack, applications etc.  In the non-Ivip core-edge
    separation schemes, it may be helpful for the ITR to know
    something about these in terms of multihoming service restoration
    and TE.  However, with Ivip, the ITR makes no decisions at all -
    the mapping contains only a single IP address.  So I can't see
    a reason why the ITFH function would benefit from any knowledge
    of what is happening in the IP stack or applications.

So Ivip, which is the proposal which most closely resembles what you
describe, does not involve a migration to a host-based solution which
resembles Strategy B.

Maybe TRRP, APT or LISP might have similar provisions for moving the
ITR function to the sending host, but I don't think they currently
involve changing the functions of *all* hosts to include the ITR
function, or to an elimination of new multihoming etc. functionality
in the network - both of which are distinguishing characteristics of
Strategy A.

 - Robin

---

From: Robin Whittle <[email-masked]>
Date: Tue, 30 Dec 2008 14:07:57 +1100

Hi Bill,

> is pretty good and it plays to our very solid experience with

OK, but your page's problem definition seems to embody assumptions
that the problem is lack of functionality in hosts.

> other approaches can be retired.

Do you support rejecting all strategies other than A and B?

If so, then perhaps I could agree that we make it clear that Strategy
B, whilst not being completely ruled out, is very much a second-best
set of approaches, which should only be considered if the best
attempts at developing and then introducing one or more Strategy A
solutions fail.

Since Strategy B approaches are much harder to develop and introduce,
due to:

  1 - Requiring wholesale adoption of IPv6 with modified host stack
      API and applications.

  2 - It provides benefits to adoptors only when the other host
      in a session (stack and relevant applications) has been
      upgraded too.

I find it impossible to imagine how a Strategy B solution could
succeed after the best one or more Strategy A solutions have been
properly developed and offered for adoption.

Because Strategy B involves what I regard as an undesirable
devolution of responsibilities, functionality and management traffic
to all hosts, I think we should reject Strategy B and persist with
Strategy A solutions solely.

If Strategy B looked easier to introduce than Strategy A, then it
could be trickier.  However, I think that Strategy A is the most
desirable kind of solution and also the easiest, by far, to develop
and have widely enough adopted.

>> I support rejection of B, C, D, E and F, individually or collectively.

Oops - I mean G too, for the reasons mentioned on your page:

as well as the fact that it fails to address the problem in the
Internet a billion or more people rely on today: IPv4.

  Regards

    - Robin

---

From: David Meyer <[email-masked]>
Date: Tue, 30 Dec 2008 07:32:55 -0800

> It's worth a discussion at least.

	Most definitely, given that NAT is the (at least near
	term) future.

	http://www.1-4-5.net/~dmm/talks/NANOG45/iteotwawki-nanog45.pdf

	Might as well get used to it.

	Dave

---

From: "William Herrin" <[email-masked]>
Date: Tue, 30 Dec 2008 10:42:44 -0500

> It's worth a discussion at least.

Hi Steven,

NAT was discussed. The discussion identified one approach which made a
credible claim to reduce the routing table load: Six/One Router. The
concept is embodied in strategy variant A4e.

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Dec 2008 09:19:32 +1300

> concept is embodied in strategy variant A4e.

I think Steve, and Dave Meyer, were referring to a widely deployed
current solution, not to a proposal. Unless you regard this as part of
strategy F, of course.

    Brian

---

From: "William Herrin" <[email-masked]>
Date: Tue, 30 Dec 2008 17:13:27 -0500

> current solution, not to a proposal. Unless you regard this as part of

I categorize generic NAT with CIDR: expended.

I would not mind a historical look at technologies which we've used to
improve routing scalability to get where we are now, but I don't feel
compelled to write one myself.

As a group, we looked at whether we could wring more gains from NAT
some months ago. We talked of tweaking NAT first one way and then
another. With the exception of with Six/One Router, none of the
participants could offer a credible hypothesis as to how any
particular take on NAT would reduce demand for routing table slots.

The solution space summary document should probably answer the
question: "what did we find when we looked at NAT?". I'll make this
addendum item #2.

Regards,
Bill Herrin

---

From: "William Herrin" <[email-masked]>
Date: Tue, 30 Dec 2008 18:14:49 -0500

Hi Brian,

Unless you correct me, I'll take this to mean that you oppose
rejecting both strategy A and B.

> But it is my opinion that B is a lost cause for IPv4.

It is and it isn't.

If you fix the layer 4/5 problem where the locator gets mixed in with
the session ID, why should the resulting protocol not be layer-3
agnostic? You just put both protocol and locator in the guid to
locator map instead of just putting a locator there. Presto! Done.

Such a strategy-B protocol should be able to run on any layer-3
protocol available, which means it should coexist happily with the
IPv4 backbone for as long a transition period as necessary. So in that
sense, it isn't a lost cause for IPv4. Quite the contrary, IPv4 is
part of the deployment bridge.

But you're correct that there's no headroom for growth in IPv4. In
that respect, strategy B is a lost cause for IPv4. But then
ultimately, so is strategy A.

> If someone can write

Feel free to take a look at the *very* early and *very* rough work at
http://bill.herrin.us/network/name/name.html, especially snrp and ltp.
I don't think it proves that IPv4 isn't a lost cause, but it does show
how a strategy-B system can be layer-3 agnostic.

> Huh? No credit for stuff that works?

Would it surprise you to learn that while "42" is the answer to life,
the universe and everything, it is in fact not the answer to the
multihoming problem?

RFC 3484 addresses a problem that a complete multihoming solution
might or might not run in to. Standing alone, RFC 3484 does not
address the multihoming problem in any way shape or form.

> So I think you can make your own list.

Indeed I can. It contains zero items.

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Jan 2009 09:20:13 +1300

Hi Bill,

> ultimately, so is strategy A.

Yes, but my point is that any strategy for IPv4 hosts that needs
changes to IPv4 host stacks is a lost cause even in the short term.
Obviously anything the needs a fresh supply of IPv4 addresses is
also a lost cause too.

> address the multihoming problem in any way shape or form.

Sorry but that is simply untrue *unless* your definition of
multihoming requires TCP, UDP or DCCP session survival across
multihoming events. Since I spent several years chairing the
debate on this in the MULTI6 WG, I don't want to rehash the
arguments yet again. But where we got to is in RFC3582,
RFC4177, RFC4218 and RFC4219.

> Indeed I can. It contains zero items.

Mine includes small items like Internet Explorer, Firefox,
Lotus Notes, and anything written in Java. Not to say there
are no glitches, of course, and that we can't make things
better as deployment experience increases. Of course, this
world (multi-prefix PA IPv6) is new and different from RFC4116
and in particular requires nothing from ISPs except PA
assignments.

Happy New Year from Auckland, where 2009 arrived 9 hours ago.

   Brian

---

From: "William Herrin" <[email-masked]>
Date: Wed, 31 Dec 2008 16:36:42 -0500

On Wed, Dec 31, 2008 at 3:20 PM, Brian E Carpenter
<[email-masked]> wrote:
> multihoming events.

Brian,

The marketplace has made it crystal clear that any acceptable
definition of multihoming requires GUID survival across multihoming
events. RFC 3484 does not attempt GUID survival.

Session is layer 5. What would multihoming without session survival
be? Layer-6 multihoming?

No points for layer-7 multihoming.

> Since I spent several years chairing the

These RFCs should surely be required reading for RRG participants.

Nevertheless, they do not individually or in aggregate describe an
operational system. They do not support a claim that "applications
updated to use IPv6 stacks already [multihome] with multiprefix PA
address assignments."

> small items like Internet Explorer, Firefox,
> Lotus Notes

Oh really? Internet Explorer will reconnect me to the server at
http://[2001:500:4:13::80]/ even after a multihoming event causes the
server's address to change to http://[2001:4860:0:2001::68]/? Oh I
see... IE will reconnect if *its* IPv6 address changes.

No points for layer-7 multihoming. Those applications perform
identically in IPv4, reconnecting with whatever network resources are
available.

Any problem can be solved at the application layer for a single
application. Architectural solutions solve the problem at a lower
layer so that it stays solved for *all* applications.

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Jan 2009 12:28:25 +1300

> No points for layer-7 multihoming.

That is a judgement call. I submit that the average
user doesn't care.

Let's agree to disagree on this.

   Brian

---

From: "William Herrin" <[email-masked]>
Date: Wed, 31 Dec 2008 20:32:40 -0500

Brian,

As you wish, but I can't resist a parting shot:

If layer-7 multihoming was the answer then why in the quarter century
it has been available has it failed to solve the problem? SMTP lit the
path. Yet here we are.

Regards,
Bill Herrin