Short version: To generate either Experimental or Standards Tracks
RFCs for something complex like a scalable routing
solution requires a lot of work, by many people -
as far as I know, in an IETF Working Group.
Hi Tony and Fred,
Tony, in an earlier message, you wrote:
> Going to proposed standard without an IETF WG is a VERY
> unlikely path to success. While it is possible, it would
> have to be something that is so uniquely controversial and
> necessary that an AD would be willing to put their
> reputation on the line.
I guess you meant "uncontroversial". As far as I know, in order to
create standards tracks RFCs, you really need an IETF WG and at least
one (or is it more?) working implementations. To do this, you need
support and involvement from a significant number of people, and you
need to build some kind of test network, publish the software etc.
Without reading the rules, I would guess that the requirements for an
experimental protocol are lower - perhaps not requiring a WG.
However, for anything with such ambitions and implications as a
scalable routing protocol, I can't imagine it would be simple enough
or uncontroversial enough to create substantial protocol standards,
RFCs or not, without attracting a bunch of people and having them
work together to write the code, or at least test it and refine the
proposal on the basis of their wider experience.
In my view there are only three scalable routing proposals which have
a chance of being practical or desirable interest - all Core Edge
Separation architectures. In order of importance - how well they
might work once properly developed - I think they are:
Ivip
IRON
LISP
In the next few years I doubt that I will have the time - the money
so I could spend a year or two working full time on a project like
this - to fully develop Ivip. However, the ideas are there and are
well enough documented that people can use them, such as for
developing a commercial system based on Ivip, with TTR Mobility,
primarily for global mobility but also potentially for multihoming of
non-mobile networks.
IRON is in a state of flux, as comments from me and others prompt
significant revisions. So I can't imagine how it could be finalised
into an experimental protocol without a lot more work - by a team of
people in a WG, as far as I know.
The original LISP team are working with other people in the LISP WG,
aiming to produce a set of RFCs for LISP, not including mobility, as
an experimental protocol. With the original deadline already passed,
I think they are far from sorting out the complications and
contradictions in their design to produce something which works as
well as they intend. I can't imagine the current design ever leading
to a successful outcome, so I doubt if another year or two's work
will make much difference.
I believe that ILNP and other CEE architectures are non-starters, for
reasons outlined in:
http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html
plus a bunch of other concerns which have emerged since then:
http://www.ietf.org/mail-archive/web/rrg/current/msg07185.html
I think ILNP is even less developed than Ivip, IRON or LISP - with
Ran and its few other supporters apparently uninterested in solving,
or admitting the reality of, such basic problems as whether ILNPv6
could work with all existing IPv6 applications, or how viable ILNPv6
mobility can be with the "Identifier squatting" problem.
There hasn't even been an update to ILNP to enable it to do the
equivalent of "round-robin" DNS, with one FQDN mapping to multiple
physically separate hosts, though this problem was pointed out
earlier this year. It shouldn't be hard to alter ILNP to do this,
but no effort has been made. At present, ILNP could only do this if
all the hosts had the same set of Locators, which would make no sense.
So I think ILNP is even further from being an experimental protocol
than the three just mentioned. I am not suggesting that no effort be
made on it. I think it would be valuable and generally instructive
to attempt to make it work, with code and a test network. That would
test the veracity of some major critiques of CEE architectures in
general, and ILNP in particular:
1 - That neither ILNP or any other CEE architecture can work
with all, or probably any, existing IPv6 applications.
(No CEE architecture can work with IPv4 unless there are
upgrades to all routers, including DFZ routers, and
longer headers are used in all packets.)
2 - That the delays and that the extra packets will slow down
the establishment of most or all communications sessions
to an unacceptable degree.
3 - Mobility can't be done robustly and efficiently, with
sufficiently rapid response to the host getting a new
Locator.
We don't need detailed protocol definitions, running code or a test
network to know how badly these CEE architectures match the
constraints imposed by the need for widespread voluntary adoption:
http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
