Subject: Re: [rrg] ILNP q1: Scalability

From: RJ Atkinson <[email-masked]>
Date: Mon, 7 Jun 2010 13:27:57 -0400

> 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.  

I'm certainly happy to add some MAY language to the ILNP 
base spec about an originating node having multiple 
known Locator values indicating the node's preferred egress 
by thoughtful selection of the Source Locator value.

I am very reluctant to require routers to use Source
Locators as part of their forwarding/routing procedures,
as it adds complexity, is not fully backwards compatible
with installed IPv6 routers, and because this kind of
thing seems a lot like a differentiating feature rather
than a required basic capability.

> If the host puts a src-locator on the packet it creates 
> [then] it's up to the network/host folks to agree to 
> src-route or agree to get overwritten. 

In the end, routers along the forwarding path for any
IP (or ILNP) packet make a myriad of decisions based
on both global policy, originator decisions (e.g. which
destination to put into the packet if there are several),
and local policy (e.g. hot potato routing).

While an originating node gets some input into that
distributed computation/procedure, the node with the
packet at a moment in time inevitably has the ability
to make its own decision (some of which might result
in a packet taking a sub-optimal path or being lost).

> (Is the 'TE' at the whim of the host or the
> network? This sounds like shim6 discussions, to me)

Originator can indicate a preference, but originator
preference (in practice, no matter what any RFC says)
will not over-ride contrary local policy in some
router along-the-path as it forwards that packet.

Yours,

Ran

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 8 Jun 2010 21:38:31 +0300

>> well, does it need to be?
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

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 9 Jun 2010 09:09:33 -0400

On 08  Jun 2010, at 14:38 , Patrick Frejborg wrote:
> 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.

Interior routing doesn't have to be so complex, 
even with that many exterior peering points.

I certainly know of sites that have been handling
that range of exterior peers for more than 20 years,
without having unusual complexity within their 
interior routing.  

There must be some other reasons that the site you
describe has chosen to have complex interior routing.

> So if you could have concurrent multiple paths
> from the hosts towards the customers via specific exits ...

The issue of concurrent multiple paths to exist
an end site is not new.

Using ILNP does not make that issue any worse than today.
So this really is not an ILNP-unique issue.  Instead,
it is a separate issue, which is why I've moved this
discussion into its own thread.

The "Border Router Discovery Protocol" that Teco Boot 
is already working to standardise within the IETF is 
an interesting technology that appears able to help 
with these issues (for existing deployed IP networks, 
and for ILNP).   Whilst BRDP's origins are in the MANET world, 
its applicability/utility seem to be very much broader -- 
including totally fixed non-mobile/non-MANET environments.  
BRDP enables the interior of a site to have better information 
about the currently available set of upstream links/
site border routers.

BRDP has been presented at a past Routing RG meeting,
and is also discussed in RFC-5887 on "Renumbering Still 
Needs Work". 

Google found this presentation to the Routing RG:  
<http://www.inf-net.nl/IETF73%20-%20BRDP%20Based%20Routing%20-%20RRG.pdf>

(NB: I would not be surprised if BRDP has evolved 
since that briefing was created.)

Cheers,

Ran

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 Jun 2010 11:11:21 -0700

Ran, Patrick,

IRON also has a well-known solution for multi-homed sites.
It is based on the mechanisms of VET, which also originated
from earlier works in MANETs but have been found to apply
to enterprise networks (or sites) of all shapes and sizes.

Thanks - Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
> Sent: Wednesday, June 09, 2010 6:10 AM
> To: Patrick Frejborg
> Cc: IRTF Routing RG
> Subject: Re: [rrg] multi-homed site issues
> 
> 
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg