Short version: I plan to write my own personal "scalable routing
design goals" I-D - probably in the next few months.
Most of the people who have contributed
substantially to the RRG since 2007, including
all the LISP folks, have not been involved in
this discussion of goals, or in voting about it.
There's no hurry with scalable routing. ILNP or
any other kind of Loc/ID Separation will be
extremely difficult to develop, since AFAIK, they
requires applications to be rewritten and only work
on IPv6. Even if it is developed, almost no-one
will want to adopt it.
I imagine the growing de$ire for global mobility will
drive further progress on scalable routing - and that
won't necessarily involve the IETF or the IRTF.
Since Wes' message hasn't turned up on the list yet, here is what he
wrote to me and the list, followed by my reply:
On 23/11/2010 3:28 AM, George, Wes E [NTK] wrote:
> Robin, enough is enough.
>
> tl;dr version:
> Put up or shut up. Replace "we" in your subject line with "Robin"
>
>
> What I see here is an email from you admitting that you've been absent from
> the discussion when we were actually reviewing the draft and making
> suggested wording changes during last call. Now you show up well after the
> extended last call and the consensus check is over, with ~7500 words about
> all of the ways that you disagree with the current draft, and more martyrism
> about opposing viewpoints being ignored and accusations of bias in the
> document and on the chair's part. Nevermind the fact that if incorporated,
> many of your comments would suggest a bias in the opposite direction since
> it's clear that you want the reader to conclude that a different type of
> solution than what is being proposed in the RRG recommendation is the
> correct one.
>
> Far more importantly, you're recommending a significant rewrite of a
> document that at least 12 of us consider done, with almost no proposed draft
> text to address your concerns except in section 3.5, 3.10 and your proposed
> additional sections. And as far as I can tell, you're pointing to the
> relatively low word count as part of the reason why this draft is in bad
> shape. I won't bother with a discussion about quality vs quantity, even if
> it is NaNoWriMo.
> The only thing I see to your defense is that you made these arguments in
> 2007. So by implication we should have remembered this and taken it into
> account during our review?
>
> If you're so convinced that the current draft is in bad enough shape as to
> call one or more sections a "horror" then it's time (past time, actually)
> for you to write an individual submission design goals draft that covers
> your concerns and reflects your views on what the design goals should be.
> Perhaps if things are as you imply and there is a statistically significant
> minority whose views are being ignored or quelled by the RG chair, and the
> consensus that has been derived is self-selecting and therefore not
> representative, your alternative draft can incorporate other disenfranchised
> members' views as well.
>
> If I were you, instead of crying "foul" yet again, I'd write it fast and
> hope that our chair is willing to indulge your tardiness instead of simply
> taking the results of the poll that show consensus among those who voted,
> and pushing this forward to IRSG as is in the name of forward progress. It
> shouldn't be hard for you to write "something much better" since as you say,
> you've been raising these concerns since 2007, you clearly have a good sense
> for how you think that the document should be structured, what it should
> cover, etc, and you're obviously prodigious at generating text. However, if
> you want me (I can't speak for the rest of the group) to seriously consider
> it as an alternative, I challenge you to make it a succinct, objective
> discussion of the problem space and design goals, and not biased towards
> your personal worldview on the matter.
>
> Wes George
Hi Wes,
Thanks for your suggestion.
Rather than debating how I do or don't contribute to the RRG, I was
hoping you and others would debate the substance of my critique.
Do you really support the goal that the solution be either Loc / ID
Separation (ILNP etc. not LISP, Ivip or IRON) or be compatible with
Loc/ID Separation?
If so, can you or anyone else think of a way any Loc/ID Separation
architecture could work on IPv4?
Can you or anyone else think of a way it could work even on IPv6
without requiring a major rewrite of application code, and in some
cases changes to application protocols themselves? Ran claims that
ILNP claims to be able to run with existing IPv6 apps, but when I
tried to figure out how this could be done, I decided it probably
couldn't be. Ran didn't even attempt to show how it could be done.
Tony tried (msg07111) and gave up, commenting: "And having a name
oriented stack would be the best solution." A Name Oriented Stack
(AKA Name Based Sockets) is a Loc/ID Separation architecture which
fully declares the need to rewrite apps, and by implication change at
least some application protocols significantly.
There is probably no greater barrier to development and adoption than
the need to move to IPv6 and rewrite all the apps.
Its not possible for me to write a document in this field which I
strongly support and have no-one think that it "reflects my biases".
The same goes for anyone else trying to do the same thing.
I can't imagine anything I write or strongly support having the
support of Tony to become some kind of alternative document under the
auspices of the RRG. The current draft will no-doubt go on to be an
RFC.
I think it is notable that no-one from the LISP team has bothered
casting a vote:
http://doodle.com/idw28gc26vezipv9
Likewise, where are Bill Herrin, Christian Vogt, Brian Carpenter, the
APT people (Dan Jen and Michael Meisel), Eric Fleischman, Iljitsch van
Beijnum, Noel Chiappa, Joel Halpern, Philip Eardley, Tom Vest or
Xiaohu Xu? These are some of the people who put a lot of work into
the RRG in the past - either with their own proposal or with helpful
analysis of other peoples'. Some are no-doubt busy or distracted, but
their absence from the debate about the Design Goals makes me think a
lot of people who really care about scalable routing have given up on
this process.
For an example of why, look no further than Tony Li's blank response
to Fred Templin's concerns about having accidentally voted for a
document which he believes (as I suggested) strongly supports (or more
likely effectively mandates) Loc/ID Separation - which he is opposed to.
Tony has spent years ignoring or deriding stuff on the list which he
doesn't like. Consequently progress and discussion has been
constrained by his focus on the architectural purity of Loc/ID
Separation to the exclusion of all other considerations. He has shown
no interest in the constraints we face due to the need for widespread
voluntary adoption. Fortunately, some people stuck it out and ignored
his guidance. Some real work was done and fresh ideas were generated.
In the next few months I plan to write an individual I-D containing a
set of design goals which make sense to me. If the RRG still exists,
then people can discuss it, express support etc. and suggest
improvements on the list. If the RRG list is closed, I guess people
involved in scalable routing will have another mailing list.
I agree, ideally I would do this right now. Likewise, ideally, I
would write up the two new "Zero Overhead Tunneling" ideas as I-Ds and
revise the other Ivip I-Ds to use this instead of encapsulation.
However, I need to give priority to some other things - like earning a
living. There's a special monk-like headspace I need to engage with
xml2rfc and write an Internet Draft. I find that process is at odds
with all other aspects of life.
There's no tearing hurry about scalable routing. LISP isn't getting
any closer to resolving its fundamental problems, such as with how
ITRs can decide which ETR to tunnel to. I am sure the processes the
RRG Report will set in motion, based on the co-chairs' recommendation,
will never produce a solution that anyone wants to adopt.
ILNP or any other Loc/ID Separation architecture is a complete
non-starter. Even if it worked on IPv4 and didn't require apps to be
rewritten, it wouldn't get very far imposing a ID->LOC lookup and
consequent extra delays on the responding hosts before they can send a
reply packet (for the many application protocols where it matters what
you send in the reply and to which host). Likewise its reliance on
everyone adopting it before it becomes useful to users, or for
scalable routing.
There will be a growing desire for limiting the growth in DFZ routes
and for making multihoming much more accessible to smaller end-user
networks. I think the pressure for global mobility for IPv4 will grow
much faster - and I guess that this will be the impetus for developing
a CES based scalable routing system as part of something like TTR
Mobility.
These developments won't necessarily happen in the IETF or IRTF. A
start-up company - or the Google-zilla looking for something fresh to
chew on - could develop their own protocols, build a system of servers
and just get on with selling the service. Hopefully all that I and
others wrote about on the list, in I-Ds and on our websites will be
regarded as public domain, and so won't be patentable.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
