I am responding to Fred about the text of the draft and to Joel about
whether the forthcoming RRG Design Goals RFC is intended as an
historical document.
Hi Fred,
You said "OK" to this text:
> Caution must be taken here to clearly distinguish the decoupling of
> host location and identification information, and the decoupling of
> end-site addresses from globally routable prefixes; the latter has
> been proposed as one of the approaches to a scalable routing
> architecture. Solutions to both problems, i.e. (1) the decoupling of
> host location and identification information and (2) a scalable
> global routing system (whose solution may, or may not, depend on the
> second decoupling)
>
> FLT >> OK.
but this phrase is meaningless now:
the decoupling of end-site addresses from globally routable
prefixes
I am sure that at the time this was written, April 2007, that this was
intended to describe LISP and any other similar architecture. At the
time, LISP had no Proxy ITRs (PITRs, PTRs) and so the DFZ routing
table had no prefix which covered the addresses used by EUNs (end-user
networks). So the phrase had its intended meaning when it was first
written.
In December 2007, LISP adopted PTRs, which advertise one or more
large (short number of fixed bits) prefixes each of which covers the
address space used by multiple EUNs. This means that one or more of
these PTRs will attract packets sent to these EUNs from a network
without ITRs, and will tunnel them to the correct ETR. I introduced
the same concept in June 2007 for Ivip, with the intention it also be
applied to LISP.
The above phrase doesn't apply to any architecture I can think of,
since Ivip, LISP and I assume IRON ensure that all of the new scalable
class of EUN address space is advertised in the DFZ so packets from
non-upgraded networks will be tunneled to the EUNs.
> are required and it is required that their
> solutions are compatible with each other.
>
> FLT >> Not OK. I think Robin is right that we will not see a
> FLT >> combination of disparate solutions such as ILNP+IRON both
> FLT >> being deployed in conjunction. What is quite possible, however,
> FLT >> is a combination of IRON+HIP since HIP is only instrumenting
> FLT >> the hosts and can be used perfectly well over an IRON network.
> FLT >> Still, why would such a combination be *required* when it may
> FLT >> not actually even be desireable in all cases?
I entirely agree.
> FLT >> Suggested change
> FLT >> is to replace the above phrase with the phrase: "are possible."
I am not sure what you are suggesting, but the requirement of Loc/ID
Separation is wrong, in my view, as is any requirement that the chosen
architecture be compatible with Loc/ID Separation.
> Ideally, such mechanisms should completely decouple mobility from
> routing.
>
> FLT >> Not OK. It should be perfectly OK for mobility to interact
> FLT >> with the routing system as long as the routing churn is
> FLT >> localized and minimized. Strike this sentence.
I agree. "Routing" is never defined, but it arguably includes not
just the existing routing system but whatever ITRs, ETRs, DITRs/PTRs
and TTRs are added by Ivip or LISP, or whatever devices in IRON
provide comparable functions.
The draft seems to be based on the assumption that the routing system
can never scale, even by adding something like LISP, IRON or Ivip to
it - and/or that adding anything to it is inherently undesirable.
Therefore, it requires Loc/ID Separation: making the hosts do all the
extra work for multihoming, inbound TE, portability (of Identifiers)
and mobility.
Hi Joel,
You wrote, in part:
> But the document is not the goals for some new set of work. It
> is the goals we roughly agreed on early on. The purpose of
> publication is for the historical record, not to drive some new
> set of work.
I disagree with your assertion that this forthcoming RRG Design Goals
RFC is intended as some kind of historical document - a record of what
we were thinking. There's nothing about this in the draft and I don't
recall Tony stating anything to this effect.
The fact that the design goals draft was not updated or widely
discussed between July 2007 and November 2010 doesn't mean that most
or all RRG participants accepted the draft -00 of July 2007 as their
design goals.
I responded to the draft on the basis that it should be the best set
of design goals the RRG can produce in late 2010.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
