Consensus on MHAP/v6 Multi-homing

[Jeroen Massar]

On Wed, 2005-04-20 at 16:50 +0200, marcelo bagnulo braun wrote:

<SNIP>

> >>   It doesn't help for
> >> example with DNS where you want multipath over x providers.
> >
> > Most likely shim6 will depend on some sort of directory and this
> > directory will not be able to live easily inside a shim area.
> >
> 
> i fail to see what directory are you talking about here...
> I mean AFAIU, shim will use the DNS to obtain addresses, just as it is 
> done today, no changes to that, or are you thinking about other 
> directory service?

DNS can be seen as a 'directory of DNS labels'. Just like the phonebook
is one for telephone numbers, yellowpages for people etc.

It can be DNS, but it can also be something else. As such you will not
be able to multihome your directory server easily as then you will have
cyclic dependency. (Beth: "where is Anna?", "Ask Anna where Anna is")

> > Fun part is that people will most likely want rapid updates for their
> > shim6-mappings, at a certain point one will then simply have an overlay
> > BGP network with all the routes in it too. One can drop the ASPATH
> > partially then though, one only needs it to check for loops.
> >
> 
> I fail to understand what are considering here... The changes in the 
> locator set of a shim context will be done through the shim protocol 
> between the end nodes involved in the communication, right? so, what is 
> BGP and overlay come into this?

The shim protocol will be just like running automatic BGP between 2
peers. But I'll first have to see the proposal of such a protocol.
In the mean time I already a have a version of the shim which can be
feed using a userspace daemon which mappings it is supposed to have.
The source of the daemon is undetermined though but that is why it has
an open API.

overlay -> because you would get a 'core' network which does not see the
shim6 /48's, and this networks gets overlayed over the existing network.
(Which many people won't like and won't favor and thus won't accept)

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050420/2b7bbdd4/attachment-0001.bin