Subject: [rrg] Proposal for recommendation language

From: Tony Li <[email-masked]>
Date: Tue, 13 Apr 2010 15:35:32 -0700

Hi all,

I hope everyone's had a chance to get caught up with their day jobs after
IETF.  ;-)

I would like to start work on the language to go in section 17
(Recommendation) of our document.  As a strawman, I would like to propose
the language below.  This would appear (modulo editorial changes) as the
complete text of that section.

Comments?

Regards,
Tony

P.s. The draft is also open for folks that would like to make editorial
changes to their contributions.

----------------
As can be seen from the extensive list above, the group explored a number of
possible solutions. Unfortunately, the group did not reach rough consensus
on a single best approach.  Accordingly, the decision of the co-chairs is to
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]

---

From: Robin Whittle <[email-masked]>
Date: Wed, 14 Apr 2010 15:08:09 +1000

Hi Tony,

You have taken no interest in Ivip since I first devised it in June
2007.  The slides you and Lixia presented at the meeting
misrepresented Ivip, and misclassified two Core-Edge Separation
(Locator / Identifier Separation) architectures as being CEE
(GLI-Split) and just a "mapping proposal" (Name Based Sockets).

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

So I don't hold much hope that my comments will alter what you decide

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

This is simple and brief - but these are not virtues, since this is a
complex field and you are recommending the path by which the world's
largest and most important IT/communication system should be
fundamentally altered.

I expect most people reading your Recommendation will recognise it
comes from you and Lixia alone.  Since you don't provide any analysis
of the proposals you rejected, I think most people will give it very
little weight.  Perhaps they will also notice that the LISP team
didn't bother to write a rebuttal or contribute substantially to any
critiques of other architectures.

Those who read the archives will note the occasional protests at you
banning or discouraging debate on "proposals" (AKA "candidate
architectures") for most of the last 3 years - while exhorting us to
discuss "architecture".  Yet you gave little or no examples of how
this should be done.

They may also notice that in recent months the only proposal you
commented on to any significant degree was ILNP.

The RRG Report contains introductory information for a bunch of
proposals, and people can read the critiques, rebuttals and responses
- and read further in the various websites and IDs.  This is a
valuable contribution to the field.

Your Recommendation adds nothing to the field.

I think it is of minor interest to anyone what you and Lixia think is
the best way forward - since you provide no arguments for you
position whatsoever.  If you fleshed out your Recommendation with
detailed analysis of the architectures you prefer, comparing them in
detail with those you reject, then that material would be a
contribution to the field, depending on how accurately you understood
the architectures and how acute your analysis was.

If anyone wants to see the form of a well researched and carefully
argued Recommendation, with a statement of the goals and non-goals,
and analysis of the key points of the various architectures, they can
take a look at my message from 8 March:

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

Ideally the RRG Recommendation would be along these lines - as a
consensus document.  Failing that, ideally, the co-chair's
Recommendation should be at least this detailed.  This is especially
so since, due to your inaction, the RRG didn't achieve one of its
earliest goals:

  http://www.irtf.org/charter?gtype=rg&group=rrg

      as a starting point, the RRG will produce a document
      enumerating the design goals for a new routing architecture.

Your Recommendation has no real meaning - no-one can be sure what it
is you are hoping to achieve with these architectures.  The Design
Goals ID (01) resulted from very early, limited, discussions to early
July 2007:

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

You never responded to my suggestions a few days later on improving it:

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

Note the message number - 203.  We are now up to 6440.

The Charter also states that the RRG will prepare a taxonomy.  I
provide a taxonomy in msg06373 and in other messages cited from
there.  You have never commented on this, other than to assert,
without arguments, that the CES/CEE architectural distinction is
invalid or not useful.  Bill Herrin and others also worked on a
taxonomy in late 2008:

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

In 2010, the closest thing there is to to an RRG taxonomy is your
slides from the recent meeting, but as I noted in msg06373, this is
plain wrong in some important respects, just at a first glance.

With little help from you, and frequently in spite of your
instructions - and with more help from Lixia (who contributed to
proposals, wrote critiques and was generally more supportive of
debate) - the RRG has developed a number of architectural approaches.

Still, as noted by k claffy and Eliot Lear:

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

there is a regrettable lack of proposal submitters (myself excepted)
providing critiques of other proposals.

With your help, these proposals are now presented in a summarised
form, with some brief but constructive discussion, in the RRG Report.
 In the future I intend to list or compile all the critiques and
responses which didn't make it into the RRG Report.

I think anyone interested in Core-Edge Separation architectures,
including LISP and Ivip, should take a look at the recent discussions
between Fred and me regarding IRON-RANGER.  I consider it to be a
better architecture than LISP-ALT or any other form of LISP.

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

     The later stages of this look highly complex and likely to be
     fragile.  In the context of the need to provide scalable
     portability, multihoming and inbound TE for ~10^7 non-mobile
     networks, and mobility for up to 10^10 devices, AIS provides
     only marginal benefits to adopting networks .  It does nothing
     to provide a new form of address space which can be used to
     scalably provide portability, multihoming, inbound  TE or
     mobility.

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

     ILNP is one of the four CEE architectures - the others being
     RANGI, GLI-Split and Name Based Sockets.  These can only work
     for IPv6.  They require changes to all host stacks - including
     (msg06423) for ILNP, to the transport protocols.  There remain
     various questions about the operation of all these
     architectures - e.g. (msg06432).

     Some CEE architectures require application changes.  Those which
     don't (such as ILNP) face challenges ensuring the assumptions
     about the IP addresses at the app level are maintained in actual
     communications.  For instance, with the current two-level naming
     model used in IPv4 and IPv6, in which the roles of "Identifier"
     and "Locator" are both performed by the IP address, the network
     provides apps (and the TCP and UDP layers) with an assurance
     that a packet sent to IP address XXX will either be delivered to
     the host with that identity, or will be dropped - it will never
     be delivered to any other host than XXX.  This model offends
     architectural purists, but it is more efficient - which can best
     be appreciated when it is fully realised what ILNP, GLI-Split
     etc. require all hosts to do in order to adopt Locator /
     Identifier Separation.

     None of them are suitable for mobility.

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

     Renumbering can never be an acceptable approach for any but
     the smallest networks choosing a new ISP.  This is because
     the IP addresses used by the network frequently appear in many
     places outside its control and outside its knowledge.  Even if
     the network administrators knew all occurrences, there is no
     acceptable, practical, means by which they can have those IP
     addresses changed at the instant they switch to the new ISP.
     To do so would involve inconvenience and costs to other
     organisations, including sometimes the customers of the network.

A more detailed analysis of all the proposals is here:

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

When people look at the discussion of Ivip, I hope they will realise
that in early March I replaced its previous mapping system with a new
approach - Distributed Real Time Mapping.  This overcomes many of the
critiques made of the earlier system, including some in Lixia's
critique which is in the RRG Report, which was written before I
developed DRTM.  DRTM is completely decentralised and involves early
provision of scalable routing benefits without any significant
investment or involvement of ISPs.  No single device is required to
handle the full mapping database.

I think the new ivip-arch ID contains the only statement of goals and
non-goals of any of the proposed architectures.  Contrary to your
misstatement in the meeting slides, Ivip does not require upgrades to
any routers.

I hope people will read the Ivip-arch ID, the new, diagram-based
introduction to DRTM, the DRTM draft and then the material on TTR
Mobility:

   http://tools.ietf.org/html/draft-whittle-ivip-arch
   http://www.firstpr.com.au/ip/ivip/drtm/
   http://tools.ietf.org/html/draft-whittle-ivip-drtm
   http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

As far as I know, you have not read any of this.  As far as I know,
you have not taken much interest in any architectures other than ILNP
and its predecessor GSE.  You have never articulated why you believe
Core-Edge Elimination (Locator / Identity Separation) is superior to
Core Edge Separation, despite me arguing against CEE due to the
burden of extra packets, processing and delays it places on all hosts.

You tersely stated, and then never seriously debated, your complete
disregard for the IPv4 Internet.

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

     I want nothing.  IPv4 is done.  Over.  Cooked. Fully toast.
     It will either enter a black market where we deaggregate and
     no proposal will help, or we shift to v6 and v4 is irrelevant.
     In either case, we're not in time to do anything significant
     for v4.  And we still need a v6 solution, that's clearly higher
     priority.

There's nothing about such disregard for the IPv4 scaling problem in
the RAWS material, or in the RRG Charter.  Many RRG folks have
indicated they consider the IPv4 Internet important and that its
scaling problem needs to be tackled.

Lixia took an interest in Ivip and went to the trouble of writing at
least one critique.  AFAIK, you didn't contribute to any critiques.

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

---

From: <[email-masked]>
Date: Thu, 15 Apr 2010 15:07:01 +0200

Dear Tony, all,

More elaboration and justification for selecting the proposed solutions would be welcome. At least including some text to motivate why one single solution is not convenient, what part(s) of the problem is covered by each of the proposed three solutions, why other candidate solutions do not fulfil the initial design requirements, etc. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tony Li
Envoyé : mercredi 14 avril 2010 00:36
À : IRTF Routing RG
Objet : [rrg] Proposal for recommendation language

Hi all,

Comments?

Regards,
Tony

----------------

  

_______________________________________________
rrg mailing list
[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: "George, Wes E [NTK]" <[email-masked]>
Date: Thu, 15 Apr 2010 09:47:17 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, April 15, 2010 9:07 AM
To: Tony Li; IRTF Routing RG
Subject: Re: [rrg] Proposal for recommendation language

Dear Tony, all,

Cheers,
Med

[[WEG]] Agree. If you ignore the whining about IVIP not being chosen/refuted to his satisfaction (and his rehashing of his issues with you as a chair) from Robin's message, he has a point. Your recommendation does not currently have sufficient information to stand on its own as anything other than a pseudo-random choice on the chairs' part driven by the absence of a consensus from the group. While I have a lot of respect for you and your opinion, your credibility as chairs and IxTF participants is not strong enough to ensure that the recommendation is taken seriously by the community on face value alone. I assume that some thought went into the recommendation, so as they told me in math class - show your work. Take the reader through the thought process that led to this recommendation for you.

The recommendation certainly doesn't have to re-hash each discussion in the previous section, but it does need to hit a couple of the high points. I'd like to see something that expounds on the contributed critiques and defenses of ILNP when compared to the other proposals which are not being recommended - in other words, "the recommended proposal addresses the following problems present in X, Y, Z proposals (or categories of proposals) in the following ways...."
It may also be helpful to at least identify why the outlined problems are fundamental enough to sink the other proposals.
Also, you need a section - "the following issues are still known to exist with the recommendations..." which leads to an explanation of why multiple proposals are needed, as well as outlining the problem-space that IETF needs to solve to actually implement these ideas.

As to why multiple proposals are required to solve the problem, you have some feedback in the form of the comments from myself and several other operators in Anaheim- We see AIS as a short-term solution to buy us time to build a better one, which in this case is ILNP. Consensus not being an option, I'd think that Operator feedback might be a good way to lend credibility.
Lastly, you also need to draw a better logical link to why renumbering is specifically mentioned here - if the problem is either unique to ILNP's implementation, or fundamental to make any of these proposals work better, say that. Otherwise, I'm not sure it's clear why that's referenced. We know renumbering needs work, we have a good draft telling us why, but unless you make it clearer why it's something that has to be fixed in the context of RRG- what not fixing it would exacerbate in the RRG recommended solution, it shows as an afterthought.

Thanks,
Wes

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tony Li
Envoyé : mercredi 14 avril 2010 00:36
À : IRTF Routing RG
Objet : [rrg] Proposal for recommendation language

Hi all,

Comments?

Regards,
Tony

----------------

This e-mail may contain Sprint Nextel Company 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: Tony Li <[email-masked]>
Date: Thu, 15 Apr 2010 08:30:07 -0700

Thanks guys, duly noted.  I'll take a pass at composing more text.

Tony

On 4/15/10 7:47 AM, "George, Wes E [NTK]" <[email-masked]>
wrote:

> More elaboration and justification for selecting the proposed solutions would
> be welcome. At least including some text to motivate why one single solution
> is not convenient, what part(s) of the problem is covered by each of the
> proposed three solutions, why other candidate solutions do not fulfil the
> initial design requirements, etc.
> 
> Cheers,
> Med
> 
> [[WEG]] Agree. If you ignore the whining about IVIP not being chosen/refuted
> to his satisfaction (and his rehashing of his issues with you as a chair) from
> Robin's message, he has a point. Your recommendation does not currently have
> sufficient information to stand on its own as anything other than a
> pseudo-random choice on the chairs' part driven by the absence of a consensus
> from the group. While I have a lot of respect for you and your opinion, your
> credibility as chairs and IxTF participants is not strong enough to ensure
> that the recommendation is taken seriously by the community on face value
> alone. I assume that some thought went into the recommendation, so as they
> told me in math class - show your work. Take the reader through the thought
> process that led to this recommendation for you.
> 
> The recommendation certainly doesn't have to re-hash each discussion in the
> previous section, but it does need to hit a couple of the high points. I'd
> like to see something that expounds on the contributed critiques and defenses
> of ILNP when compared to the other proposals which are not being recommended -
> in other words, "the recommended proposal addresses the following problems
> present in X, Y, Z proposals (or categories of proposals) in the following
> ways...."
> It may also be helpful to at least identify why the outlined problems are
> fundamental enough to sink the other proposals.
> Also, you need a section - "the following issues are still known to exist with
> the recommendations..." which leads to an explanation of why multiple
> proposals are needed, as well as outlining the problem-space that IETF needs
> to solve to actually implement these ideas.
> 
> As to why multiple proposals are required to solve the problem, you have some
> feedback in the form of the comments from myself and several other operators
> in Anaheim- We see AIS as a short-term solution to buy us time to build a
> better one, which in this case is ILNP. Consensus not being an option, I'd
> think that Operator feedback might be a good way to lend credibility.
> Lastly, you also need to draw a better logical link to why renumbering is
> specifically mentioned here - if the problem is either unique to ILNP's
> implementation, or fundamental to make any of these proposals work better, say
> that. Otherwise, I'm not sure it's clear why that's referenced. We know
> renumbering needs work, we have a good draft telling us why, but unless you
> make it clearer why it's something that has to be fixed in the context of RRG-
> what not fixing it would exacerbate in the RRG recommended solution, it shows
> as an afterthought.
> 
> Thanks,
> Wes
> 
> 
> This e-mail may contain Sprint Nextel Company 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: "Templin, Fred L" <[email-masked]>
Date: Thu, 15 Apr 2010 10:00:43 -0700

Hi,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Tuesday, April 13, 2010 3:36 PM
> To: IRTF Routing RG
> Subject: [rrg] Proposal for recommendation language
> 
> 
> Hi all,
> 

Forgive me for stating the obvious (which I know no one
else on this list ever does) but it seems to me that an
unspoken aspect of all this is the tension between
Provider-Aggregated (PA) and Provider Independent (PI)
addressing.

Strict PA seems to me to be fostering a strong customer
dependence on ISPs and an inability to switch to a
different ISP easily or to multihome a single IP prefix
with multiple ISPs. (Yes, I know that multi-addressing
is possible in IPv6.) Strict PI on the other hand seems 
like a "perfect world" scenario, but it also seems to be
the driver that has gotten us into this whole mess
surrounding routing scaling issues in the first place.

But, how can we give the customers the perceived
advantages of PI without locking them into a PA "matrix"?
How can we make it so that the ISPs serve the customers
instead of the other way around? The IRON-RANGER solution
to this is simple; have the ISPs give the customers PA
addresses, but then let them use the PA addresses as a
springboard into PI. Then, the customer border routers
get exposed to PA addresses, but the customer internal
networks get to use PI and get to multihome whether or
not multi-addressing is also used. So why not have a
combined PA/PI scenario instead of strictly one vs the
other? Wouldn't that tend to have some bearing on the
RRG recommendation?

These ideas are not in any way mine originally, as
anyone who has followed the exchange between Robin
and me can see. Again, apologies if I am stating the
obvious as I know no one else on this list ever does.

Fred
[email-masked]

---

From: [email-masked]
Date: Thu, 15 Apr 2010 16:59:32 -0400

-----Ursprüngliche Mitteilung----- 
Von: George, Wes E [NTK] <[email-masked]>
An: Tony Li <[email-masked]>; IRTF Routing RG <[email-masked]>
Verschickt: Do., 15. Apr. 2010, 16:47
Thema: Re: [rrg] Proposal for recommendation language

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Thursday, April 15, 2010 9:07 AM
To: Tony Li; IRTF Routing RG
Subject: Re: [rrg] Proposal for recommendation language

Dear Tony, all,

More elaboration and justification for selecting the proposed solutions would be 
welcome. At least including some text to motivate why one single solution is not 
convenient, what part(s) of the problem is covered by each of the proposed three 
solutions, why other candidate solutions do not fulfil the initial design 
requirements, etc.

Cheers,
Med

[[WEG]] Agree. If you ignore the whining about IVIP not being chosen/refuted to 
his satisfaction (and his rehashing of his issues with you as a chair) from 
Robin's message, he has a point. Your recommendation does not currently have 
sufficient information to stand on its own as anything other than a 
pseudo-random choice on the chairs' part driven by the absence of a consensus 
from the group. While I have a lot of respect for you and your opinion, your 
credibility as chairs and IxTF participants is not strong enough to ensure that 
the recommendation is taken seriously by the community on face value alone. I 
assume that some thought went into the recommendation, so as they told me in 
math class - show your work. Take the reader through the thought process that 
led to this recommendation for you.

The recommendation certainly doesn't have to re-hash each discussion in the 
previous section, but it does need to hit a couple of the high points. I'd like 
to see something that expounds on the contributed critiques and defenses of ILNP 
when compared to the other proposals which are not being recommended - in other 
words, "the recommended proposal addresses the following problems present in X, 
Y, Z proposals (or categories of proposals) in the following ways...."
ILNP is an IPv6-only solution. IPv6 may do what so ever - for more than a decade. No one really cares. 
However, it would be against RFC4984 to ignore the IPv4's scalability problem incl. the associated Moore's-law-resistance.
Just supporting ILNP means ignoring the task given by RFC4984. Imho: ILNP is free to go ahead ( just as LISP was free to go ahead).
But that will not solve anything (well, it will please the chairs :-).
What is the ILNP locator all about? Is it routable? Or is it only mappable just like the MAC address or the current IPv4/v6 address?
Is it at least PI ? What is it really and precisely?
How about the basic requirement "incremental deployability" ? Is it a non-issue for ILNP because the few IPv4-addressers aren't worth to be considered?
Six years have been wasted so far and the actual decision of the chairs is blantly  ignoring the task to come up with an architecture that fits a future internet.

Heiner

It may also be helpful to at least identify why the outlined problems are 
fundamental enough to sink the other proposals.
Also, you need a section - "the following issues are still known to exist with 
the recommendations..." which leads to an explanation of why multiple proposals 
are needed, as well as outlining the problem-space that IETF needs to solve to 
actually implement these ideas.

As to why multiple proposals are required to solve the problem, you have some 
feedback in the form of the comments from myself and several other operators in 
Anaheim- We see AIS as a short-term solution to buy us time to build a better 
one, which in this case is ILNP. Consensus not being an option, I'd think that 
Operator feedback might be a good way to lend credibility.
Lastly, you also need to draw a better logical link to why renumbering is 
specifically mentioned here - if the problem is either unique to ILNP's 
implementation, or fundamental to make any of these proposals work better, say 
that. Otherwise, I'm not sure it's clear why that's referenced. We know 
renumbering needs work, we have a good draft telling us why, but unless you make 
it clearer why it's something that has to be fixed in the context of RRG- what 
not fixing it would exacerbate in the RRG recommended solution, it shows as an 
afterthought.

Thanks,
Wes

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tony Li
Envoyé : mercredi 14 avril 2010 00:36
À : IRTF Routing RG
Objet : [rrg] Proposal for recommendation language

Hi all,

Comments?

Regards,
Tony

----------------

This e-mail may contain Sprint Nextel Company 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: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Apr 2010 09:46:15 +1200

Hi Fred,

On 2010-04-16 05:00, Templin, Fred L wrote:
...
> other? Wouldn't that tend to have some bearing on the

Well, to take a few other examples, SHIM6, LISP, NAT66 and ILNP
can all be construed to provide the same effect, to a close
approximation. (You can quibble, for example SHIM6's ULID is
in fact an arbitrary PA address, although it behaves like
PI for the host, but broadly, they're all isomorphic).

IMHO that's why it's hard to choose. All solutions are
equivalent at a sufficient level of abstraction, so the choice
depends on details, and we're never going to agree on the
details.

    Brian

---

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 15 Apr 2010 16:20:01 -0700

Brian,

This is a good argument. However, the PI/PA issue may be the elephant in the room in this entire discussion. It is certainly a key issue that the RRG WG debated. Given that, I would like to see words in the recommendation that explicitly acknowledge that routing scaling benefits from locator aggregation while simultaneously end-users' nodal identifiers should be able to not have any ISP dependencies. The specific technology which is used to decouple the historic semantic overloading of the "IP identity problem" is less important for this WG than the fact that decoupling somehow needs to be able to occur via some appropriate technology choice for the local environment. To satisfy everyone, why not just enumerate all of the current possibilities (IRON-RANGER, SHIM6, LISP, NAT66, and ILNP)?

Best wishes,

--Eric 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, April 15, 2010 2:46 PM
To: Templin, Fred L
Cc: Tony Li; IRTF Routing RG
Subject: Re: [rrg] Proposal for recommendation language

Hi Fred,

> But, how can we give the customers the perceived advantages of PI 
> without locking them into a PA "matrix"?
> How can we make it so that the ISPs serve the customers instead of the 
> other way around? The IRON-RANGER solution to this is simple; have the 
> ISPs give the customers PA addresses, but then let them use the PA 
> addresses as a springboard into PI. Then, the customer border routers 
> get exposed to PA addresses, but the customer internal networks get to 
> use PI and get to multihome whether or not multi-addressing is also 
> used. So why not have a combined PA/PI scenario instead of strictly 
> one vs the other? Wouldn't that tend to have some bearing on the RRG 
> recommendation?

Well, to take a few other examples, SHIM6, LISP, NAT66 and ILNP can all be construed to provide the same effect, to a close approximation. (You can quibble, for example SHIM6's ULID is in fact an arbitrary PA address, although it behaves like PI for the host, but broadly, they're all isomorphic).

IMHO that's why it's hard to choose. All solutions are equivalent at a sufficient level of abstraction, so the choice depends on details, and we're never going to agree on the details.

    Brian

---

From: Tony Li <[email-masked]>
Date: Thu, 15 Apr 2010 16:26:27 -0700

Hi Heiner,

I¹m not sure that I see the point in going through these arguments yet
again, but in the interests of completeness, I¹ll recapitulate.

> decade. No one really cares.
You¹re speaking for yourself.  You don¹t care.  There are now lots of people
who do care, in part due to the IPv4 address space runout.
> 
> However, it would be against RFC4984 to ignore the IPv4's scalability problem
> incl. the associated Moore's-law-resistance.
> Just supporting ILNP means ignoring the task given by RFC4984. Imho: ILNP is
> free to go ahead ( just as LISP was free to go ahead).
> 
I¹m not sure what you¹re referring to, but the fact of the matter is that we
currently have exactly the same routing architecture for v6 and v4 and that
the problem that we have been chartered to solve is to address that routing
architecture.  As requested by 4984.
> 
> What is the ILNP locator all about? Is it routable? Or is it only mappable
> just like the MAC address or the current IPv4/v6 address?
It is a topologically sensitive namespace for Œsubnets¹, topologically
allocated and not associated with a host.
> 
> How about the basic requirement "incremental deployability" ? Is it a
> non-issue for ILNP because the few IPv4-addressers aren't worth to be
> considered?
> Six years have been wasted so far and the actual decision of the chairs is
> blantly  ignoring the task to come up with an architecture that fits a future
> internet.

ILNP is incrementally deployable.  Any host can individually deploy it and
it will continue to interoperate with legacy hosts.

Tony

---

From: [email-masked]
Date: Sun, 18 Apr 2010 08:18:56 -0400

Some comments inline. But I will also respond on the new thread.
Heiner

-----Ursprüngliche Mitteilung----- 
Von: Tony Li <[email-masked]>
An: [email-masked]; [email-masked]
Verschickt: Fr., 16. Apr. 2010, 1:26
Thema: Re: [rrg] Proposal for recommendation language

Hi Heiner,

I’m not sure that I see the point in going through these arguments yet again, but in the interests of completeness, I’ll recapitulate.

You’re speaking for yourself.  You don’t care.  There are now lots of people who do care, in part due to the IPv4 address space runout.
H: You are half right. I don't see that  IPv6 is a future-prone protocol and you don't either (see your own next comment).  

I’m not sure what you’re referring to, but the fact of the matter is that we currently have exactly the same routing architecture for v6 and v4 and that the problem that we have been chartered to solve is to address that routing architecture. 
H:Exactly, it has the same architecture as v4, only more address space (enough to identify each square micrometer on this planet, why????) and more inappropriate overloads: not only more of the misconcepted multicast addresses, but even anycast addresses!!!

 As requested by 4984.
H: Read what 4984 write about the hopes on IPv6!

It is a topologically sensitive namespace for ‘subnets’, topologically allocated and not associated with a host.
H:.. and will repeat the same mistakes as of PNNI - that protocol I once fervently supported, but which disproves itself, by requiring nodal topologies (the so-called complex node representation).

ILNP is incrementally deployable.  Any host can individually deploy it and it will continue to interoperate with legacy hosts.
H: If, as you say above,a new topologically sensitive namespace shall be provided, you have to change the existing addresses, right? When will you do that ? No flag day?

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Apr 2010 17:50:29 -0700

Hi all,

I promised to draft some text including some rationale for the
recommendation.  I'm attaching a first draft here.

While I do hope that folks find this clear, I don't expect that everyone
will find this compelling.

Most comments are welcome.  In particular comments of the form "I'm not
convinced, try again" of "based on this rationale, you should have picked
proposal XYZ" aren't particularly helpful.  Comments (and in particular text
contributions) that a) add points or clarify the message, b) improve the
text either editorially or via wordsmithing, or c) otherwise improve the
tone, strengthen the argument, or clarify the intent are very much welcome.

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.

17.1.  Motivation

   Without a new routing and addressing architecture, there is a concern
   that the cost and structure of the routing architecture as we know it
   today would become prohibitively expensive, with repercussions to the
   overall growth of the Internet.  We need to avoid this and must thus
   select some solution and push forward with it.

   For the long term future of the Internet, it has become apparent that
   IPv6 is going to play a signficant 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 runout 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.

   Whatever change we make, we should expect that this is a very long-
   lived change.  The routing architecture of the entire Internet is a
   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 change possible.  We should regard any such changes as
   permanent and we should therefore aim for long term solutions that

Li                      Expires October 21, 2010               [Page 61]

Internet-Draft             RRG Recommendation                 April 2010

   position the network in the best possible position for ongoing
   growth.  Our goal should be to make permanent, long-term changes to
   the architecture and those changes should be smoothly integrated,
   first-class citizens within 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 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 be replaced by long-term, permanent
   solutions.

   In the particular instance of the routing and addressing architecture
   today, we feel that both short-term improvements and long-term
   solutions are worthwhile.  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

   On behalf of the routing research group, the co-chairs would like to
   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
   those 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Apr 2010 15:37:43 +1200

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

I'm flattered to be cited, but I hope this doesn't convey the
impression that the draft (now in the RFC queue) offers a
solution. It's more of the nature of a problem statement and
gap analysis. I think it would be helpful to state that, to
avoid any false expectations.

...

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

Two observations:

1. Maybe add some words to point out that it isn't a done deal. ILNP
hasn't had the kind of across the board review in the IETF that seems
essential, to look for corner cases and unexpected consequences. There's
work to be done.

2. The IETF has already standardised a different approach (shim6) and is
in the process of specifying LISP. While this may be the IETF's problem
to sort out, perhaps you should also point out that we'd end up with
a menagerie of three species by adding ILNP.

     Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Apr 2010 23:53:18 -0400

Just to clarify, the LISP work is specifically aimed at experimental 
status.  This is the kind of space where multiple experiments seems 
quite sensible.

Yours,
Joel

---

From: Steven Blake <[email-masked]>
Date: Tue, 20 Apr 2010 00:07:13 -0400

>    locators in line with this abstraction.

I heartily agree that further work on automatic renumbering is needed.
However, ILNP could be deployed with ULAs and border locator translation
in the edge network, so it would not be strictly accurate to suggest
that automatic renumbering technology is a deployment dependency.

Regards,

// Steve

---

From: Robin Whittle <[email-masked]>
Date: Tue, 20 Apr 2010 15:32:59 +1000

Hi Tony,

Thanks for providing a draft of your proposed text.

You wrote:

> proposal XYZ" aren't particularly helpful.  

So you don't want to know about any serious disagreement - you only
want help wordsmithing and strengthening your arguments.  But
strengthening your argument involves anticipating disagreement and
providing suitable counter-arguments.

> Comments (and in particular text

In that case, I suggest you remove the 17.2 text:

  On behalf of the routing research group,

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

This portrays the failure to achieve consensus as being of the group
- and implies that the group "left" the task to the co-chairs.

As noted in (msg06441) you never pursued the finalisation of an
agreed goals document (as required by the Charter) and you generally
discouraged or banned discussion of "proposals" (candidate
architectures), without contributing much in the way of whatever
"architectural" discussions you wanted us to engage in.

You let the matter of writing the Recommendation drift without any
statement of your plans, until, after some questions from me in late
March, you announced your intention not to seek consensus, and to
write the Recommendation with Lixia.

If you want to strengthen your account of the background against the
inevitable criticisms, you might like to write something along the
lines that you tried to restrict discussion to whatever it was you
considered "architectural", and that you did not pursue the extended
discussion of, or the finalisation of, a "goals" document.

You might then explain why you did this.  I can't imagine a valid
justification, but you can.  You might like to explain when and why
you took this decision not to seek consensus.

However, in your defence, it should not be assumed that you and Lixia
were exactly thrilled at being given the task of co-chairing the RRG
and guiding a self-selected group towards discussion and consensus on
this very difficult problem.  Furthermore, while people complain
about you two taking it upon yourselves to write a Recommendation,
without seeking consensus, there is, so far, at this very late stage,
an extraordinary lack of action among most RRG participants in terms
of critiquing proposals other than their own and in terms of writing
what they would like to see in a comprehensively argued Recommendation.

>    The

OK.

>    is to provide improved scalability.

Yes - but "scalability" is just a single word.  I think it is vital
that you explain your understanding of the goals, such as:

   IPv4 vs. IPv6.  One or the other first, or not bother with IPv4?
   This involves questions of how long IPv4 will be used for, and
   what costs there will be if its scaling problems are not solved.

   Portability vs. expecting networks to renumber when they choose
   another ISP.

   Coping with the continued (highly constrained) rate of growth in
   multihomed end-user networks vs. allowing a much greater rate of
   growth (to better match the needs of end-user networks) in a
   scalable manner.

   Having the architectural enhancement directly facilitate mobility
   or not.

   To what extent it is justifiable to burden all hosts with extra
   processing, extra communications and extra delays when
   establishing a communications session in order to achieve scalable
   routing (however defined) without adding much, or anything, to the
   network itself.

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

I suggest you cite some of these "non-trivial" deployments.  I can't
think of any - and I guess many readers would have the same difficulty.

>    It

With this, you simply skip over the problem of solving the only
current or near-term routing scaling problem: IPv4's.  I think most
readers will recognise this avoidance and so regard your
recommendation with increased suspicion.

>    These cannot be undertaken lightly.

OK.

But if long-term always trumps problems with introduction, we would
all change to a Dvorak keyboard and all countries in the world would
standardise on driving on one side of the road.

You have failed to mention that architectural changes can only be
adopted voluntarily, and that there are considerable constraints on
this form of adoption, when it is considered that very high adoption
rates are required to solve the scalability problem.

In the case of ILNP or any other CEE architecture, you need to have
100% (or close to 100%) adoption before any adopter gains proper
benefits (being able to rely on the new system for all their traffic)
and before you can gain substantial scaling benefits.  These
constraints don't apply to CES architectures, which can provide
immediate full benefits to adopters, and routing scaling benefits in
direct proportion to levels of adoption.

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

IPv6 is a great idea in many ways.  If not for constraints such as
these, it might have been very widely adopted in recent years.

To ignore these constraints would probably doom your recommended path
of action to the same extended and potentially permanent Limbo that
IPv6 languishes in.

>    the best change possible.  

Yes - but what is "best", when the host-based (CEE = Locator
/Identifier Separation) architectures add to host complexity, delays
and traffic requirements?  This is particularly significant since in
the foreseeable future, I think it is reasonable to expect most hosts
will be hand-held devices hanging off a tenuous 3G or similar
wireless link, with their operation fundamentally constrained by the
limits of their batteries.

>    We should regard any such changes as

OK.

>    short-term improvements should be replaced by long-term, permanent

OK.

The IETF has also had a spectacular failure in proposing IPv6 as if
the barriers to widespread adoption were far less than are actually
the case.

>    recommend that the IETF pursue work in the following areas:

I suggest you change this to:

     The co-chairs recommend that the IETF pursue work in the

>    locators in line with this abstraction.

I listed my primary objections to these in (msg06441).

I think you should acknowledge that ILNP:

  1 - Can't help with IPv4.

  2 - Requires all hosts adopt IPv6 and then adopt the ILNP changes
      to IPv6.

  3 - Is in a very early stage of development.

  4 - Is one of four CEE (Locator / Identifier Separation) proposals
      - and you have not explained why it was chosen over the others.

  5 - Involves extra processing, extra packets and typically extra
      delays in establishing initial communications.

  6 - Can't support certain important functions which are done today
      such as ACLs based on IP addresses.

I think you should also note that "Renumbering" is not an RRG
proposal, and that the author of the I-D you cite - Brian Carpenter -
recently (msg06470) wrote that his I-D is a problem-statement and
gap-analysis, not a solution.

 - Robin

---

From: Paul Jakma <[email-masked]>
Date: Tue, 20 Apr 2010 11:27:39 +0200 (CEST)

>   select some solution and push forward with it.

I know mine is a minority view, given earlier polls here, but I do 
think the case for there being a problem isn't quite that settled, on 
an evidential basis at least. As such, I think the above ought to 
admit just a teeny bit of uncertainty. E.g.:

  "There is a general concern that the cost and structure of the
   routing 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 to it."

However, it's your text. ;)

>   first-class citizens within the architecture.

This is somewhat repeating the immediately previous? Possibly can be 
compacted a little.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
It is a wise father that knows his own child.
 		-- William Shakespeare, "The Merchant of Venice"

---

From: Eliot Lear <[email-masked]>
Date: Tue, 20 Apr 2010 14:54:00 +0200

>     recommend that the IETF pursue work in the following areas:

As this is a recommendation from the chairs, I believe that the correct 
wording would be as follows:

      The co-chairs recommend that the IETF pursue work in the following
      areas:

This conveys the appropriate message that this is a chairs' report.

Eliot

---

From: David Williamson <[email-masked]>
Date: Tue, 20 Apr 2010 06:37:05 -0700

> providing suitable counter-arguments.

So, despite a request to not do so, you are going to (again) state your
case.

I think the entire group is clear on your position, and I think we're
clear on the degree of your disagreement with the direction tho chairs
have chosen to go with the recommendation.

Please stop.  Your volume already makes keeping up with this group
difficult, and the continuous restatement of the same material is not
helpful.  Please stick to the questions at hand.  That will make your
messages far more valuable to all of us.

Thanks.

-David

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Apr 2010 11:41:18 -0700

Hi Brian,

> avoid any false expectations.

Sure, added some text in that direction.

> essential, to look for corner cases and unexpected consequences. There's

There's work to be done in ALL of the areas that we recommended.  In fact,
the first sentence of the recommendation reads: " ...  recommend that the
IETF pursue work in the following areas".

> a menagerie of three species by adding ILNP.

You are correct, this is the IETF's problem.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Apr 2010 11:44:26 -0700

Hi Steven,

> that automatic renumbering technology is a deployment dependency.

You are correct, it's not a requirement, but there is a large segment who
have religious objections to border locator translation (i.e., NAT).  Thus,
some form of renumbering really is a requirement in the long run.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Apr 2010 11:51:52 -0700

Hi Paul,

> However, it's your text. ;)

I'm missing the distinction here.  Seems like a concern is still a concern.

That said, thank you, text accepted.

> This is somewhat repeating the immediately previous? Possibly can be

Agreed, thanks, will address.

Tony

---

From: [email-masked]
Date: Tue, 20 Apr 2010 14:51:53 -0400

Tony

But this is what I thought with the incremental deployment issue. You told me that ILNP is incrementally deployable.
And now you say that there would be a renumbering requirement in the long run, which actually means, a flag day for renumbering is required from where on a changed interpretation of the address'es octets would apply.

I remember a long discussion, resulting with the ban for any solution that required a flag day.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Tony Li <[email-masked]>
An: Steven Blake <[email-masked]>
Cc: IRTF Routing RG <[email-masked]>
Verschickt: Di., 20. Apr. 2010, 20:44
Thema: Re: [rrg] Proposal for recommendation language

Hi Steven,

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Apr 2010 12:02:34 -0700

Hi Eliot,
>  This conveys the appropriate message that this is a chairs' report.
 First, I¹ve added some text in the Introduction:

      This document also includes the recommendation from the research
      group to the IETF.  The group did not reach consensus on this
      recommendation, thus the recommendation reflects the decision of
      the co-chairs.  The group did reach consensus that the overall
      document should be published.

The last sentence is a bit presumptive at present.  ;-)

