Re: Ohta-san's draft

[Jim Bound <seamus@bit-net.com>]

Sean,

> | 8+8 is not needed at all or differential of location and identification to
> | achieve multihoming
> 
> This is strictly true, since we have multihoming now.
> However, what we have now simply sux.

Yes multihoming is a problem and why we are here and I think we can figure
this out.
 
> Note that there are very different properties between what
> you and greg maxwell talked about while i was asleep, and
> what is in Ohta-san's draft.   The latter contains an
> important optimization.

I don't agree that we need that optimization as proposed in the draft but
I do think it important we view the optimization to see what happens. I
read the draft twice fyi.

> Firstly, think of the host's take on "who" vs"where" 
> separation in terms of masking out the top N bits when
> trying to figure out if a received packet is "for me" or
> "not for me".  That is, sender may choose a viable path of
> which the receiver is currently unaware, and put the path
> into the "don't care" top bits..  Routers along the way DO
> care, and forward appropriately right to the receiver,
> which masks away the for-use-by-routers part (where) and
> sanity checks against the for-use-by-hosts (who) part.

I am familiar with the NIMROD arch issue of who and where we have been
here before in the IETF it bore no fruit and I doubt it will bear any
here.

First what is being deployed (the pipelines) is the Aggregatable Address
format where we have low order 64bits as EUI and upper 64bits as prefix
but implementations do not take inherent knowledge of that property except
on compare of high order bits of the IPv6 address for prefix use
indirectly.  So they will work with other address formats for the 128bits.
I think this is wise so we can be flexible tomorrow.

So for this discussion the present deployment mode is where (prefix) and
who (EUI) but who requires all 128bits.

So where we have and maybe the discussion is overloading the who by using
the prefix.  We had this discussion on IPng directorate fyi.  PIP had the
potential to not overload who and keep where separate.  But did not have
other properties for that set of requirements.  Especially IPv4
interoperation mechanisms critical to deployment next to IPv4.

Also as note I was a participant at the 8+8 meeting and watch the GSE
historical account carefully.

> Then bear in mind that this split allows for an important
> optimization: if the hosts DO care about all the bits, and
> given that real Internet traffic is often forwarded on
> asymmetric paths, and thus (and for other reasons)
> failures may be simplex, then there are NxM combinations
> of (source,destination) that must be agreed upon to have a
> connection.  Using Ohta's method, since it cares only
> about the *sender*'s choices, there are only N or M where
> N and M are the number of addresses each host believes
> can be used to reach the other.

I don't believe we have to consider the NxM (assuming cross product???)
solution tomorrow if we extend the end-node model (that part I agree with
with the draft), to support better multihoming from the end node. Because
it will decrease the routing table and NxM mesh the Border, Edges, and
Core have to deal with by an order of magnitude is my "guess".

Anycast and Multicast present other problems which we will have to discuss
once we figure out the unicast discussion (the draft lightly touched on
multicast with commentary but anycast is missing).

So if we say N = who/what and for IPv6 is 128bits.

And say M = where and for IPv6 that is a prefix length.

This will not be popluar with my IPv6 colleagues but I would like to see M
become less-than-or-equal-to 64bits and we can count on it.  I believe
this would also work with Anycast and Multicast too.

Then all the hosts care about are M.  And all the routers care about are
M.  And with end-node multihome optimizations we have reduced the
multihome problem at the IP and transport layer significantly and
something that cannot be done with IPv4 (that is not a negative statement
just an evolution of great minds).

Ipv6 implementations stay in tact and APIs are not blown away.
Core specs stay in tact (ND, Addrconf, DHCPv6, PMTUD, IPsec, Transition
Mechanisms, et al).
 
So where I do disagree with the draft (and maybe my interpretation is
wrong) and with GSE parts is a hard split for the 'who', and as
implementer I don't think we have to whack the stacks either and
understand the details down to the running code.

So I think my difference is not great but significant.

> That is, no "who"/"what" split: NxM.  With "who"/"what" split: Nx1.
> Because we don't have to do anything special with choosing
> a working/optimal source address.

I strongly agree with this point.  I think we can 'forget-about-it' as far
as the source address for our purposes and why I think the prefix and
length is imperative.  But if we just say upper 64bits is the length we
remove that code check across implementations and reduce millions of
caches and path serarches will be faster.  In fact I think new algorithms
would be big time possible.  And it would be very very friendly to
Wireless and Mobile nodes too.

It would mean IMO PIP would have been retrofitted to IPv6 and the benefits
from that idea and with zero cost to IPv6 implementations and we could add
options to Neighbor Discovery to fine tune multi6 at later date.
 
> Given a near future which likely includes both heavily
> multihomed popular content sites, and household
> multihoming (IP over cable, xDSL, power lines, wireless, ...),
> the reduction in power of the function which finds a
> working combination of addresses [at startup or after
> topology change] is extremely important!

100% agree and note my comment above about Mobile and Wireless we can add
toasters, lawnmowers (my favorite choice to do from my laptop), and
embedded intelligent devices like lock&load&reload for firing mechanisms
remotely operated when mankind has to do wargames.

> P.S.: Could you please explain "bump-in-the-bump" to me? 
>       I've never run across the term before.

Sure.  Its my way of referring to the general mechanism to use shims to
translate IPv4 to IPv6 or IPv6 to IPv4 in the context of application
space as tool to not have to port applications to IPv6 mostly. 

It can be done at the API by catching the socket call (as one API we are
all using) in the library and doing what is necessary to translate the
address or at the socket layer in the kernel (e.g. so_send.c or
so_recieve.c in BSD) lots of other code has to do mappings (e.g.
addresses, socket options, error returns) and keep a new state machine at
the socket layer in both cases.

Other method is bump in the transport layer where the above is done at
tcp_input.c or udp_input.c and this affects checksums et al and IPsec too.

Other method is bump in the IP layer and here we do all the work before
the virtual transport layer very similiar to what we have to do to process
the MIPv6 binding update.

And I am sure there are others.  So to refer to them all I call it
bump-in-the-bump as none are cast in stone and others will be invented I
am sure.

Also I have issue putting this extra code and state in a production
implementation because it will at some point become dead code and cause
performance hit.  Also it will not work for all cases. And its easier to
just port ones app to IPv6 and we have elegant ways with the API to
process IPv4 ONLY, IPv6 ONLY, or hybrid handling IPv4 && IPv6.

But if the customer lost their source code (and I know some who have) then
to get their systems to IPv6 a bump-in-the-bump will be a custom system
integration job and special case OS patch for them and could be warranted
and in that case I like bump-in-the-bump but the only case.

I think the mail to suggest this can help mutlihoming per Brian's taxonomy
will not work in practice and only in theory.

Does that help?
 
> P.P.S.: Just to be repetitive in hopes of clarity... 
> 
> 	O'Dell-san: hosts don't care about what is in top 8 bytes
>   	     (well, 6, 7, whatever), that's for routers, 
> 	     and is filled in by routers -- hosts can
>   	     expect zeros and send zeros to indicate
>   	     something going into the wide Internet (fsvo "zeros")

I agreed with Mike on this for 8+8 but I don't think zeroes will work
practically and I do think as I said above 'who' is the entire 128bits
and good for autoconfiguration.  This is what convinced many to make IPv6
128bits (at least me) was the autoconfiguration benefits and plug and play
and one of strong advantages of IPv6 marketing people state which is
true.  We should not break that because multihoming.

> 	Ohta-san: _receiving_ hosts don't care what's in
>   	     the top 8 bytes (well, 6, 7, whatever),
>   	     that's for routers, but is filled in by the
>   	     sending host -- receiving host can expect
> 	     random bits and sending hosts fill in
>   	     something that makes sense to routers

This is more in line with my thinking too.

In the past I have been pretty hard on the idea that routers can whack the
prefix bits. But if we can move forward and resolve the mutlihome
problem it might be useful to look at different models again. But this
part of our discussion must be transparent to the upper layer and APIs and
it must not interfere with the identifcation of flowlabel + src address
for potential QOS (int serve) work in progress.

The APIs and apps stay in tact if they continue to deal with 128bit
thingees.

The flowlabel stays in tact as long as the source address + flowlabel is
left in tact for delivery to the 'who' destination much like an MPLS label
is what I am thinking.  This has great optimal implemetation advantge too
for stack builders (servers, clients, routers, and mobile devices). 


> 	Major architectural difference is that O'Dell's proposal 
> 	*explicitly* requires munging by "middle boxes" 
> 	to make up for sending-host ignorance, 
> 	whereas in Ohta's proposal,  hosts are expected to
> 	be less lazy about knowing what the Internet looks
> 	like at any given moment, so that they can supply
> 	top (8,7,6,whatever) bytes which make sense to routers 
> 	everywhere, and thus not need middleboxes to do rewrites.
> 	(I suppose Ohta-san is more into the spirit of
> 	"end-to-end fundamentalism" than O'Dell-san)

And I think the e2e catanet model is necessary for the future. And I don't
like the idea of middleboxes whacking things if it can be avoided.

> 	For *both*, major difference to host implementors
> 	like Bound-san is that you MUST be prepared for a
> 	packet whose lower (8,9,10,whatever) bytes are
> 	your identity (EUI-64, or whatnot), and ignore the
> 	(possibly zero, possibly random) top bytes when it
> 	comes to replying to the packet.

Yep.
 
> 	Both offer useful features when you leave the top
> 	N bytes out of checksums and don't use them to
> 	carry identity around in higher-layer protocols.
> 	O'Dell's proposal requires this.

You can carry them just don't use them.  This would make any nodes lookups
so much faster all of us would apply the fix.

p.s. One other thing in Ohta's draft was discussion of session layer APIs.
I don't think we should specifiy or standardize this in the IETF.  But if
we want to specify a selector which would help sctp too and I think the
flowlabel can be overloaded to do QOS and this function that is fine and
achieve the same result Ohta I think is looking for to make the draft
work.  But it would take to long to develop a session API in the IETF and
I strongly believe this should be left to implementer discretion how it is
designed and executed by running code on a the many platforms that may use
the selector.  If we specify such a selector correctly interoperability
will be maintained and not necessary to define how the code or APIs are
used.

/jim