Re: Shim6 proxies

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 25/04/2006, a las 2:04, Jason Schiller (schiller@uu.net) escribió:

> On Thu, 20 Apr 2006, Scott Leibrand wrote:
>
> > Date: Thu, 20 Apr 2006 09:58:58 -0400 (EDT)
> > From: Scott Leibrand <sleibrand@internap.com>
> > To: marcelo bagnulo braun <marcelo@it.uc3m.es>
> > Cc: Per Heldal <heldal@eml.cc>, shim6-wg <shim6@psg.com>
> > Subject: Re: Shim6 proxies
> >
> > On 04/20/06 at 4:02pm +0300, marcelo bagnulo braun 
> > <marcelo@it.uc3m.es> wrote:
> >
> > > you can still make source address based routing work in multiple hops
> > > or you can use a mesh of tunnels to allow exit routers to forward the
> > > packet to the proper exit router and so on...
> >
> > If this is a requirement to implement shim6, it will not happen.  It
> > doesn't scale, and is way too complicated to manage.  Either we find 
> > a way
> > to automate source routing by IGPs, or we give up on letting hosts 
> > control
> > its egress in networks with more than one broadcast domain.
>
> I agree with Scott.
>
> Source routing is expensive.
>
> 1. Get the source to put the "right" source address in the packet
> (e.g. it understands the IGP metrics or there is some routing oracle 
> that
> pushes enterprise wide source address preferences)
>
> OR
>
> 2. Have the egrees router re-write it on exit.

yes these two options have been considered and imho they are useful, 
but only in some scenarios

option number one above is good but you need to upgrade the host within 
the multihomed site. that is ok, but you would be breaking connectivity 
for legacy nodes (i.e. nodes that do not have this mechanism).

option number two provides even additional features, as some TE 
features, but it imposes even more requieremetns, since both the 
internal and the external party need to support the full shim6 protocol 
and have shim6 state

So, both of these options are ok and we may go for them , but we also 
need something else

I mean, the problem with ingress filtering is that if you have a single 
homed site with regular IPv6 nodes (no shim6/multihoming mechanisms) 
and then the site becomes multihomed, then these nodes will experience 
connectivity problems because ingress filtering (even if there is no 
failure!). So actually these nodes will ontain a worse service because 
of multihoming.

So, IMHO we need mechanisms that when a site becomes multihomed, so 
that legacy nodes without multihoming support can obtain at least 
similar service that the one they had when the site was single homed. 
(this means that will not loose packets if there is no failure)

This AFICT can only be achieved with some form of source address based 
routing in some of its forms. I agree that this may only be a 
transition tool and that more stable solutions may be required in the 
long term as the ones that you mention above, but imho something in 
those lines is needed at least to enable multihoming at the begining. 
Please note that a transitory solution based in mesh of tunnels between 
the site exit routers could be enougj to restore connectivity

makes sense?




> > > but, i guess that as the site grows, such approaches may collide with
> > > other requirements
> >
> > I don't think it requires any growth to get such collision.  I'll put 
> > it
> > even more bluntly: almost anyone with enough routers to have an IGP 
> > and
> > run BGP *will not* want to multihome with shim6 as currently 
> > specified.
> > They may be fine with enabling shim6 on their hosts so they can talk 
> > with
> > multihomed hosts at smaller sites, but for their own multihoming such
> > sites will want to use traditional BGP techniques.
> >
> > As I've said before, I think the shim6 design needs to recognize that 
> > it
> > will not be the One and Only method for multihoming, and therefore it
> > needs to be designed to ensure that hosts that don't use shim6 for
> > multihoming can still interoperate with multihomed hosts and small 
> > sites
> > that do want to use shim6.
>
> Agreed.  To put it another way, if shim6 is not useful to largish
> enterprise customers and content providers, then they are not likely to
> turn it on, especially if it add complexity like policy routing

please note that source address based routing is only required in the 
site that is mutlihomed using the shim6 technique (i mean if you have a 
big content server located in a site that is using PI-BGP based 
multihomed and it is communicating with small multihomed site that is 
using shim6 to support multihoming, only the small site will need to do 
source address based routing in this case) so no additional burden is 
putted in the big site routing system because of the source address 
based routing used by the site using shim6

> or holding
> lots of state on content servers.

yes but this discussion wasn't actually finished in the list...

We still not have a clear picture about what the state required by 
shim6 suppose to big servers, compared to the state required by tcp for 
instance...

see Erik's mail on this issue

So, i do agree we need to make the solution attractive for big servers, 
but imho we need to quantify what this means...

Regards, marcelo


>   So unless you only want shim6 to be
> useful as a peer-to-peer technology for consumner customers figure out 
> how
> to eaither add value to the business enterprise customers and content
> providers, or at least make it non-invasive to them as Scott is
> attempting.
>
> ___Jason
>
> > -Scott