[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shim6 proxies

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