Re: Move forward

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Iljitsch;

> > > Essentially, 2 is a subset of 3.
> 
> > You are saying your classification is meaningless.
> 
> No, I'm pretty much sure you're saying this. But then I firmly believe
> that everything is meaningless except for the meaning we choose to
> bestow upon any particular thing. If you find my my classification
> meaningless that's ok, I'll use it as long as it suits my needs.

For a classification suits some need, classes of the classification,
by definition, MUST be mutually disjoint.

That is, your need is nonsense even in an abstract sense.

> > We can move forward a little if you admit that, by definition,
> > weak separation is not a subset of strong separation.
> 
> > The hard part, then, is to define what are "weak" and "strong".
> 
> Feel free to suggest better names for the classes.

I suggested not to have the classes, which actually are not classes
at all.

> > > If we want to do 2
> > > at all there's the problem that everyone has to implement it before it
> > > works.
> 
> > Remember that my 8+8 with doubtlessly-strong separation is
> > interoperating with leagacy IPv6 stack that it can be deployed
> > gradually.
> 
> ??? How?

As I wrote to Brian, reserve some bit(s) to designate address
families and use legacy upper layers unless both source and
destination addresses are of the new ones.

It is implemented and is interoperating with the legacy stack.

> > The problem of deploying type 1 is that it will bloat global routing
> > table unnecessarily, which can not be restored later.
> 
> My point is that this isn't necessarily the case: if we start giving out
> PI space that is simply allowed in the global routing table, we have
> bloat.

That is enough to argue against 6bonebof.

> But if at some point a type 2 solution becomes available, we can
> simply start moving in the middleboxes and after a suitable transition
> period the PI /48s can be removed from the global routing table because
> the middleboxes translate all the traffic. It should be possible to do
> this in a way that is transparent to end hosts.

If ever the type 1 is deployed to some extent, people using it won't
accept any proposal which require them additionally purchase the
middleboxes.

Wheter it is transparent to end hosts or not is irrelevant.

Proposals requiring middleboxes at some transition stage is
definitely not deployable.

						Masataka Ohta