On Mon, Jun 7, 2010 at 8:27 PM, RJ Atkinson <rja.li...@gmail.com> wrote:
>> Most likely, this would imply routing towards the specific
>> exit based on the packet's source locator in addition
>> to the destination locator.  This is not part of the base
>> ILNP spec as it exists today.
>
>> well, does it need to be?
>
> Good question.
>
Some thoughts on why it should be supported by ILNP, base or for future studies.

Here in the Nordic&Baltic region I have seen several enterprises that
are present in several countries been multi-homed in each country -
due to mixed reasons, e.g. you prefer to be attached at the local
exchange points to ensure top quality connectivity, due to historical
reasons caused by mergers etc.

The outcome is that there are a bunch of exit points, there could be
easily four to ten peering points and the internal routing becomes
complex. In case of slow performance at some ISP the enterprise needs
to tweak the routing policy (BGP) and it gets complicated - also the
performance issue is usually noticed when customers complains about
it, i.e. when the service level has decreased (when it is too late).

So if you could have concurrent multiple paths from the hosts towards
the customers via specific exists you gain the following
- when some ISP are performing badly the multipath transport protocol
takes care of the issue immediately, the service level will not suffer
- internal routing becomes less complex (guess it depends on the
policy-based-routing-by-shim-header solution, right)
- no longer multi-homing is needed per country, you can cut 50% of the
installed ISP connections/border routers and perform cross-country
multi-homing with the primary path at the domestic connection
- the border routers becomes less complex, also cheaper since the DFZ
should shrink
- operational costs goes down since multipath transport protocol fix
the temporary IPS performance issues by the endpoints themselves

So what the enterprise gain is a better service level for their
customers and a simplified internal routing architecture at a lower
cost than the current one - should catch the attention at the upper
management at the enterprises and we get this rolling :-)

I don't know about the enterprises in e.g. the U.S and other places,
how many peering points in average they have - so before rushing ahead
it could be worthwhile to investigate if the enterprises are
interested in this kind of approach or not.

-- patte
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

Reply via email to