RE: Again no multi6 at IETF#56

["Bound, Jim" <Jim.Bound@hp.com>]

>|    RIRs will just give out addresses that is all.  THe market 
>|    will deliver
>|    a routing architecture via new industry consortia or we 
>|    will figure it
>|    out here.
>
>
>A new industry consortia is now in charge of IPv6?  Please, 
>point us at it.  Figuring it out here is 'challenging'.

If this and many other specs do not begin to produce solutions in a
timely manner then I predict there will be a deployment body for IPv6 to
go work on those specs and send them to the IETF but not with the
intention of waiting for 4 years for them to complete but implement and
work the IETF at same time.  So my statement was the result of an "if".

>
>
>|    >|    Does this effort want to fix the multihome 
>|    >|    problem or the
>|    >|    routing architecture to be something other than what 
>|    we have?  Two
>|    >|    different goals.
>|    >
>|    >The goal is to fix the multihoming problem, but to do it will 
>|    >take a routing architecture that is different than what we have.
>|    
>|    Might be good to define routing architecture?
>
>
>10 years and we still don't understand the problem that we're 
>trying to solve?  Sigh.  

I think we do.  I think we just do not agree on some very basic ways to
solve the problem.  One will win and one will loose.  The loser will
predict horrible fates from the others choice.  I find asking the most
basic obvious questions before that result is the case, might be
prudent.  Because I think this is all going to stop soon and some
solutiion will just happen.  For me no solution to change the IPv6
address or the IPv6 architecture is acceptable.  Period.  I do not
believe that is required.  More below.

>
>Routing is the other half of ROAD.  The part that we didn't 
>ever finish.
>
>Ok, just for posterity: routing architecture tells you how 
>packets get from point A to point B in the network.  It 
>includes the semantics of the address, the routing protocols, 
>and the forwarding paradigm.

Ahaha.  I do not agree that includes the semantics of the address. But
the use of the semantics of the address.  So I am glad I asked this
obvious question.

But you and I will never agree on some basics that appear to be deep
rooted.  Like fixed vs variable addresses for the IP header.

>
>
>|    If we begin 
>|    by reducing
>|    traffic that causes problems for routing at the ISP in the 
>|    end systems I
>|    believe that is a start.
>
>
>Ok, let's turn off v6.  Solved.

Go back and read the SCTP suggestions as one initial solution to this
problem.

If the end system is smart enough to failover interfaces to different
ISPs, because it is aware of its multi-home nature it will help reduce
the need for ISPs to share aggregate routes.  The end system will not
need them to do that for most cases.  I realize this is not a total
solution.  Nor do I believe there is one total solution.  But multiple
solutions at different points in the network.  

>
>
>|    If new routing architecture 
>|    means change to
>|    IPv6 then I say engineers go in a room and make work what 
>you have.
>|    Extensions to IPv6 are acceptable I think.
>
>
>Extensions imply that the architecture could not support that 
>case properly as a first class citizen and that you're 
>crocking and kludging to make it work.  Seems like a pretty 
>poor basis for a "new" protocol when you're trying to get it 
>deployed and you admit up front that it doesn't cut it.

This is the negative view yes, but there is the positive view.
First I am not clear that the extensions are needed I suggested them to
you if you believe IPv6 needs **new** features, there is way to add
them. The positive view is that IPv6 is a base architecture that can be
extended far better than IPv4.

As a note the only complaint I have heard from entities really deploying
IPv6 routing with their ISP to an enterprise is they would like to see
more sub-routes for the /48s permitted.  The ISPs are sticking to the
rules and saying NO.  The ISPs are also handling the mutlihome routes
through peerings currently.  

>
>    
>|    >Well, that's kinda hard, because IPv6 as defined simply 
>|    >ingrains the problem.
>|    
>|    That's where we  will never agree and I don't use the 
>word never to
>|    often.  One possible solution to this statemate is for 
>|    someone to define
>|    what exactly routing architecture would look like as a 
>|    model.  Then if
>|    we all agreed on that model each could apply that model to their
>|    favorite solution.  I for one would look at extensions to 
>|    IPv6 that are
>|    quite possible and there are many places to define 
>|    extensions (e.g. DST
>|    Options, Hop-by-Hop, Next Headers new formats).
>
>
>Jim, if you're going to be so closed minded as to say that we 
>will never agree, then I don't see how you can reasonably 
>expect anyone to change the architecture.

Not being closed minded.  But taking a stand. IPv6 exists it is being
deployed and cannot be changed in 2460, 2461, 2462, and others.
Applications are being ported.  The point is the product has been
shipped work with the product.  If you can't then by all means compete
against it.  The locator and identifier has been discussed many times it
has not born fruit and it is not going to happen with a change to 2460.
I personally don't buy the entire notion.  That's just my view and I am
free to have it and state it and your free to state yours.  That's a
good thing.

>  Multihoming can 
>never be a first class citizen in the architecture if you do 
>not divorce the 'locator' from the 'identifier'. And that's 
>what IPv6 insists on today.  If we continue down that path, 
>then the only alternatives are:

I don't agree at all.

>
>1) Forbid multihoming.  Not gonna happen.

Agreed.

>
>2) All multihomed sites get global addresses and the routing 
>subsystem implodes.  This is the only way to get a single 
>'identifier' and then use it for 'location' across all of my 
>exit paths.  I must advertise the route throughout the topology.

I vote for #2 above but I do not believe the routing subsystem will
implode, it will just require faster/better routers, and peerings.

But we should look at the problem further to see if it can be optimized
with a change to the semantics of the v6 address.

>3) Change the semantics of a v6 address.

So you are not suggesting a syntax change only semantics to the 128bits?
But I don't believe location and identification should be different. The
address should be overloaded to support both context.I believe that is
possible.  The address is both a location and an identifier. The IPv6
address supports location top down from the left most bits for routing.
So I believe what you ask exists now.

Do you agree with the way we have stated the multi6 problem? 

Regards,
/jim