Subject: [rrg] Teco's BRDP proposal and SHIM6

From: Robin Whittle <[email-masked]>
Date: Tue, 25 Nov 2008 15:11:45 +1100

Hi Teco,

In:
  Re: RACHH: the host-based solution ....
  http://www.irtf.org/pipermail/rrg/2008-November/000239.html

you wrote:

> Multi-homing with PA is possible. See RFC3704 section 4 on
> suggested solutions.

A quick look at this left me with the impression that this does not
specify a usable form of multihoming with PA prefixes.

My understanding of the purpose of multihoming is that the end-user
network's hosts can continue their current sessions through one or
the other ISP's links, without disruption, as one link is selected by
some mechanism due to an outage in the other.

> My BRDP Based Routing proposal is an enhancement, it eliminates
> careful planning and configuration and the need for tunnels.

OK - I see this I-D, new a week ago:

   http://tools.ietf.org/html/draft-boot-brdp-based-routing-00

which depends on:

   http://tools.ietf.org/html/draft-boot-autoconf-brdp-01

I understand it is for IPv6 only at this stage. I still don't see how
this form of multihoming enables sessions to survive an outage of the
ISP currently in use.

If you think BRDP is in any way relevant to scalable routing, perhaps
you could write up a summary for it on the list.

>> 1 - It would be impossible to deploy it widely enough (in any
>> reasonable time frame) that there were such a proportion of all
>> hosts (such as 95%, 99% or whatever) that the resulting
>> multihoming would actually be useful to anyone who deployed it -
>>  this is because a host-based solution only works when both
>> hosts are upgraded.  This is especially so if the scheme
>> involves rewriting applications, as well as host stacks.
>>
>> As Brian Carpenter wrote recently:
>>
>> It's clear that once you ask for action by application
>> programmers or non-routine action by end users, the costs become
>> unthinkable.
>>
>>
>> 2 - As I wrote here:
>>
>> Fundamental objections to a host-based scalable routing solution
>>  http://www.irtf.org/pipermail/rrg/2008-November/000233.html
>>
>> It would be undesirable to push this functionality out to hosts,
>>  compared to handling it with some new architectural structures
>> in the network (that is, the routing and addressing system in
>> the core of the Net and in ISP and end-user networks).
>
> I prefer a step-by-step approach.
>
> The first step would upgrade edge networks for multi-homing, this
> enables multi-homing for hosts that can make use of it.

However, with the possible exception of SHIM6, there are no such hosts.

There seems to be no broad support for SHIM6 as a solution for
multihoming, or as part of the scalable routing solution.  I was
referred to this message in a 2006 discussion, by a list member, as
an example of "Several prominent network engineers at major SPs
trying to tell the shim6 creators that it was unacceptable."

   http://www.ops.ietf.org/lists/shim6/msg01139.html

but I haven't had a chance to read it yet.

What is the incentive for anyone to upgrade their edge networks, if
there are no hosts which can multihome with the upgrades? I assume
that the correspondent host would also need the host upgrade too - so
for a very long time, there would still be lots of traffic which
could not be multihomed.

I think that having a multihoming solution which does not work with
100% of traffic, or very close to 100% (like 99%) is of little value
to anyone.

I guess your upgrades to the network would involve upgrades to
routers, more management etc. as well as the major expense of
connecting to a second ISP.

> In a second step, hosts are updated.

Yes, but to what?

> It depends on the gain for users how fast a transition takes
> place. Keep in mind that many end-user hosts use dynamic addresses
> already (single address, IPv4, lots of NAT). Day-to-day
> renumbering is no problem at all.
>
> Upgrading server farms requires special attention. I would not say
> servers MUST have static unique addresses, there are examples of
> hosted servers based on DNS names. For those, multi-homing is not
> that difficult to implement.

I don't see how you can implement multihoming for anything, with
session continuity in the event of an outage, with PA addresses
unless all hosts involved in the communication have some stack and
probably application changes, such as I criticised here:

  Fundamental objections to a host-based scalable routing solution
  http://www.irtf.org/pipermail/rrg/2008-November/000233.html

> I think the subject line has some negative judgment.

Yes - but RACHH (Routing and Addressing Changes Handled in Hosts) is
quite descriptive of the host-based scalable routing solutions I am
criticising.

> And I would call it the edge-based solution.

"Edge-based" could mean actions in end-user networks (routers) or in
the hosts themselves, or both. I was discussing only solutions which
required new responsibilities for hosts to handle things which happen
in the network (outages, TE, new ISP etc.), especially if
applications needed to be rewritten.

> Keep in mind that I do not prefer edge-based over core-based. I
> think they are orthogonal.

OK - but I would prefer a situation which solved the entire routing
scaling problem in one place, such as the routing and addressing
system, rather than requiring new functionality, new architecture
etc. in both the network and all the hosts.

- Robin

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

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 25 Nov 2008 15:50:51 +0100

Short version:
 - Reply to Robin's question
 - BRDP Based Routing doesn't brake anything and works with all IGPs.
 - There is more than Shim6
 - BRDP Based Routing IPv4 support is on its way
 - There could be a need for host renumbering

> -----Oorspronkelijk bericht-----
> Van: Robin Whittle [mailto:[email-masked]]
> Verzonden: dinsdag 25 november 2008 5:12
> Aan: RRG
> CC: Teco Boot
> Onderwerp: Teco's BRDP proposal and SHIM6
> 
> Hi Teco,
> 
> In:
[Teco:] 
That depends what you think what is usable.

> some mechanism due to an outage in the other.
[Teco:]
Session continuity is provided with MIP6 and HIP (and maybe others) and this
works fine with BRDP Based Routing.
Moreover, BRDP provides hints to the MIP6 stack for SA selection.
Expect BRDP Based SA selection I-D before next IETF.

As far as I know, there is no secure, scalable and management-free solution
for multi-homed networks.
Translation on the border router is something of interested, but this has
some well-known disadvantages.

> this form of multihoming enables sessions to survive an outage of the
[Teco:] 
On BRDP, Autoconf (SLAAC) for IPv4 is not in scope.
IPv4 address configuration using DHCP for connected MANETs is in scope.
Using short lease times, address switching caused by failing ISP unlink
helps fast recovery. Some MIP stacks has hooks in WiFi driver for triggered
handover. This is a subject for improvement (MIPSHOP).

BRDP Based Routing for IPv4 is straightforward, I just add the IPv4 prefix
in the BRIO. There are reserved fields left, so no overhead. Next versions
will include IPv4 support.

Again, session continuity is MIP6 and HIP (and maybe others).
In many access network use cases, session continuity is not that important
because short lived connections are used or session reestablishment is
handled by higher layers (or user...).
Personally, I switch IP addresses once a day (at least!).

> you could write up a summary for it on the list.
[Teco:] 
I included a _marketing_ sheet in the v6ops presentation:
- Built on well known protocols such as IPv6 Neighbor Discovery
     And Policy Based Routing
- Works with all IGPs
- Full support for multi-homing with Provider Independent (PI)
     And Provider Aggregatable (PA) addresses
- Helps scaling the Internet by removing need for PI addresses
- Border Router load balancing
- Automatic ingress filter on first hop routers
- No tunnels, routing headers or any other encapsulation
- Extensible for ad hoc networking

The second marketing sheet is more important:
 - List of incompatible protocols:

   <empty>

If someone comes up with a currently being used protocol that is broken by
BRDP Based Routing, I really want to know. I'll add it in the applicability
statements.
Same for IGPs, I am not aware that BRDP Based Routing doesn't work with any
of the IP routing protocols used today.

I'll set up a wiki / Q&A or something else to better describe the BRDP
protocol and related topics.
Current URL: http://www.inf-net.nl/brdp.html

> However, with the possible exception of SHIM6, there are no such hosts.
[Teco:] 
Fault.
We have MIP6 and HIP.
And session recovery at higher layers.

> there are no hosts which can multihome with the upgrades? 
[Teco:] 
1) add additional capacity
2) reduce dependency (ISP uplink fail: part of hosts survive)
3) migration to multi-homed hosts (also by adding load balancers)
4) single uplinks at different sites, sites are interconnected
5) ad hoc networks / hasty formed networks, where zero or more uplinks are
available
6) multiple access providers, e.g. dsl and wimax and wifi (is related to ad
hoc networks)

> I assume
[Teco:] 
Not the case with MIP6.
Also not the case if short lived connections are used.

> 100% of traffic, or very close to 100% (like 99%) is of little value
[Teco:] 
Agreed on that no traffic may have hindrance of multi-homing.
It depends on the benefits of multi-homing. Think of a smooth transition of
single homed network (single ISP), with PA addresses. I this case, not a
single host is required to support multi-homing, but there can be a business
case for the smooth transition.

> connecting to a second ISP.
[Teco:] 
If someone finds out multi-homing is not cost effective, (s)he is not
interested in this kind of technology.
But it seems to be that there is a need for PI addresses.
I would not say that multi-homing with PA addresses takes away all the needs
for PI, but I expect a reduction.

> > In a second step, hosts are updated.

There are multiple solutions for upper layer transparency (MIP6/HIP/Shim6).
Personally, I think updates of applications provide the real benefits.
I use the Skype in the notification area for checking my Internet
connectivity:-)
Bittorent is another example.
I have to check SIP (to mention an IETF upper layer protocol).

>   http://www.irtf.org/pipermail/rrg/2008-November/000233.html
[Teco:] 
Yes, a long list of objections. It is easy to compose a long list of
objections for the routing based approach (Tony posted this already).
Remember I do not prefer one of the other.
But please understand there are some good points on the host based approach!

> applications needed to be rewritten.
[Teco:] 
I think the routing architecture should describe the whole infrastructure
and not just the core network.
The Internet model is a model of cooperation. Host do their job, so is the
core.

For example, my BRDP Based Routing improves routing in edge networks only. 
There are benefits for the hosts and for the core. 
Hosts may use multi-homing. Load on the core by unneeded PI addresses may be
reduced.

> etc. in both the network and all the hosts.
[Teco:] 
Maybe you forget something.
There could be hard requirements for host renumbering, e.g. for privacy or
address hijacking.
And I am not sure on security considerations on total loc/id split. There
are some postings on this subject.

Teco.