[RRG] draft-irtf-rrg-design-goals-01

[Robin Whittle <rw@firstpr.com.au>]

Here are some thoughts on:

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01

I agree with what I think is the thrust of this, but have some
suggestions about how it might be improved, including perhaps with
a specific focus on "portability".

I wasn't involved in previous discussions about this, so maybe
these points have been covered before.


Regarding the inter-domain routing system:

> Thus, the first required goal is to provide significant
> improvement to the scalability of the control plane.

This could be interpreted as meaning that the BGP system itself
("the control plane") - meaning the CPUs, firmware and BGP
messages, rather than the FIB part of the routers - needs to cope
with more of whatever is currently challenging it: number of
advertised routes, number of transit and border routers, amount of
traffic or responsiveness to changed advertisements.

I don't see LISP or Ivip as being part of the "control plane" of
the inter-domain routing system, but if a scheme such as this was
successful, then it would greatly reduce the pressure which drives
most of the growth in the global BGP routing table, by making
single IP addresses and ranges of IP addresses (prefixes and other
sets) portable and so suitable for multihoming and moving to
another ISP without involving BPG.

Unless LISP or Ivip are regarded as part of "the control plane of
the inter-domain routing system", they could solve the biggest
problems we face without formally satisfying this requirement.

I think of LISP or Ivip as rather separate from the routing
system, but I guess that is just the current routing system.  They
don't require any direct interface to BGP, other than the behavior
of routers advertising or not advertising certain prefixes.  I
guess that if either was adopted, it would become part of basic
infrastructure for getting packets to destinations, so we would
then have a broader definition of the routing system to include
LISP or Ivip.


The definition of traffic engineering seems rather tied to the
only current way of doing it: imposing restrictions on how the BGP
routers select their best paths.

LISP explicitly achieves TE in a way which doesn't quite match the
definition: "directing traffic along paths other than those that
would be computed by normal IGP/EGP routing." because the BGP
routers continue directing traffic as normal.  (Ivip could do some
inbound TE by allowing rapid, low-cost, remapping of individual IP
addresses to different ETRs, also without burdening the BGP system.)

Maybe there could be a more functional definition of TE, such as
"the ability to control inbound or outbound traffic flow over
multiple links for purposes such as load balancing, using the most
cost-effective provider, ensuring certain levels of packet loss
are not exceeded for certain streams of traffic etc. - all as
traffic patterns change over seconds, minutes and hours".

Then, any proposal which achieves this will pass muster even if it
doesn't technically match the definition.  I am being pernickety
here, but for instance, BGP wouldn't normally compute any path for
packets addressed to a LISP (2+) EID because there is no
advertised prefix for them.  (With Ivip there is, but that prefix
has no single home on the Net.)


I would have thought that the goal of more scalable multihoming
would be "Required", since this mainly what is driving the biggest
single problem - the growth in the global BGP routing table.


I think the definition of mobility is good.  While there is
mention of existing approaches, including using a "home-agent"
which is an implicitly fixed topological location and has the
mobile node's actual address, and so often leads to longer paths
(stretch), the final goal is completely open ended about how
mobility can be made more scalable and efficient.


I think the "simplified renumbering" section is basically good.
However it ends with a goal which doesn't mention renumbering.

I think any architectural change which makes it easy to renumber
networks is desirable, but since I can't imagine any solution
which will ever make it acceptably easy for every or even most
substantial end-users to renumber their network, I think the more
important goal is "portability".

I think the goal of portability of one IP address or a range of
addresses is the central goal, but it is not stated explicitly as
such in this I-D.

The final sentence of "Simplified renumbering" is a valid goal,
which could easily be achieved with portability, rather than ease
of renumbering.  If it was rewritten from:

  It is strongly desired that a new architecture allow end-sites
  to change providers with significantly less disruption.

to:

  It is strongly desired that a new architecture allow end-sites
  to renumber their network with significantly less disruption.

then this would be a good ending for the section on renumbering.

The section on "Decoupling location and identification" also
implies, to me, "Portability", but without actually saying so.

This section initially uses "desired" and then "required",
regarding decoupling host identification and location:

> it is desired that a solution separate the host location
> information namespace from the identification namespace.

> 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) are required . . .

The "second decoupling" is, I think the earlier mention of:

> the decoupling of end-site addresses from globally routable
> prefixes

I could take this text:

 1 - the decoupling of host location and identification
     information

 2 - the decoupling of end-site addresses from globally routable
     prefixes

       (This is stated as one of the possible approaches
        to creating a "scalable global routing system".)


and say that this really means portability in two scenarios:

 1 - The ability to deliver packets addressed to one IP address
     (being used as a host identifier) to any provider or
     AS-end-user network, without involving the BGP system.

 2 - The ability to deliver packets addressed to a range of IP
     address, including especially a prefix, (being used as
     identifiers for multiple hosts or as locators for some
     scheme in which host identifiers are made portable) to any
     provider or  AS-end-user network, without involving the BGP
     system.

