RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

["Aldrin Isaac" <aisaac@bloomberg.com>]

Hi Michel,

% From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us]
%
% > or face the fact that there are no layer-3 guarantees
% > today so don't expect them tomorrow. (this is a half baked)
%
% This is not baked at all. There are some layer-3 only protocols

sorry i was referring to IP.  currently, higher-layer protocols add
reliability and all the other good stuff.  current multihoming
practices (announcing prefixes to the internet) try to provide
recovery at the IP-layer, the time-to-recovery of which widely varies
depending on the nature of the outage and it's relationship to one's
site.  what should one consider an acceptable time-to-recover?  this
varies greatly on the kind of application one is working with.  this
is what i meant when i said, there really are no layer-3 guarantees on
the internet today.

% currently designed that guarantee survivability of open sessions.
%
% Regarding your "part 2:  - another quarter baked idea", this sounds
% interesting at the first read, is there a draft of this?

i don't have a draft since i am not a protocol engineer.  i do,
however, design and operate a network with private connections to over
20000 other companies and therefore have a keen interest in the
operational impact of whatever conclusions are drawn up here.  i
believe that site-exit discovery solutions have been proposed for this
or other reasons in the past (i know something i read somewhere
inspired me to present this) and i thought it may be useful to put the
concept on the table.

%
%

-- aldrin


once again - with word-wrap at 70 characters. :)

in order to simplify the operations of routing multi-homed hosts, i
have been thinking about an approach that may satisfy the operations
needs of some of us.  this approach is geared for enterprises.

this approach:
(1) eliminates requiring having to support multi-interface hosts as a
means of site-exit backup
(2) eliminates the advertisement of prefixes
(3) reduces the number of routes to manage inside the site
(4) avoids having to do source-based forwarding to the appropriate
site exit in order to avoid having ISPs drop packets where the source
address prefix doesn't belong to them.
(5) simplifies the life of private network providers by eliminating
the requirement that you must provide transit to the DFZ to get a
global-prefix.
(6) ??
[obviously most of the above imply one another.]

it appears that this appoach will not reduce the security or
resilience of connections that we can have today.

the short version of the approach is as follows:

assume that a site:

(1) uses site-border and internal routers that are capable of
intra-site routing using only the SLA portion of the IPv6 destination
address.  this obviously means a max of 2^16 subnets per site.

assume hosts in that site:

(2) have one site-local or non-routable globally-unique address per
interface

for outgoing connections:

(3) host performs a "forward site-exit-discovery" for site-external
destinations.  the forward site-exit-discovery response would return
<1> a prefix that matches the site-external destination address <2>
AND a global-prefix (source-prefix) associated to that site-exit +
next-hop ISP <3> AND a reachable anycast or unicast site-local address
of that site-exit (site-border) router.

NOTE: the site-exit router could also be configured to <1> return a
"::/0" destination-prefix along with the global-prefix and site-exit
address, i.e. a "default route" associated to the global-prefix <2> or
if the router is running an EGP, the destination-prefix could be the
longest match prefix for the destination address <3> or if multiple
site-exit routers peer using IBGP, than the site-exit router can
additionally return the site-exit address and the global-prefix of the
best site-exit (this may require some new MBGP knobs).

(4) the host would insert this source-prefix, destination-prefix and
site-exit address in a special "site-external" routing table.  these
route entries are special route entries used to allow the host to
select the appropriate global source-prefix to communicate with a
site-external address and to source-route via the appropriate
site-exit.  site-exit discovery would be repeated if any destination
associated to that source-destination-prefix pair becomes unreachable.

(5) for the initial packet sent to a site-external destination, use
the source-prefix associated to  the best matching site-external
destination route entry.  packets sent to the site-external
destination would include a routing header where the associated
site-exit address would be the first destination of the packets.  all
connections that are "in-progress" would be routed based on
site-external route entries that match both source and destination
prefixes, i.e. only the initial localhost-originated packet can route
purely by best matching destination-prefix.  the host could probably
create a temporary pseudo-interface with that source-prefix for the
duration of all connections that use it.

for incoming connections:

(6) accept any prefix so long as the SLA and interface portion belong
to the host.  the host could also create a temporary psuedo-interface
to handle the connection.

(7) perform a "reverse site-exit-discovery" against the incoming
global-prefix (i.e. destination address field of incoming packet) to
discover what the ingress site-exit of the incoming packet was.  the
site-exit-router would return the same results as in (3) but without
any IBGP optimizations.

(8) traffic sent to site-external address would work as in (4) and (5)

additionally:

(9) the site-exit-discovery and "site-external" routing table approach
can be used for both temporary global "pseudo-interfaces" described
above as well as standard global interfaces that are configured today
using router-advertisements.

this approach OBVIOUSLY implies that the site-border (site-exit)
routers are TRUSTED and only attract traffic with global-prefixes that
have been assigned to the site.  most enterprises fit this mold.

i'm sure this approach is chock-full-of-holes since it's a half-baked
idea.  but i figure it may give a fresh perspective to some of the
problems.

-- aldrin