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

[Robin Whittle <[e-mail]>]

Hi Fred,

In "Re: [rrg] Recommendation and what happens next", you wrote:

> Hi Robin,
> 
> About IRON-RANGER below:

...

>> That leaves four CES architectures:
>>
>>    IRON-RANGER
>>    Ivip
>>    LISP
>>    TIDR
>>
>> TIDR can't solve the routing scaling problem because its "mapping" is
>> almost identical to advertising individual end-user network prefixes
>> in the DFZ.  I have argued that IRON-RANGER is not yet sufficiently
>> developed to understand its security and scaling challenges - and
> 
> The points on security and scaling have been addressed
> in my latest rebuttal; see:
> 
> http://www.ietf.org/mail-archive/web/rrg/current/msg06158.html

I don't understand the mechanisms by which potentially very large
numbers of IRON routers repeatedly and continually register with
potentially multiple VP routers.  These IRON routers could be
anywhere and so could the VP routers.  In that message, the most I
can discern about this mechanism is:

   IRON routers lease portions of their VPs as Provider
   Independent (PI) prefixes for customer equipment (CEs),
   thereby creating a sustaining business model. CEs that lease
   PI prefixes propagate address mapping(s) throughout their
   attached RANGER networks and up to VP-owning IRON router(s)
   through periodic transmission of "bubbles" with authenticating
   and PI prefix information. Routers in RANGER networks and IRON
   routers that receive and forward the bubbles securely install
   PI prefixes in their FIBs, but do not inject them into the RIB.

I have a rough idea of what you are trying to achieve with this
mechanism, but I have no idea what the mechanism is - "bubbles"
doesn't give me any understanding of exactly how the IRON routers
would do this securely.  Only when I understand exactly how they
would do this could I estimate the scaling and security problems
which are no-doubt involved.


>> there's no apparent method of supporting packets sent from
>> non-upgraded networks.
> 
> Non-upgraded IPv4 networks will continue to work as they
> always have. Do you mean non-upgraded IPv6 networks?

I mean when you start installing IRON routers, these will collect
packets addressed to "edge" addresses (or whatever the new subset of
"EID" space is called in I-R) from the ISP networks they are
installed in.  Packets sent by hosts in those networks will be
handled according to I-R principles and the recipient networks of
those packets will get the benefits (portability, multihoming and
inbound TE) for those packets.

But what of packets sent from hosts without IRON routers?  AFAIK,
there's no equivalent in I-R to Ivip's DITRs or LISP's PTRs.


> Assuming the latter, let's consider that today we have
> two separate BGP instances - the IPv4 BGP instance and
> the IPv6 BGP instance. The IPv6 BGP instance carries a
> set of IPv6 prefixes (e.g., 2001:: derivatives) that are
> routed in the IPv6 Internet in the "traditional" sense.
> What IRON-RANGER is doing is essentially creating a
> *third* BGP instance - one that carries a new set of
> IPv6 Virtual Prefixes (VPs) that are distinct from the
> prefixes carried in the traditional IPv6 BGP instance.
> 
> Due to routing scaling issues, IRON-RANGER expects that
> growth of this new third BGP instance will flourish while
> growth of the traditional IPv6 BGP instance will level
> off. In order to support what I think you mean by
> non-upgraded networks then, it only requires that IPv6
> routers connected to the IRON also participate in the
> traditional IPv6 BGP instance. For that matter, not all
> IRON routers need to participate, but at least some must. 
> 
>> As far as I know, there have been no
>> substantial counter-arguments to these critiques.
> 
> Do the above points address your concerns?

It is 5AM here, and I can't clearly translate what you wrote into an
answer to the concern I mentioned above.  But that doesn't mean it
doesn't address it.

> Hmm, maybe these two IPv6 BGP instances I alluded to don't
> even need to be kept separate - as long as Virtual Prefixes
> can be kept distinct from non-virtual ones. This I think is
> the key point, and would greatly reduce the complexity.

I am definitely not going to think about this until I get some sleep!

  - Robin