[rrg] APT: Universal division line, between "the core" and all edges

[Robin Whittle <[e-mail]>]

Please see:

   CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper
   http://www.ietf.org/mail-archive/web/rrg/current/msg06009.html

and a follow-up message I just sent:

   http://www.ietf.org/mail-archive/web/rrg/current/msg06060.html

for my discussion of the 2008 paper by Lixia and colleagues which
formalised the Core-Edge Separation (CES) and Core-Edge Elimination
(CEE) terms.

I argue that these authors, many of whom devised APT, used the CES term
in part to describe their proposed separation (as in "Universal division
line, between") of core and edge *networks*, since this was a long-term
goal of APT.

Their "Core-Edge Separation" term also has a second and more generally
useful meaning - the separation of a new "scalable edge" subset of the
global unicast *address space* from what remains as the "core".

Separating *addresses* into two subsets is a totally different concept
from physically preventing the flow of packets between two classes of
*networks*.

APT aimed to do both.  LISP, Ivip and TRRP only aim to the the latter -
create the scalable "edge" subset of global unicast addresses, and have
ITRs and ETRs to do special handling of these packets, rather than
letting them be handled entirely by the ordinary routing system.

I believe this separation of *addresses* into two subsets is the useful
meaning of "Core-Edge Separation", since it applies to an important
class of scalable routing solution, including the LISP, APT, Ivip, TRRP,
TIDR and IRON-RANGER proposals.  (I have written that Six/One Router is
a CES architecture too, but I am not so sure - it is an unusual approach
which requires the global DNS provide different IP addresses for each
host than the host has itself.)

CES architectures retain the current two-level naming model of IPv4 and
IPv6.  I believe this naming model should be retained.  Many people
think it should be abandoned and both Internets (or at least the IPv6
Internet) converted to a "Locator/Identifier Separation" naming model,
in which Locator and Identifier roles are played by two separate
objects, each in a separate namespace.  (In today's naming model, both
roles are played by the IP address.)  I believe this would be a mistake,
for reasons outlined here:

  Today's "IP addr. = ID = Loc" naming model should be retained
  http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html

  CES & CEE are completely different (graphs)
  http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html



Hi Lixia and Noel,

In "Re: [rrg] AIS - goals and techniques", you wrote:

>> a basic question of whether one could draw a universal division line
>> between "the core" and all edges; one of the reasons we gave up APT is
>> because APT also had this model of divided world view. 
> 
> This sounds interesting - can you say a bit more about it?

APT had this goal, but in my view it was not necessary for achieving
scalable routing.

I think APT was a better approach to scalable routing than any version
of LISP.  The goal of "separation of *networks*" was a long-term aspect
of APT, but not of LISP, or Ivip - and probably not of any other CES
architecture.

So I don't think any problem with this absolute separation of traffic
between two types of *network* was a good reason to abandon APT as a
scalable routing solution.

APT, like LISP or Ivip, achieves scalable routing goals in direct
proportion to its adoption, assuming:

  1 - Each such CEE architecture supports packets sent from
      non-upgraded networks. This means:

      LISP: PTRs advertising what Dino recently called "coarse"
            prefixes in the DFZ.

      Ivip: DITRs advertising Mapped Address Blocks (MABs) in the
            DFZ.

      APT:  All the BRs of ISPs in an APT island advertising a
            prefix which covers one or more EID prefixes.  For
            IPv4, this means that if there are more than one
            EID prefixes per /24, then they all need to be used
            in the one APT island.  This restriction could be
            removed by linking all APT ISPs into a single island
            by joining their BGP-based flooding mapping distribution
            systems into a single global "island" by using tunnels
            as well as direct router-to-router links.

  2 - These "coarse prefixes" or MABs or whatever, each of which
      adds one prefix to the DFZ control plane, generally covering
      multiple end-user network prefixes.  For instance a single such
      prefix may contain many "edge prefixes" (micronets in Ivip, EID
      prefixes for LISP and APT), for a single end-user network or
      for many such networks.

      LISP, APT and Ivip are are all technically capable of this, but as
      far as I know only Ivip has this as an explicit goal, and includes
      suggestions for the types of business arrangement by which this
      would occur.

Then, the more the CES architecture is adopted, the more these two goals
are achieved:

  1 - Less use of PI space, as existing PI users either give up that
      space and adopt different SPI (Scalable PI - the Ivip term) "edge"
      address space, or convert their PI prefix to be managed by the CEE
      system as SPI "edge" space.

and/or

  2 - End user networks which never had PI space, being able to have
      portability, multihoming and inbound TE using the new SPI "edge"
      space.

I think the routing scaling problem could be substantially solved
without full adoption by all the end-user networks which want or need
portability, multihoming and TE.  If in 2020 there are still 100,000 or
so PI prefixes, and millions of networks are getting portability,
multihoming and inbound TE via the new scalable "edge" space, then the
scaling problem will still "solved" in my view, since the DFZ control
plane can probably cope with the 100,000 or so PI prefixes without too
much fuss.

Ivip does not need or aim for 100% adoption by the end-user networks
which need portability, multihoming and inbound TE - and as far as I
know, either does LISP.   I believe APT wouldn't need it either to be
highly effective solution to the routing scaling problem.  For all the
CES architectures, I think the more adoption the merrier.

CEE architectures, however, need to be 100% adopted (or very close to
100%) before the adoptors gain substantial benefits (being able to rely
on the system to provide portability, multihoming and inbound TE for all
their communications) and before there can be any substantial routing
scaling benefits.  This is  because until there is ~100% adoption
end-user networks can't give up their PI space until the CEE system
supports all their communications, and those without PI space don't get
all their communications supported.

~100% adoption for CEE means that all hosts - including those of ISPs
and the many networks which are happily using PA space today, and don't
need portability, multihoming or inbound TE - must adopt the new
arrangements.  CEE architectures involve host stack changes and in most
cases application changes (this is the steepest of all barriers to
adoption).


CES can solve 100% of the routing scaling problem by being adopted by
all the end-user networks which need portability, multihoming and
inbound TE - and ideally by having all ISPs install ITRs.  This is far
less than 100% adoption.  (To the extent there are ISPs without ITRs,
the adopting end-user networks need to pay someone to run PTRs or DITRs
to cover their prefixes.)

This adoption of the new kind of address space is only for this subset
of end-user networks which want or need portability etc.  There is no
need to alter the PA addressing arrangements of the vast number of
end-user networks, primarily DSL, HFC etc. home and SOHO users.  Nor is
there any need for ISP's own hosts to adopt the new kind of scalable PI
"edge" space.


APT, LISP or Ivip could, in theory, get to the 100% adoption which would
be required before it would be possible to implement the "Universal
division line" prevention of packets from edge networks reaching core
devices.  This would require these additional hosts and networks to
adopt the new scalable "edge" space exclusively:

   1 - All the end-user networks on PA space converting to the new
       CES-provided "edge" space.  This is completely unnecessary
       for achieving routing scalability, since these networks' use
       of PA space is entirely scalable.  This would involve all
       the mass market of ISP customers on DSL, HFC, wireless etc.
       services, who currently get an IPv4 address.

       This includes all hosts of hosting companies, government
       departments etc.

   2 - All other hosts, including those of ISPs and DNS servers.
       The ISP's hosts (and I guess many nameservers run by ISPs)
       do not contribute to the routing scaling problem either because
       they are on the space provided by the ISP's own prefixes, which
       are not part of the scaling problem.  (We accept the DFZ can and
       will cope with all ISP's prefixes.)

All that would be left in the "core" - the remainder of the global
unicast addresses which are left after all the above addresses have been
handled by the CES system as scalable "edge" addresses - is unused
addresses and the addresses of "routers" - such as some of the routers
of ISPs, including most or all of the addresses of DFZ routers, and all
the ETRs and ITRs (LISP, Ivip and APT) and all the Default Mappers (APT)
which need to be on "core" addresses.

If this was achieved, there would be no need for PTRs or DITRs, since
all ISPs would have adopted the CES architecture.

Then, theoretically, it would be possible to create, as Lixia wrote, a
"Universal division line, between 'the core' and all edges".

All communication between "edge" networks (all user networks, including
hosting companies, DSL customers etc.) would take place exclusively
through the CES system.  All ISP hosts which are to be accessed by
end-user hosts, including their nameservers, mail servers, web servers
etc. would also be on "edge" space and be using the CES system
exclusively.

This would go way beyond the needs of scalable routing - and I can't
imagine how or why such a thing would ever be encouraged or achieved.

Only then could the "core" devices - just the DFZ routers, and perhaps
any hosts which ISPs collectively decided should remain in the "core".
plus ITRs, ETRs etc - be physically separated from the "edge" networks.
 This would require that when any host in any "edge network", including
a large part of the ISP's networks, sent a packet addressed to a "core"
address, that there would be no path for it, due to the "core" prefixes
not being advertised in any "edge" network.

Then, in the "core", there would be two classes of prefixes advertised
in the DFZ:

   1 - Whatever "core" prefixes were in use, including those which
       contained the addresses of the DFZ routers, probably many or
       all ISP routers and all ITRs, ETRs and DMs.

   2 - The MAB (Ivip), "coarse" prefixes of LISP or whatever their
       equivalent is in APT.

Theoretically, then, from any "edge" host, it would be impossible to
send a packet to any IP address in the "core".  This includes all ITRs,
ETRs and at least the DFZ routers.

I think this could only work for APT.  I think this could work for LISP,
provided no ITR functions were implemented in sending hosts.  (All such
hosts would be on EID addresses.)

This could only work for Ivip if there were no ITR functions in sending
hosts.  "ITR functions in sending hosts" (ITFH) is an option with Ivip,
but is highly desirable in some settings such as hosting companies or
other server farms.  In the above "complete separation" scenario, ETRs
are on "core" addresses and all ITRs need to be able to send packets to
all ETRs.  If Ivip only used separate ITRs, and these were all on "core"
addresses, then the above prohibition could work.  But this would not be
possible if sending hosts were also acting as ITRs, since these hosts
are on the new SPI "edge" addresses.

 - Robin