Re: More random and not so random thoughts

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I suppose it would be a good idea to get a working definition of 
> "multiaddressing". I think the idea is that a host gets more than one 
> address. At some point this host will start emitting packets to the 
> network. The most basic problem that we must solve in order for this 
> to work is the source address selection problem.

This seem to be on the plate for more than one working group at the 
moment, and I would guess that the IETF needs to do some work here. I 
think I can guess Randy's comment : "As long as work is being done it 
doesn't matter where it is". But I still think this is the grey zone 
for belonging here. If so, I think we need to convince some 
applications people to start following this WG.

>  Something better than RFC 3484 for the destination address would be 
> very useful too.

See above.

> I think we can address this separately from whatever else we're going 
> to do. So by all means, work such as NAROS should continue.

Agree, see above.

> IP: not so bad and not so good
>
> - this can be a general mechanism, do it once, solve the problem 
> forever
> - possibility of offloading processing to middlebox for policy, 
> efficiency or speedy deployment
>
> Ideally, we could start by implementing this in middleboxes. Yes, 
> middleboxes suck but doing multihoming in the face of restrictive RIR 
> policies and strange filters in far away networks isn't much fun 
> either.

RIR policies are set by the community, not by the RIRs for their own 
sake.

> Then everything is implemented in the OSes. Now there is a tradition 
> in Unix where TCP and IP are in practice completely comingled. So even 
> though we define this mechanism to work at the IP layer, TCP 
> implementations could easily incorporate this and start doing *really* 
> interesting things such as load balancing a single session over 
> multiple paths.
>
> And if we're careful when defining all of this, it should be possible 
> to drop in a new namespace if and when this is considered desirable.

So you are arguing for adding a new "abstraction" layer in the 
architecture?

> Christian says implementing this would turn OSes upside down. But I 
> simply don't see this. It seems to me that this could be entirely 
> contained to the (TCP/)IP stack. Applications simply revert to IPv4 
> behavior where they connect to a single address and if it is possible 
> to set up the session, it will happen, and if not, the connection 
> fails. No need to do anything complex.

The unanswered question is how much do we want to / can we / dare we to 
change in the architecture in one go.

> About the roadmap/more desing teams thing: I'm afraid of a situation 
> where a good core idea doesn't take some limitations in consideration 
> so the resulting proposal is flawed. It looks like this is already the 
> case with e2e/lin6, but I have to read a bit more about those before I 
> can say anything conclusive here. Hopefully the chairs can figure out 
> a way to avoid this from happening.
>

The point me and Sean tried to make is that people will have their 
views and ideas on  the solution of a specific problem, if there is 
one, two or ten design teams. For us as chairs, it is however easier to 
handle if these views are expressed grouped in single drafts, rather 
than as comments and individual drafts per each person. So I see your 
concerns, but I don't see how a second design team changes anything.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBPxaXz6arNKXTPFCVEQLPzACfZHskdIC7UUpcuFBclpHkEaIGVbIAoM9W
psCxL3tikzZtIC1K51rBcrHb
=ZkM0
-----END PGP SIGNATURE-----