Subject: [rrg] Next pass

From: Tony Li <[email-masked]>
Date: Thu, 22 Apr 2010 13:55:41 -0700

Hi all,

Here's the next pass at section 17.  Please comment.

Regards,
Tony

--------

17.  Recommendation

   As can be seen from the extensive list of proposals above, the group
   explored a number of possible solutions.  Unfortunately, the group
   did not reach rough consensus on a single best approach.
   Accordingly, the recommendation has been left to the co-chairs.  The
   remainder of this section describes the rationale and decision of the
   co-chairs, and does not reflect the consensus of the group.

   As a reminder, the goal of the research group was to develop a
   recommendation for an approach to a routing and addressing
   architecture for the Internet.  The primary goal of the architecture
   is to provide improved scalability for the routing subsystem.
   Specifically, this implies that we should be able to continue to grow
   the routing subsystem to meet the needs of the Internet without
   requiring drastic and continuous increases in the amount of state or
   processing requirements for routers.

17.1.  Motivation

   There is a general concern that the cost and structure of the routing
   and addressing architecture as we know it today may become
   prohibitively expensive with continued growth, with repercussions to
   the health of the Internet.  As such, there is an urgent need to
   examine and evaluate potential scalability enhancements.

   For the long term future of the Internet, it has become apparent that
   IPv6 is going to play a significant role.  It has taken more than a
   decade, but IPv6 is starting to see some non-trivial amount of
   deployment.  This is in part due to the depletion of IPv4 addresses.
   It therefore seems apparent that the new architecture must be
   applicable to IPv6.  It may or may not be applicable to IPv4, but not
   addressing the IPv6 portion of the network would simply lead to
   recreating the routing scalability problem in the IPv6 domain,
   because the two share a common routing architecture.

   Whatever change we make, we should expect that this is a very long-
   lived change.  The routing architecture of the entire Internet is a
   loosely coordinated, complex, expensive subsystem, and permanent,
   pervasive changes to it will require difficult choices during
   deployment and integration.  These cannot be undertaken lightly.

   By extension, if we are going to the trouble, pain, and expense of
   making major architectural changes, it follows that we want to make
   the best changes possible.  We should regard any such changes as
   permanent and we should therefore aim for long term solutions that
   position the network in the best possible position for ongoing
   growth.  These changes should be cleanly integrated, first-class
   citizens within the architecture.  That is to say that any new
   elements that are integrated into the architecture should be
   fundamental primitives, on par with the other existing legacy
   primitives in the architecture, that interact naturally and logically
   when in combination with other elements of the architecture.

   Over the history of the Internet, we have been very good about
   creating temporary, ad-hoc changes, both to the routing architecture
   and other aspects of the network layer.  However, many of these band-
   aid solutions have come with a significant overhead in terms of long-
   term maintenance and architectural complexity.  This is to be avoided
   and short-term improvements should eventually be replaced by long-
   term, permanent solutions.

   In the particular instance of the routing and addressing architecture
   today, we feel that the situation requires that we pursue both short-
   term improvements and long-term solutions.  These are not
   incompatible specifically because we truly intend short-term
   improvements to be completely localized and temporary.  As the long-
   term solution is rolled out and gains traction, the short-term
   improvements should be of less benefit and can subsequently be
   withdrawn.

17.2.  Recommendation to the IETF

   The group explored a number of proposed solutions but did not reach
   consensus on a single best approach.  Therefore, in fulfillment of
   the routing research group's charter, the co-chairs recommend that
   the IETF pursue work in the following areas:

      Aggregation in Increasing Scopes [I-D.zhang-evolution]

      Identifier/Locator Network Protocol (ILNP) [ILNP Site]

      Renumbering [I-D.carpenter-renum-needs-work]

17.3.  Rationale

   We selected Aggregation in Increasing Scopes because it is a short-
   term improvement.  It can be applied on a per-domain basis, under
   local administration and has immediate effect.  While there is some
   complexity involved, we feel that this is option is constructive for
   service providers who find the additional complexity to be less
   painful than upgrading hardware.

   We recommended ILNP because we find it to be a clean solution for the
   architecture.  It separates location from identity in a clear,
   straightforward way that is consistent with the remainder of the
   Internet architecture and makes both first-class citizens.  Unlike
   the many map-and-encap proposals, there are no complications due to
   tunneling, indirection, or semantics that shift over the lifetime of
   a packets delivery.

   We recommend further work on automating renumbering because even with
   ILNP, the ability of a domain to change its locators at minimal cost
   is fundamentally necessary.  No routing architecture will be able to
   scale without some form of abstraction, and domains that change their
   point of attachment must fundamentally be prepared to change their
   locators in line with this abstraction.  We recognize that
   [I-D.carpenter-renum-needs-work] is not a solution so much as a
   problem statement, and we are simply recommending that the IETF
   create effective and convenient mechanisms for site renumbering.

---

From: Vince Fuller <[email-masked]>
Date: Thu, 22 Apr 2010 14:43:41 -0700

> Here's the next pass at section 17.  Please comment.

Hi Tony-

Thanks for your continuing efforts to improve this document.

As I stated in my previous message, I object to the "recommendation"
section being included in a document that is billed as a product of a
group calling itself "the RRG", particularly if I am considered a
member of that group by virtue of my inclusion on this mailing list,
my attendance at RRG meetings, and/or my participation in RRG
discussions during the past three years.

I would happy seeing the document, minus the "recommendation" section,
published as a product of "the RRG". The "recommendation" section
should be separately submitted as an individual submission to the IETF
by you and Lixia as it reflects your opinions and not those of the larger
membership of "the RRG".

Thank you for your consideration.

	--Vince

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Apr 2010 17:58:20 -0400

The new text makes it quite clear that the recommendation is just the 
recommendation of the chairs.  That's good enough for me.

(While one could suggest I am less picky on this, since I actually agree 
with the recommendation, I would note that I have been among those 
pushing strongly that the document not claim to be a recommendation from 
the RRG.  The RRG clearly has no consensus of any kind on what we should 
do.)

Yours,
Joel

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Apr 2010 15:14:58 -0700

+1

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Thursday, April 22, 2010 2:58 PM
> To: Vince Fuller
> Cc: Tony Li; IRTF Routing RG
> Subject: Re: [rrg] Next pass
>

---

From: Robin Whittle <[email-masked]>
Date: Fri, 23 Apr 2010 14:22:46 +1000

Hi Tony,

Here are some comments:

>    Accordingly, the recommendation has been left to the co-chairs. 

I suggest instead:

  In accordance with RFC 2014, the co-chairs have written the
  following recommendation.

>    The

OK.

>    processing requirements for routers.

This does expand on your use of the term "scalability", as I
suggested in (msg06474).  However, in that message I raised some
questions about your goals which remain unanswered in your current text.

> ... grow the routing subsystem

This is ambiguous.  It could mean adding more routers, or making the
routing system do more work, or support more end-user networks with
portability, multihoming, TE, mobility etc.

ILNP and other CEE architectures do not, in general, "grow the
routing subsystem" as it is currently understood.  In fact, they do
this, by making every host part of the routing subsystem - and by
making that subsystem do more work than the current purely
network-based (not host-based) "routing subsystem".

> to meet the needs of the Internet without requiring drastic and
> continuous increases in the amount of state or processing
> requirements for routers.

OK - but what do you mean by "routers"?  If you mean existing and DFZ
routers and routers of the future which perform the same roles, then
this requirement is met perfectly well by the Core-Edge Separation
architectures such as LISP, Ivip and IRON-RANGER.  (It may also be
met by CEE architectures such as GLI-Split, ILNP, Name Based Sockets
and RANGI - though some of these do involve additional router
functions, which may involve DFZ routers.)

The CES architectures add new network elements, some of them which
are known as "routers" (ITRs, ETRs or similar roles in IRON-RANGER) -
and/or new functionality in existing routers.  A CES architecture may
involve adding functionality to a DFZ router, but only as a matter of
choice for the network which runs that router.  In Ivip, there is no
need to use existing DFZ routers for ITR functions - so all DFZ
routers can remain completely untouched.  With Ivip, there may be no
need to alter any routers - all the work could be done by new
devices, including by all those devices being COTS servers.

CES does involve new work being done in the network - by devices
which are specifically designed to do this efficiently.  In LISP,
Ivip and IRON-RANGER (as currently discussed), there is no use of BGP
for conveying information between these new devices or new router
functions.  Each CES architecture has its own way of providing much
more scalable communications between the new devices or
functionalities which need to communicate - with the intention that
they scale well.

Both CEE and CES architectures pretty much leave the DFZ routing
system alone.

CES architectures do not burden hosts at all.  They add new things to
the network which are designed to cope well with the intended massive
growth in adoption of portability, multihoming, TE and mobility.  CES
architectures work fine for IPv4 and IPv6.

CEE architectures either do not add anything to the routing system or
add what is argued to be less to it than a CES architecture.  CEE
architectures burden hosts with all or most of the new work - and
they only work by modifying IPv6.  They can't work for IPv4 (msg06489
and msg06530).

If your goal is to make the Internet endlessly scalable without any
architectural additions to the network, then you might be able to do
this with CEE - at the great cost of moving every host to IPv6 and
then to using new stack and perhaps application software in order to
fully implement the new Locator / Identifier Separation naming model.

Your recommendation of ILNP doesn't acknowledge anything about the
transition and adoption difficulties, or contain any justification
for why hosts should do most or all the work (CEE), rather than the
network (CES).

>    examine and evaluate potential scalability enhancements.

I think you need to mention your goals, such as increased access to
portability, multihoming, inbound TE, mobility etc. on a scalable
basis.   Or are you only aiming to provide the currently overly
constrained access to these benefits, while limiting the costs this
imposes on the existing routing system?

>    deployment.  

As I mentioned in (msg06474), you do not provide any evidence for
this assertion - and I believe many people will not be able to think
of any such deployment.

>    This is in part due to the depletion of IPv4 addresses.

So you feel no need to solve the IPv4 scaling problem - or to explain
to readers why you consider it to be of such low importance.

>    deployment and integration.  These cannot be undertaken lightly.

OK.

>    when in combination with other elements of the architecture.

Sure - but you haven't explained to readers why hosts should do the
extra work, why CES approaches are more trouble or less beneficial
than CEE approaches, or why you chose ILNP over the other CEE
architectures: GLI-Split, Name-Based Sockets and RANGI.

>    term improvements and long-term solutions.  

The fact that ILNP (or other CEE architectures) have a much more
onerous set of barriers to adoption than CES architectures doesn't
mean they are a better solution in the long-term.

>    These are not

Yes, but a CES architecture can provide immediate benefits to all
adoptors, and routing scaling benefits in direct proportion to the
level of adoption.  So you don't need any short-term things to go
along with CES.  ILNP and other CEE architectures at the very best
might take decades to be widely enough deployed that most
communications will use the new system.

>    the routing research group's charter, 

Its not the charter - it is according to the IRTF rules which enable
the chair a great deal more choice in how the work will be done than
in an IETF WG, which many readers will not understand.

>    the co-chairs recommend that

For my critique of these rationales, please see:

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

and for what I think would be a good recommendation:

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

   - Robin

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Apr 2010 11:33:53 +0200

Tony,

I think this looks pretty good.  Vince, Heiner, and Hongbin have 
suggested that the document be split.  That's an interesting idea as far 
as it goes, but one could argue that the best approach would be to not 
split into two documents, but instead into perhaps one or two per 
approach, thus providing for a means of evolving the understanding of 
each approach independently.

On the other hand, this has somewhat to do with where the RRG goes from 
here.  If people just want to be finished, then I really don't care how 
many documents there are, personally, since none are going to evolve, 
and as Joel points out, the views of the chairs are clearly indicated as 
their views.

And so the question I have is this, and I asked it in the Anaheim 
meeting (this isn't meant as a question only for Tony):

What do people want to do next with this group?

Eliot

---

From: <[email-masked]>
Date: Fri, 23 Apr 2010 13:32:57 +0200

Dear Eliot, all,

I'm not sure that splitting the reco document into two files makes sense since the purpose was to come up with a recommendation..which is the case despite that this recommendation is not a RRG consensus but a proposal from the chairs (their proposed text is clear on this). I personally like to have more text to argue how the proposed solutions solve the problem to be solved and what are pieces of the puzzle which need more work. I sent an email to Tony with my comments on the first version of the reco text.

As for your question, I think that the recommendation document in its current state does not provide answers to several (pending) issues such as the following ones:

- The proposed solutions I read, imho, seem to not solve the scalability issue since the full table should be maintained in some nodes and this table is not reduced (in transit border routers for current BGP deployment, in TIB tables in TIDR proposal, APR for AIS, LISP/Ivip maintain separate database to store the mapping but still there is a impact on the global routing table in early deployment stages since IDs need to be routable at least to be reached from non LISP/Ivy sites, etc.). These nodes need to be upgraded regularly not only to meet bw increase demand but the increase of the routing+forwarding states.

- Can the scalability issue be solved without revisiting interconnection (business) models?

- Can the scalability issue be solved without close collaboration with registry bodies (some of the aggregation issues are due to disjoint blocks, this will be even aggravated in the next period due to IPv4 address depletion)?

- Can the scalability issue be solved without any firm policy on the use provider independent prefixes/addresses?

- To what extent a loc/id solution can mitigate/solve the routing scalability issue?

And other open questions related to having a consensus on the problem statement:
- Why draft-narten is not acceptable as a starting point to sketch the problems to be solved? A frozen version of the problem statement is must for the group in order to help selecting solution(s).
- Unlike the multi-homing case which is obvious, need to motivate why mobility is an issue for routing systems.
- How AIS/INLP solve these problems. At least for me, it is not clear how AIS/ILNP solves the routing scalability issue. ILNP concept and DNS documents are silent on IPv4 scenario except the definition of the L32 record but without any further explanation.

As for the next steps:
- Why not considering launching several experimental effort to assess the validity of proposed approached: in particular AIS and ILNP Suite since this is the recommended solutions by the chairs.

Does this make sense?
Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de Eliot Lear
Envoyé : vendredi 23 avril 2010 11:34
À : Tony Li
Cc : IRTF Routing RG
Objet : Re: [rrg] Next pass

Tony,

I think this looks pretty good.  Vince, Heiner, and Hongbin have suggested that the document be split.  That's an interesting idea as far as it goes, but one could argue that the best approach would be to not split into two documents, but instead into perhaps one or two per approach, thus providing for a means of evolving the understanding of each approach independently.

On the other hand, this has somewhat to do with where the RRG goes from here.  If people just want to be finished, then I really don't care how many documents there are, personally, since none are going to evolve, and as Joel points out, the views of the chairs are clearly indicated as their views.

And so the question I have is this, and I asked it in the Anaheim meeting (this isn't meant as a question only for Tony):

Eliot

Hi all,

Regards,
Tony

--------

17.  Recommendation

17.1.  Motivation

17.3.  Rationale

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

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Scott Brim <[email-masked]>
Date: Fri, 23 Apr 2010 15:50:10 -0400

> Here's the next pass at section 17.  Please comment.

Hi Tony.  First, a lot of this is general comments on goal, motivation
and problem statement.  This should all be put up at the front, as
context.  I would have the order in front be Introduction, then Problem
Statement, then "Proposals" with "Abbreviations" being the first
subsection under that.

For each of your justification paragraphs, I think you should have a
summary bullet, e.g. "must be applicable to IPv6", "must be good for the
long term".

>    improvements should be of less benefit and can subsequently be

Ha ha ha.  "Incremental" isn't just about new things coming in, it's
about old things going out as well.  The text should note that the
short-term tweaks will be with us for a long time, but that they are
necessary steps.  When you get down to specifics later, explain why
having the short-term tweaks hang around isn't a terrible problem.

>       Renumbering [I-D.carpenter-renum-needs-work]

Brian's right, renum-needs-work is not a solution, it's a discussion.  I
would mention it in the "Rationale" as something that helps make ILNP
more feasible in the long term, but not up here where you're talking
about "solutions".

>    painful than upgrading hardware.

Here's where you explain why it's okay if people do this for 20 years.

>    tunneling, indirection, or semantics that shift over the lifetime of

"Clean" etc. doesn't say much -- you should be less subjective.  In what
ways is it cleaner?  Why specifically are tunneling and indirection
considered problems?

>    We recommend further work on automating renumbering because even with

Here's where you mention renum-needs-work as a focal point for this
important effort, but skip the last sentence -- it's unnecessary since
you are no longer presenting it as a solution.

>    create effective and convenient mechanisms for site renumbering.

Finally, I recommend a new section: A bulleted list of issues the IETF
needs to consider in order to turn this recommendation into real
engineering for real networks.  I think that would help the IETF figure
out what to do with this recommendation.  I'll try to contribute to that
next but as you have seen I don't have a lot of time these days.

Oh, and I appreciate all the work you're doing.

Scott

---

From: Scott Brim <[email-masked]>
Date: Fri, 23 Apr 2010 15:52:25 -0400

> What do people want to do next with this group?

Declare victory, put it to sleep, and let Aaron decide what to do with it.

---

From: Tony Li <[email-masked]>
Date: Fri, 23 Apr 2010 19:02:40 -0700

Hi Eliot,

> I think this looks pretty good.  Vince, Heiner, and Hongbin have suggested
> that the document be split.  That's an interesting idea as far as it goes, but
> one could argue that the best approach would be to not split into two
> documents, but instead into perhaps one or two per approach, thus providing
> for a means of evolving the understanding of each approach independently.
> 
Apart from the rest of this conversation, I¹ll just point out that all
proposals have already been explicitly invited to submit their proposals as
IRTF RRG RFCs.  So far, I¹ve got two proposals that have expressed interest.
>  What do people want to do next with this group?
I agree with the follow-on mail suggesting that this is up to Aaron.

Regards,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 24 Apr 2010 14:44:36 +1000

Short version:   Med's concern (as best I understand it) about DFZ
                 routers needing to carry routes for all end-user
                 prefixes in Ivip or LISP seems to be based on a
                 misunderstanding.

                 Also, why support for Mobility should be a goal of
                 any architectural change regarding scalability.

Hi Med,

In "Re: [rrg] Next pass" (msg06535) you wrote, in part:

> - The proposed solutions I read, imho, seem to not solve the scalability
> issue since the full table should be maintained in some nodes and this
> table is not reduced (in transit border routers for current BGP
> deployment, in TIB tables in TIDR proposal, APR for AIS, LISP/Ivip
> maintain separate database to store the mapping but still there is a
> impact on the global routing table in early deployment stages since IDs
> need to be routable at least to be reached from non LISP/Ivy sites,
> etc.). 

I think you are assuming that for LISP and Ivip that each prefix (or
for Ivip, a "micronet", which need not be a prefix) of "edge" space
used by an End User Network (EUN) is separately advertised in the
DFZ.  This is not the way Ivip will be used, and I doubt if LISP
would be used in this manner either.

The main way "edge" space will be provided in Ivip is for a company
to devote a DFZ advertised prefix to being used to serve the needs of
many (up to tens or hundreds of thousands) of separate EUNs.  This
prefix is called a "Mapped Address Block" (MAB) and the company which
runs it is called a MAB Operating Company (MABOC).  The MABOC leases
the space within the MAB to all these EUNs.  Each EUN splits up its
space into as many separately mapped micronets as it likes.

So you could have a MAB of 44.44.0.0/16 with 2^16 IPv4 addresses.
This could be split into various User Address Blocks (UABs), each for
a different EUN.  There might be 10,000 EUNs, some with just one or a
few IPv4 addresses and some with more.  A single micronet in Ivip is
an integer number of IPv4 addresses or IPv6 /64s, with any starting
and ending point provided both are within the one MAB.  So a micronet
could be:

   44.44.55.67   (Single IP address.)

   44.44.55.68 to 44.44.55.73 inclusive   (6 IP addresses.)

The MABOC runs one or typically multiple DITRs - Default ITRs in the
DFZ.  These advertise the MAB.  So all DFZ routers need the MAB in
their RIB and FIB.  This is entirely scalable, since the one MAB is
providing space for ten thousand EUNs, and some of those EUNs will be
further splitting their space into multiple micronets.  A single DFZ
advertised prefix for all these separately mapped micronets of "edge"
space is highly scalable.

LISP could do the same thing - except LISP always works in prefixes.
Each separately mapped division of address space is an "EID prefix".

As far as I know, there is little documentation of LISP's technical
and administrative arrangements regarding address space usage.  LISP
has no formal concept equivalent to Ivip's MAB, but Dino has used the
term "coarse prefix" to refer to much the same thing - which would be
advertised by some or perhaps all PTRs (Proxy Tunnel Routers - much
the same as Ivip's DITRs).

> - To what extent a loc/id solution can mitigate/solve the routing

Neither LISP or Ivip are Locator / Identifier Separation
architectures.  RANGI, GLI-Split, ILNP and Name Based Sockets are.

For an account of how LISP or Ivip could solve the scalability
problem for both IPv4 and IPv6, and for why Ivip could do it better,
please see:

Since then, IRON-RANGER has developed somewhat and I think it may be
more promising than LISP.  This also includes a taxonomy of the
proposals and links to other messages where this is argued in greater
detail.

> - Why draft-narten is not acceptable as a starting point to sketch the
> problems to be solved? A frozen version of the problem statement is must
> for the group in order to help selecting solution(s).

The RRG Goals I-D was never properly developed.  My message 06219 has
my account of the goals - but there seems to be no consensus on what
the goals should be.

> - Unlike the multi-homing case which is obvious, need to motivate why
> mobility is an issue for routing systems.

Because global mobility is similar to multihoming and portability in
some ways.

For an account of a new approach to global mobility, for IPv4 and
IPv6, without modifications to correspondent hosts and with generally
optimal paths, please see the TTR Mobility architecture:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

This could work with both Ivip and LISP.

If we are going to do a major upgrade to the architecture of the
Internet, I and some other people think that it should support
Mobility - rather than doing an upgrade just for portability and
multihoming and then having to do something later for Mobility.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Sat, 24 Apr 2010 18:09:22 -0700

Hi Scott,

> First, a lot of this is general comments on goal, motivation

I have no problems with that, however, moving up to the front would move it
out from underneath the disclaimers at the head of the section.  I think
that a lot of folks would then have an issue with it.

> summary bullet, e.g. "must be applicable to IPv6", "must be good for the

Would section headings do?
 
> having the short-term tweaks hang around isn't a terrible problem.

You can laugh all you like, but I do suspect that the operational pain of
AIS is going to motivate operators to retract it as quickly as possible.
Added text as you suggest.

> more feasible in the long term, but not up here where you're talking

Already done.

> ways is it cleaner?  Why specifically are tunneling and indirection

Heh.  This dovetails nicely into other conversations that I've been having
recently.  Unfortunately, architectural complexity seems to be very
subjective.  Suggestions for text?

> you are no longer presenting it as a solution.

? Brian asked me to add it, now you want me to take it out.

> next but as you have seen I don't have a lot of time these days.

I welcome the text.  We should be careful to suggest work that should be
done and not how it should be done.

> Oh, and I appreciate all the work you're doing.

Thanks.  Glad someone does.  ;-)

Tony