I think this really means just being able to make one IP address
or a bunch of them appear at any edge network, without involving
or burdening BGP (or perhaps while involving BGP, but in a much
more scalable way than is currently possible).

So to me, this is simply "portability" of one address or a prefix
of them, with the latter implying a single management structure
which doesn't depend at all on the hosts which use the addresses
in that prefix.

Questions about portability include:

1 - A single IP address, a prefix of them or an arbitrary range
    of them?

2 - Does the actual host(s) on these addresses need to be involved
    in the management of their portability.

3 - Does it work for both IPv4 and IPv6?

4 - Can the address(es) which are portable themselves be used
    as locators for a scheme which makes other addresses
    portable?

LISP and Ivip handle single IP addresses and prefixes with equal
ease.  Maybe Ivip might be more flexible than LISP 2+ for
arbitrary, non-prefix, ranges of IP addresses.

The host(s) could be involved in the management, but does not need
to be, whereas with SHIM6, which gives a very limited form of
portability (from wherever the host initially appears to one or
more other IP addresses, without breaking ongoing sessions), the
host definitely does need to be involved in the management.


If the network which you need to be portable includes the
addresses of ETRs, then you can't use LISP or Ivip to make this
network portable - you still need to have PI space and burden the
BGP system with an extra route.

So all ETRs must be located in a real, physical, conventional
provider or AS-end-user network with PI space directly reachable
via BGP.

Any host or end-user edge network (1 to any number of IP
addresses, whatever the purpose) can then be made portable via
LISP or Ivip provided:

1 - The address(es) are within the LISP or Ivip system (and there
    could be various administrative arrangements for this) in a
    way which is secure and lasting enough for the end-user.

2 - The address or network which is thus made portable can't be
    used to host ETRs (unless via some tunnel to an ordinary
    BGP-reachable network).


I think the "portability" is the key.

With fast portability, you have mobile.

  BGP can't do this, but LISP or Ivip could, though not
  necessarily fast enough for glitch-free VoIP communications.

With fast or slow portability, you don't need to renumber - so you
have the ability to take an IP address or a whole range or
prefixes of addresses to another ETR-equipped ISP, without having
to worry about renumbering.

  BGP can do slow to moderate speed portability, and enable the
  portable network to have its own ITRs and therefore have hosts
  or other networks which use LISP/Ivip for their portability.
  But this should only be used for the networks of providers or of
  some end-users who for some reason can't satisfy their needs
  with LISP/Ivip-mapped addresses.

  LISP/Ivip can do slow, moderate or maybe fast portability - but
  not if the portable network needs to have ETRs etc.

With fast portability, if you have two or more links to two
different ISPs then you have multihoming.

  As above: if the network you want to multihome needs to have
  its own ETRs, then you can't use LISP or Ivip - you must
  continue to use BGP.  LISP or Ivip can probably switch
  traffic to the new ETR faster than BGP, and doesn't involve
  getting BGP expertise, a whole (probably wasteful) prefix of
  PI space etc.


So in setting goals, I think there could be a distinction between
"portability, multihoming and/or mobility" for addresses in terms of:

1 - Whether the system works with a single control construct for
    prefixes - which makes it suitable for managing an entire
    network reliably (rather than relying on each host on the
    addresses in question to do something).

2 - Whether the space which is made portable etc. is expected
    to have ETRs.

3 - The speed with which the portability can be achieved, and
    how much burden each change places on the new global
    system.

4 - Whether the portable addresses need to be used for ETRs
    or some critical infrastructure which shouldn't rely on
    LISP/Ivip.


Returning to "Decoupling location and identification" and
"separate the host location information namespace from the
identification namespace.":

Both LISP 2+ and Ivip split the existing IP address space into
addresses of two classes:

1 - Prefixes of addresses for which any packet whose DA matches
    the prefix will always be encapsulated by an ITR and tunneled
    to an ETR somewhere (or dropped, if that is what the database
    says to do for this EID/DID (LISP/Ivip) address.  Therefore,
    these addresses, singly, in arbitrary sets or in prefixes, are
    portable to any provider or AS-end-user network with an ETR
    which will support the end user whose addresses these are.

    These addresses shouldn't be used for certain items of
    critical infrastructure and can't be used for ETRs.

    (Maybe they can't be used for ITRs in LISP, but Ivip
     ITRs can be on Ivip-mapped addresses.)

2 - The remainder of the address space, on which all LISP ITRs and
    all LISP/Ivip ETRs must be located - and of course which can
    still be used for all other purposes.

I don't regard this as "two separate namespaces".  Every host on
the Net can ignore the distinction and just regard them as
"IP addresses".  Its just the global system of ITRs - which
hopefully catches every packet addressed to some address in the
first class - which always needs distinguishes between these two
classes of address.

  - Robin      http://www.firstpr.com.au/ip/ivip/





--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg