Subject: Re: [rrg] multi-homed site issues

From: Patrick Frejborg <[email-masked]>
Date: Fri, 2 Jul 2010 14:45:25 +0300

Ran, Fred,

sorry for taking so long time to come back to this topic, day work
"interference" and I needed to update my I-D to make it clearer on
this topic ...

Comments in-line

On Wed, Jun 9, 2010 at 4:09 PM, RJ Atkinson <[email-masked]> wrote:
>
> 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.

Yes, these scenarios are usually due to mergers or acquisitions - then
the networks are loosely integrated just for some common applications.
Also since the countries are quite small over here, a patriotic factor
arrives - moving functionality to some other place and it is overtaken
by "foreigners". Now not every network is like a describe but I see
some challenging solutions from time to time.

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

Hmm.. if you could improve current  situation you might have a
business case to start a migration, wouldn't you?

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

I had a look on that, if I understood that right you need two NICs on
the host to be able to use both border routers?
It also seems that VET do not integrate multipath transport protocols
in the architecture?

Instead of rewriting locator values on the border router you take the
edge and core address spaces out to the hosts, add multipath transport
protocol - then you get an interesting solution, multi-homing becomes
multi-pathing with only one NIC at the host. I have tried to explain
that in appendix B, see
http://tools.ietf.org/html/draft-frejborg-hipv4-07#appendix-B

With this approach it will bring some use cases that might be
interesting for the CIO of an enterprise - it should bring down costs
and at the same time improve availability and performance, also make
mergers easier to handle - maybe enough incentives for the CIO?
http://tools.ietf.org/html/draft-frejborg-hipv4-07#section-7

-- patte

To make it easier to understand, ALOC=core locator space that is
installed in DFZ, similar as RLOC space in LISP. ELOC= edge locator
space, similar as EID in LISP.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 2 Jul 2010 07:55:52 -0400

On 02  Jul 2010, at 07:45 , Patrick Frejborg wrote:
> I had a look on that, if I understood that right you need
> two NICs on the host to be able to use both border routers?

No.  That is not correct.

BRDP lets even a node with only 1 network interface 
learn about and use as many border routers as exist.

> It also seems that VET do not integrate multipath
> transport protocols in the architecture?

I don't know what "VET" means, so can't comment on VET.

ILNP actually enhances multi-path transport protocols,
such as the (UK) UCL work on MP/TCP.  

However, it is important first to note that ILNP *by itself* 
enables a multi-path TCP implementation -- without requiring 
any TCP protocol extensions/options.  Further, ILNP's approach 
also enables any other transport-layer protocol to instantly 
become multi-path capable.

To provide a single example of how ILNP can enhance existing
proposals for MP/TCP, combining ILNP with MP/TCP enables one 
to use a single IPsec session with a multi-path TCP connection.  
By contrast, with current IPsec, one would need to have a 
separate IPsec session for each pair of TCP endpoints.  So 
the key management complexity associated with MP/TCP
would be reduced from O(M * N) to O(1) -- which is a very
significant benefit and quite complementary to existing work
within the MP/TCP area.  

Yours,

Ran

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 2 Jul 2010 08:57:10 -0700

Hi Ran,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of RJ Atkinson
> Sent: Friday, July 02, 2010 4:56 AM
> To: IRTF Routing RG
> Subject: Re: [rrg] multi-homed site issues
> 
> 

I'm surprised by this, since VET has been around for
quite some time now. The first version of VET is already
published as RFC5558. The (bis) version is very far down
the development path as 'draft-templin-intarea-vet', and
I will soon also seek publication for it. VET (i.e., the
(bis) version) is best read in conjunction with SEAL
('draft-templin-intarea-seal').

Please also stay tuned for a new version of IRON very soon.

Thanks - Fred
[email-masked] 

> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg