Short version: I think Toni is asking some important high level
questions in a constructive manner.
I try to relate the answers to these questions to
the major bodies of opinion I think exist amongst
RRG participants.
Hi Toni,
In msg07402, you wrote in part:
> Ah, I see why the current recommendation "reflects the decision of
> the co-chairs", not the consesus of the group.
Yes, but I and others support the publication, as an RFC, of
draft-irtf-rrg-recommendation-14 as a whole, with its summaries,
critiques, counterpoints and chairs' recommendation - in my case with
a note about problems with how ILNP is represented (msg07357).
> How about the chair
> checking the consensus on a set of documents, of which each
> contains the phrase "virtually all Routing RG outputs are
> considered controversial"?
I support the publication as RFCs of the ILNP I-Ds, but not because I
support ILNP or consider it uncontroversial.
> I am provoking the resolution of controversial issues that have key
> effects upon the entire architecture.
>
> Join.
I understand you are asking a series of high-level questions:
msg07356 [A] Consensus on identity/location separation
Adopt Locator / Identity Separation vs. retaining
existing overloading Locator = Identifier = IP address.
msg07379 [B] Consensus on node reference
Change the routing/addressing system to refer to nodes
rather than (as present) specific interfaces of a node.
msg07400 [C] Consensus on inter/intra-domain routing separation
Have interdomain routers concern themselves with ASNs
primarily, so they each figure out which of their
interfaces should get packets addressed to any of the
prefixes an AS advertises - as opposed to the current
BGP arrangement of ignoring the ASN at the end of
a route and forwarding packets according to their
prefix, to the one or more border routers which
advertise this prefix.
I think these are important questions and I tried to answer them
constructively.
I think there are three broad bodies of opinion in the RRG - not
counting those who are undecided:
1 - Keep the existing overloaded arrangements and solve the
routing scaling problem by adding a CES (Core Edge
Separation) architectural enhancement: LISP, Ivip, TIDR or
IRON.
This retains all existing host functions and protocols
unchanged, including the practice of the IP address
specifying (as an Identifier and Locator) a specific
interface of a node, rather than the node itself.
[A] LOC/ID? No.
[B] Node instead of interface? No.
[C] Route on ASN rather than prefix? No.
Change host protocols? No.
Change host stacks or apps? No.
Add work, delays etc. to hosts? No.
Add complexity to routing system? Yes.
2 - Keep the routing system relatively unchanged, and solve
the routing scaling problem with new protocols and
functionality in all nodes, using the Locator / Identifier
Separation (Core Edge Elimination CEE) approach, such as
ILNP, Name Based Sockets, RANGI or GLI-Split.
In these architectures, an Identifier refers to a node
(host) and each node has one or more Locators, which are in
practice IP addresses (IPv6 in all cases except ILNPv4,
which is not practical since it requires upgrades to all
IPv4 BGP routers).
I think this involves new application protocols and adoption
of IPv6 as a basis. This is certainly the case for Name
Based Sockets, and I argue that ILNP needs applications to be
rewritten too. No-one has shown how ILNP can work with
existing applications. I think the problems I encountered
trying to figure out how ILNP would work with existing
applications would also apply to RANGI, but the RANGI
designers say this is not the case. I intend to discuss
this more.
[A] LOC/ID? Yes.
[B] Node instead of interface? Yes.
[C] Route on ASN rather than prefix? No.
Change host protocols? Yes.
Change host stacks or apps? Stacks and apps
(though ILNP and RANGI
supposedly work with
existing IPv6 apps)
Add work, delays etc. to hosts? Yes.
Add complexity to routing system? No.
3 - Replace the BGP interdomain routing system with something
which uses different algorithms for each router to share
information and decide how to route packets, either
according to the prefix their destination address matches,
or perhaps according to the ASN which advertises that prefix.
These are TARA (draft-hummel-tara-00) which concerns geographic
routing (I have partially read it and intend to comment on it)
and the Hyperbolic Mapping proposal (papers in a Nature
Communications and Physical Review E arxiv.org/abs/1006.5169).
Like the CES proposals, I think these proposals involve no
changes to host protocols, stacks or applications - and no new
burdens on any hosts.
(I think these are both completely impractical since they do
not enable routers to serve the needs of networks, and because
there's no way of introducing these changes. I think there is
little or no support for them beyond the proponents, but at
least they have been described and discussed - and they are
completely different from the CES and CEE approaches.)
[A] LOC/ID? No.
[B] Node instead of interface? No.
[C] Route on ASN rather than prefix? Maybe?
Change host protocols? No.
Change host stacks or apps? No.
Add work, delays etc. to hosts? No.
Add complexity to routing system? ...
Supposedly simplify it compared to what a BGP-based
system would need to do in order to achieve the
same results - but I think neither could work.
Another approach might be to soup up BGP and/or BGP routers - but I
don't think anyone seriously suggests this will provide the
multihoming, TE, portability and mobility we need.
I think that outside the RRG, some or many folks may think there's
no real problem that can't be handled by BGP routers improving their
capabilities in the years to come (Moore's Law etc.) and so coping OK
with continued growth in the number of advertised prefixes. However,
I think this ignores that fact that the current arrangements fail to
provide multihoming, portability and TE for many networks which want
and need it - and can't provide global mobility.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
