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

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

hi all,

i've been following this thread for several days, and i have some comments (part 1) as
well as an approach (part 2) towards resolving some operational issues with multi-homed
hosts.  i hope i can provide a different perspective by offering some representation from
the non-isp, non-vendor community.

part 1:

with regards to transport session continuity, a long term goal in the form of SCTP or a
similar more secure transport protocols seems neccessary.  but for now, people will
work-in application level recovery if they really need it.  that's what the smart ones do
now, especially since even current ipv4 multi-homing practices don't guarantee protection
from all failure modes.  if a developer has to write an application that is
misson-critical, s/he's definitely going to have to figure out how to make it recover if
an interface, network, system or datacenter fails.  people who provide mission critical
applications are willing to pay a price to make sure their applications recover regardless
of failure mode (either by operational procedures or automatically).

for applications that absolutely cannot accept discontinuity for established layer-7 try
this: connect using SSL transport, create and pass a temporary layer-7 session identifier
with an "in-active lifetime" (say one minute),.. and if your SSL transport session gets
disconnected, both ends maintain state for that layer-7 session for one minute,
re-establish a new SSL transport connection within one minute, send your layer-7 session
key and resume layer-7 session.  or wait for SCTP or a better-than-SCTP protocol.  or face
the fact that there are no layer-3 guarantees today so don't expect them tomorrow.  (this
is a half baked)

i believe that, if the v6 TCP stack would provide enhanced options to allow a developer to
ask the stack to "from the list of addresses for a name try an address then skip to the
next address if there is a failure to connect after 3 attempts spaced at 10 second
intervals or if a destination unreachable is received, etc and repeat till end of list" it
may make it easier on developers to deal with multiple addresses.  i.e. a configurable
auto-select and connect call.  something like this would allow those who are familiar with
how the net works to provide a foundation for others to stand on.  providing a standard
interface across platforms would be a bonus.  functionality like this available "by
default" in every system may be sufficient to satisfy those 11,000 sites that announce
their prefixes into the IPv4 DFZ such that they instead announce multiple addresses per
host to the DNS.

I'm much more concerned about the operations aspect of multi-homed hosts.  As has been
pointed out before, the current multi-homing makes the life of ISPs much easier, but it
makes the life of certain other organizations no easier.  in the end the internet may have
to carry less routes than a very large organization.  the state of the internet routing
table is critical to those who have wares to sell to the general public (like
connectivity, merchandise, nude pictures, etc), but the internet protocol is also heavily
used by those who interconnect privately as well.  i.e. operations is critical to all -
not just ISPs.



part 2:  - another quarter baked idea

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 address

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 (4) but
without any IBGP optimizations.

(8) traffic sent to site-external address would work as in (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

p.s. sorry about the run-on sentences.



% -----Original Message-----
% From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]On
% Behalf Of Craig A. Huegen
% Sent: Friday, November 01, 2002 12:04 PM
% To: J. Noel Chiappa
% Cc: multi6@ops.ietf.org
% Subject: RE: PI/metro/geo [Re: The state of IPv6 multihoming
% development]
%
%
% On Fri, 1 Nov 2002, J. Noel Chiappa wrote:
%
% >     > operational issues in the edge enterprise space favor provider
% >     > independence for maximum flexibility.
% >
% > No doubt operational issues in the edge enterprise space would favor
% > perpetual motion machines - if they existed.
%
% As would operational issues in the ISP space.  Can we please quit the
% bickering?
%
% The point that Tony H. is trying to make (I think, correct me if I'm
% wrong here) is that the multi-PA solution makes life very easy for ISP's
% while throwing all of the operational issues of supporting such a solution
% on the end-sites.
%
% As an operator of an enterprise network with tens of thousands of
% segments, I fully agree with that statement.  Many other enterprises I've
% spoken to also concur with that statement, and are holding back on IPv6
% deployment for that reason.
%
% With that said, let's find some solutions.  I also agree with the idea of
% separating router goop from identities; however, I also am a pragmatist
% and am concerned with the existing applications that would break with
% this.
%
% /cah
%
% ---
% Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
% IT Transport, Network Technology & Design           ||        ||
% Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
% San Jose, CA  95134, (408) 526-8104                ||||      ||||
% email: chuegen@cisco.com       CCIE #2100      ..:||||||:..:||||||:..
%
%
%