Second, please recall this text from the top of section 17:

    The remainder of this section describes the rationale and decision
    of the co-chairs, and does not reflect the consensus of the group.

Third, I¹ll point out once again that under the rules of the IRTF, as I
understand them, the group¹s process and results are at the discretion of
the co-chairs.  It¹s very true that the decision has been made by the
co-chairs and as such I¹m trying to be very careful and emphasize that this
is not the consensus of the group.  However, it is still the output and
result of the group.

Regards,
Tony

---

From: Paul Jakma <[email-masked]>
Date: Tue, 20 Apr 2010 21:08:39 +0200 (CEST)

> I'm missing the distinction here.  Seems like a concern is still a concern.

Well, the initial paragraph suggests that it is a settled matter that 
a new architecture is required. The intent of my revision was to make 
it a bit more open - i.e. that the concerns are about the 
architecture and whether it can or can not scale, and that this needs 
investigation.

You did ask for word-smithing. ;)

> That said, thank you, text accepted.

Welcome.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
I have a terrible headache,  I was putting on toilet water and the lid fell.

---

From: Tony Li <[email-masked]>
Date: Tue, 20 Apr 2010 12:10:58 -0700

Hi Heiner,
> And now you say that there would be a renumbering requirement in the long run,
> which actually means, a flag day for renumbering is required from where on a
> changed interpretation of the address'es octets would apply.
> 
The two issues are not coupled and I don¹t understand how or why you are
trying to couple them.

Again, there is no flag day.  You can deploy ILNP initially and have it
interoperate with legacy v6 hosts.  If you need to change providers with
ILNP and you are a NAT-lover, you can do that.  If you are a NAT-hater, then
you can do traditional manual renumbering or we will have renumbering tools
so you don¹t have to.

Tony

---

From: [email-masked]
Date: Tue, 20 Apr 2010 15:17:02 -0400

Thanks,
Heiner

Hi Heiner,

The two issues are not coupled and I don’t understand how or why you are trying to couple them.

Again, there is no flag day.  You can deploy ILNP initially and have it interoperate with legacy v6 hosts.  If you need to change providers with ILNP and you are a NAT-lover, you can do that.  If you are a NAT-hater, then you can do traditional manual renumbering or we will have renumbering tools so you don’t have to.

Tony

-----Ursprüngliche Mitteilung----- 
Von: Tony Li <[email-masked]>
An: [email-masked]; [email-masked]
Cc: [email-masked]
Verschickt: Di., 20. Apr. 2010, 21:10
Thema: Re: [rrg] Proposal for recommendation language

Hi Heiner,

The two issues are not coupled and I don’t understand how or why you are trying to couple them.

Again, there is no flag day.  You can deploy ILNP initially and have it interoperate with legacy v6 hosts.  If you need to change providers with ILNP and you are a NAT-lover, you can do that.  If you are a NAT-hater, then you can do traditional manual renumbering or we will have renumbering tools so you don’t have to.

Tony

---

From: Darrel Lewis <[email-masked]>
Date: Tue, 20 Apr 2010 12:47:11 -0700

> some form of renumbering really is a requirement in the long run.

Or use of encapsulation.... 

-Darrel

---

From: [email-masked]
Date: Tue, 20 Apr 2010 16:50:18 -0400

...which could be improved substantially by using routable information rather than just mapable information in the outer header.
Heiner

-----Ursprüngliche Mitteilung----- 
Von: Darrel Lewis <[email-masked]>
An: Tony Li <[email-masked]>
Cc: IRTF Routing RG <[email-masked]>
Verschickt: Di., 20. Apr. 2010, 21:47
Thema: Re: [rrg] Proposal for recommendation language

-Darrel

---

From: Robin Whittle <[email-masked]>
Date: Wed, 21 Apr 2010 13:26:07 +1000

Hi Tony,

You wrote:

>            On behalf of the routing research group, the co-chairs would
>            like to recommend that the IETF pursue work in the following areas:
>          
>     As this is a recommendation from the chairs, I believe that the
>     correct wording would be as follows:
>      

I suggested the same text (msg06474):

            following areas:

> First, I’ve added some text in the Introduction:
> 

The first sentence is misleading, since the Recommendation section
comes entirely from the co-chairs, not from the other participants.

>     of the co-chairs, and does not reflect the consensus of the group.

As I indicated (msg06474), I think this sentence is fine.

> Third, I’ll point out once again that under the rules of the IRTF, as I
> understand them, the group’s process and results are at the discretion
> of the co-chairs.  

That's my understanding too.  Compared to an IETF WG, the co-chairs
have more of a free-wheelin' ability to shape the process and
outcomes as they wish.  I think this is fine in principle, since it
enables you to make good use of whatever resources you have available
from other participants, but enables you to be more autocratic and
less bound by strict process rules if you find the participants
unable or unwilling to progress the project in the manner you think
is best.

I think this is a very difficult field technically, and the RRG
participants are all self-selected, with a great diversity of
viewpoints.  My guess is that even with the very wisest choices, you
and Lixia may not have achieved consensus.  I think you could have
done more to facilitate constructive debate - on goals, constraints,
commonalities and differences between the architectures and on the
merits of the different architectures themselves.

Its your choice to write a Recommendation - and your choice how to
justify it.  While technically this is allowed under IRTF rules (RFC
2014) and technically the output of the group is whatever you decide
it to be, I think is is misleading to write:

  group to the IETF.

This is a self-selected set of individuals.  There's no membership or
entry / exclusion criteria.  It is called a "group", but it is not
really a group.  The set of active participants - those who write to
the list and/or who speak at meetings - is no-where near forming
consensus on which one or more architectures to recommend to the
IETF.  As far as I know, everyone supports the creation of a final
report, with the summaries, critiques, "rebuttals", reflections etc.

I support you and Lixia writing your Recommendation text - as long as
there is no pretence that this comes from anyone but you two, as
individuals who are also the co-chairs.

> It’s very true that the decision has been made by the
> co-chairs and as such I’m trying to be very careful and emphasize that
> this is not the consensus of the group.  However, it is still the output
> and result of the group.

Only in a formal and reductionist sense.  It is an open question how
much of the participants' discussions, documents and proposals you
have read, understood or properly considered.  As I wrote previously,
 (msg06373) some of the meeting slides indicate you misunderstand
some proposals.  You (Tony) have generally only discussed ILNP on the
list.

The participants have contributed to many discussions and developed a
bunch of architectures.  Several documents of lasting value (I think)
to the field have been produced by the participants.   The
participants generated summaries, critiques etc. and you have
collated these - including by setting length limits and by choosing
one out of the sometimes two or more contributions.

The participants did not produce any recommendation, set of goals, or
taxonomy which has achieved consensus.

The recommendation you and Lixia are writing is your work - it is not
written by any of the other participants, and so far there has been
little support for it.

So far, no-one but me (msg06219) has gone to the trouble of writing a
properly referenced, fully argued, Recommendation text.  I suggest
that anyone who criticises your Recommendation should first provide
the full text of a Recommendation they would prefer.

  - Robin

---

From: Steven Blake <[email-masked]>
Date: Wed, 21 Apr 2010 00:38:43 -0400

> some form of renumbering really is a requirement in the long run.

A large segment has religious objections to site renumbering.

Both approaches have pros and cons, and those change with a locator/id
split architecture like ILNP.  Better to cater to everyone's religious
preferences where possible, IMHO (as long as there are no innocent
third-party victims!).

Besides, the IETF already has a multi-homing solution that depends on
multi-addressing in the edge network.

Regards,

// Steve

---

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

Hi Tony-

> The last sentence is a bit presumptive at present.  ;-)

I also don't believe it is a true statement. As currently written, I
would not agree that this document should be published as the product
of a group called "the RRG", particularly not if my attendance in all
of the RRG meetings, including on the "[email-masked]", and participation
in all of the discussions that occurred during the past three years
mean that I am a member of that group.

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

which I realize is undergoing changes. The critical point is that
by stating "On behalf of the routing research group", you are implying
that this document is a recommendation that reflects the opinion of
the group of people making up "the RRG", which presumably includes
those on the "[email-masked]" mailing list and/or those who attended
RRG meetings during the past year. This implication will remain even
if you explicitly state elsewhere in the document that no consensus
exists. Given the lack of any semblence of consensus (beyond perhaps
an agreement that no conensus on any recommendation is possible), it
is completely inappropriate to even suggest that "the RRG" contributed
to or supports this recommendation.

In addition, I strongly object to the naming of this document; by
titling it "draft-irtf-rrg-recommendation-xx.txt" there is once again
an implication that the document and any recommendations it contains
reflects agreement among members of "the RRG". As discussion before,
during, and after the last RRG meeting has clarly shown, that simply
is not the case and to imply otherwise is misleading, however
unintentionally.

If this document is to stand as written, it must be renamed and
resubmitted as an individual contribution by the RRG co-chairs.
Furthermore, any text which implies or infers that its
recommendations reflect the opinions or views of other RRG
participants must be excised before it is published. I welcome your
describing the alternatives considered within the RRG and the
deliberations that went on there but any recommendation must be
exlicitly labelled as the opinion of you and your co-chair.

I am aware that the results of IRTF RG are not required to reflect
group consensus but am concerned that the audience for your document,
which will include the IETF and the larger community of RFC readers,
do not understand this fine distinction between an IRTF RG and IETF
WG. In my opinion, there is sufficient potential to mislead or confuse
that both the content and the process of publication for this document
must be crystal clear regarding its origin.

As a participant in all of the RRG meetings and discussions that
occurred during the past three years, I cannot in good conscience
allow my name to be associated, either implicitly or otherwise, with
the recommendations made in this document; my guess is that other RRG
members feel the same way.

An alternative approach (suggested by Noel) to resolving these
concerns might be to split this document into two: the first would
describe the RRG deliberations and include the synopses of various
proposals, maybe along with classification of each along several axes,
such as: host vs. network-based solution; network elements requiring
changes (hosts, customer-preises equipment, provider-edge, core);
applicability for IP, ipv6, or both; infrastructure dependencies
(DNS, new devices/services needed, etc.) and so on. Such a descriptive
document would be an excellent and successful output from the RRG and
I would wholeheartedly support its publication as a product of the
RRG. The second document would express your opinion and recommendation
to the IETF and would be an individual submission Internet-Draft and
RFC with you and Lixia as the authors; it would reference the
descriptive RRG document and explain how you came to your conclusion.
Section 17 of your current draft would form the basis of the second
document while the remainder would make up the first. I hope you will
consider this suggestion as a way of communicating good information
to the Internet community while at the same time clearly defining
where agreement did and did not exist during the RRG deliberations.

Incidentally, I would be also interested in seeing the opinions of
RRG members on how to move forward with this. Given four options:

  1. publish the document as-is as an RRG recommendation to the IETF
  2. remove RRG references and publish as an individual contribution
  3. split the document as described above
  4. none of the above (please describe an alternative)

which would you choose?

	Thanks,
	--Vince

---

From: "Hongbin" <[email-masked]>
Date: Fri, 23 Apr 2010 05:44:56 +0800

I'd like #3.

Hongbin

#1. publish the document as-is as an RRG recommendation to the IETF
 #2. remove RRG references and publish as an individual contribution
 # 3. split the document as described above
 # 4. none of the above (please describe an alternative)
#which would you choose?
#Thanks,
#--Vince
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: [email-masked]
Date: Thu, 22 Apr 2010 17:51:49 -0400

Well spoken Vince. Obviously, I am not the only one who deeply disagrees.
Therefore I also think the recommendation should be an individual contribution of chair and co-chair.

It would have been much better if the group had tried to understand that the trouble is caused by  the wrong paradigms themselves.
Lixia's comparison with the "things of the right size (lung versus skin for breathing) doesn't even get close: Not only that the scalability issue can be eliminated, we could 
come up with a much better routing technology, e.g where in principle ALL users can be mobile (including the home agents!) and where  Moore 's law became fully applicable.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Vince Fuller <[email-masked]>
An: Tony Li <[email-masked]>
Cc: IRTF Routing RG <[email-masked]>
Verschickt: Do., 22. Apr. 2010, 23:16
Thema: Re: [rrg] Proposal for recommendation language

Hi Tony-

which would you choose?

    Thanks,
    --Vince

---

From: Robin Whittle <[email-masked]>
Date: Fri, 23 Apr 2010 13:04:21 +1000

I support everything Vince wrote (msg06522), including his option #3:
there being two documents - one being summaries, critiques,
"rebuttals" etc. as an RRG RFC and the other being a recommendation,
written by Lixia and Tony, published under their names and not as an
"RRG document".

Extending this a little, I think everyone should have a go at writing
a recommendation - ideally with goals, non-goals, analysis of all the
proposals etc. along the lines of my (msg06219).  These could be
separate RFCs by separate authors.

Alternatively there could be an omnibus RFC with recommendations from
various authors, including the co-chairs.  This might be published as
an RRG RFC, as long as it was clear that it was a compendium of
contributions with no inference about consensus or levels of support
from RRG participants.

  - Robin

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 23 Apr 2010 08:40:48 +0200

Hi,

I agree with the comments Vince Fuller sent to the mailing list, and I think that option #3 (split the document) is the fairest solution.

Luigi

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Fri, 23 Apr 2010 11:57:41 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vince Fuller
Sent: Thursday, April 22, 2010 5:17 PM

[[WEG]] <snip>

[[WEG]] I say option #1, or option 4, with option 4 defined below. Sorry in advance for the longish email, but there's a lot to discuss.

My reasoning for #1 -
RRG did not reach consensus. Failing the chairs making a recommendation, this would have been a filibuster - endless debate blocking progress, and it would have gone on indefinitely. It's time to move on. RRG is not helpful to the community if it waits so long to make a recommendation that the problems which brought us here in the first place start becoming reality before IETF has a chance to implement anything to fix it, nor is it helpful to simply have one proposal outlast the others by wearing them out in debate.

I'm a relative outsider on this list. I dropped off the list for nearly a year because I couldn't keep up with the volume, and then rejoined prior to the Anaheim meeting in the lead-up to the recommendation. Whether that gives me any sort of unique perspective or not I leave to you to decide. However, I can say that I have *still* seen some of the same arguments go around in circles since I rejoined, and I don't see any compromise in sight.
I'm by no means trying to minimize the contributions that anyone made to RRG, nor make a statement on the quality of each proposal, but... My sense of what happened here is that those who came up with proposals were so convinced that their idea was the right one that they either DOS attack us with email in support of it in the belief that someone is only against the idea because they don't understand it well enough, or were simply unwilling to compromise in such a way as to come up with a uniform recommendation that takes the best parts of several ideas and combines them. It may be that they believe (right or wrong) that their solution is incompatible with the others, but I find it hard to believe that two proposals in the same class [referencing Anaheim presentation for classification] could not find any common ground in implementation. Thus, we end up with 15(!) separate proposals, and deadlock.

So to phrase that another way, a chair recommendation is the tiebreaker so that we can start moving forward. If your proposal wasn't chosen, are you open to working to make the chosen proposals better as they transition to IETF? Or would you rather this be about making sure IETF knows that you disagree with the chairs' recommendation, or that you were the one with the "big idea" that fixed the internet? If it's the latter two, feel free to write an individual contribution refuting the RRG recommendation, as I think Tony has done a good job modifying the text to reflect the fact that this isn't a consensus recommendation, and why that's still ok within the context of an IRTF group.

Further, as Tony stated a few weeks ago, those who are unhappy with the choice that the chairs made are free (and encouraged) to pursue individual contribution drafts, perhaps taking the direction that the LISP folks took and either getting their own WG started, or at least shopping their ideas to existing WGs to get them to take on the effort of refining the idea with an eye to eventual implementation.

Option 2/3 is a no-op, because not only would there be a Tony/Lixia doc, there would be an IVIP doc, and there would be a [LISP] doc, and an IRON-RANGER doc, etc, etc. It would only prolong the current state of non-consensus.

Regarding #4 - As I see it, there are two alternatives:
1) Compromise, and actually distill the 15 proposals down to a few proposed implementations based on the way that they solve the problem.
2) Admit defeat and punt to IAB with no recommendation, with the assumption that IAB will be able to look at this objectively and provide the compromise that has failed to happen in RRG, and recommend a path forward within IETF. This would likely take the form Vince described of perhaps further classifying the proposals in the existing document and leaving a big [to be completed by IAB] in section 17.

Unless there is a sudden groundswell of support for taking the multiple proposals and merging them down to perhaps one recommendation in each class of solution (and yes, I realize that there isn't even agreement on how to classify some of these), or a recommendation of a certain *type* of solution instead of a specific proposal, I think it's time to call the horse dead, and already beaten to sub-molecular bits.

For example -
Both of the recommendations made in Anaheim fit into Class 1. I assume that the chairs believe that this is the best type of solution of the 3 classes. There are obviously others who disagree, and think that either a Class 2 or Class 3 solution might be best, but it doesn't work as a recommendation to say that all 7 or 5 or 12 of those proposals are recommended. My personal opinion is that since LISP already is well into the "running code" phase, and is therefore much further along in actual refinement by the community at large, it would be the recommended map-and-encap solution, and that at some point those with alternatives in this space need to help the LISP WG resolve the problems that they perceive to still be extant in that implementation, perhaps using ideas from your own proposals. The correct solution is NOT to continue trying to convince people in RRG that your idea is better.
Also, if RRG recommends multiple types of solutions (one from each class, for example) there would need to be more written on the pros and cons of each type of solution, so that the recommendation can further be refined down to an actual course of action to solve the problem within the auspices of IETF WGs. I don't believe that the IETF has the resources to solve the problem multiple times by recommending multiple solutions and starting a race within IETF, so I think that making a general architectural recommendation based on a type of solution agnostic to the solution proposals themselves, and then leaving the debate about which implementation is best to the WGs that end up taking up the work is probably a no-op and would still require direction from the IAB.

I don't know if the recommendation as written today will ultimately result in IETF taking the recommended action. If the recommendation is truly just the chairs' and the majority of IETF believes they're wrong, chances are it won't. But I do know that the solution to the lack of consensus problem isn't to write MORE reams of text in support of individual proposals as in option 2/3 above, and I don't see much value in splitting the draft up.

Thanks,
Wes George

---

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

> 2) Admit defeat and punt to IAB with no recommendation, with the assumption
> that IAB will be able to look at this objectively and provide the compromise
> that has failed to happen in RRG, and recommend a path forward within IETF.

There's a few points of clarification needed here: first, our recommendation
went to the IESG, not to the IAB.  Second, that recommendation has already
been delivered.  What we're talking about now is producing the formal
supporting documentation.  Third, our recommendation does NOT include a path
forward within the IETF, as that's an internal IETF matter.

Regards,
Tony