Re: [rrg] IRON-RANGER scalability and support for packets from non-upgraded networks

[Robin Whittle <[e-mail]>]

Hi Fred,

Thanks for this:

> In catch-up mode, your suggestion of a need for more
> discussion of scaling properties is a good one, and
> something I think that can be accommodated in the
> next IRON update.

Also, in "Re: [rrg] Why won't supporters of Loc/ID Separation ..."
you wrote:

> IRON-RANGER used to speak of using IPv6 neighbour discovery
> as the means for locator liveness testing, dissemination
> of routing information, secure redirection, etc. However,
> the VET and SEAL mechanisms are being revised to instead
> use a different mechanism called the SEAL Control Message
> Protocol (SCMP) for tunnel endpoint negotiations that occur
> *within* the tunnel sublayer and are therefore not visible
> to either the outer IP protocol nor the inner network layer
> protocol. Hence, the inner network layer protocol could be
> anything, including IPv4, IPv6, OSI CLNP, or any other network
> layer protocol that is eligible for encapsulation in IP.

OK.  I hope you will be able to explain these things not just in
terms of high-level concepts, but to give examples of how the whole
thing would actually work on a large scale.

For instance, how many IRON routers are there in an IPv4 I-R system,
and how many individual EID prefixes?  Then, how do these IRON
routers, for each of these EID prefixes continually and repeatedly (I
guess every 10 minutes or less) securely inform a given number of VP
routers they are the router, or one of the routers, to which packets
matching a given EID prefix should be tunneled.  Since there could be
multiple VP routers for a given VP, and the IRON routers don't and (I
think) can't know where they are, how does this process work securely
and scalably?

If the VP routers act like DITRs or PTRs by advertising their VP in
the DFZ, then in order to make them work well in this respect - to
generally minimise the extra path length taken to and from them
compared to the path from the sending host to the proper IRON router
- I think you need at least a dozen of them.   This directly drives
the scaling problems in the process just mentioned where the IRON
routers continually register each of their EID prefixes with the
dozen or so VP routers which cover that EID prefix.

Your IDs tend to be very high level and tend to specify external RFCs
for how you do important functions in I-R.  Yet those RFCs say
nothing about I-R itself.  I think your I-Ds generally need more
material telling the reader specifically how you use these processes
in I-R.   Then, for each such process, have a detailed discussion
with real worst-case numbers to show that it is scalable at every
level for some worst-case numbers of EID prefixes, IRON routers etc.
- as well as secure against various kinds of attack.


>>   8 - Apart from Ivip's Modified Header Forwarding arrangements,
>>       CES architectures involve encapsulation for tunneling
>>       packets from ITRs to ETRs (IRON-RANGER doesn't have ITRs and
>>       ETRs, but it still requires encapsulated tunneling).  There
>>       are some problems with this - but they do not appear to be
>>       prohibitive.
>
> IRON-RANGER calls them as ITEs/ETEs because it is possible
> to also configure a tunnel endpoint on a host and not just
> on routers. In terms of routers, the IRON-RANGER ITE/ETE
> are exactly equivalent to what the other proposals are
> calling as ITR/ETR.

OK.  In Ivip the sending host can have in "ITR" function - though it
is not a router and this "ITR" function doesn't advertise routes to
the MABs (Mapped Address Blocks) inside the host.  It does however
only handle packets sent by the host's stack which have destination
addresses matching any of the MABs.  I am sticking with "ITR" and
"ETR" in Ivip, to remain compatible with LISP - and because I think
they are easier to pronounce than "ITE" and "ETE".

  - Robin