Re: [Spud] FW: New Version Notification for draft-hildebrand-spud-prototype-02.txt

[Ted Hardie <[e-mail]>]

On Tue, Mar 10, 2015 at 1:52 PM, Joe Hildebrand (jhildebr) <
[e-mail]> wrote:

> On 3/10/15, 2:18 PM, "Patrick McManus" <[e-mail]> wrote:
>
> >"want" is such a strong word :) I'm just brainstorming.
> >
> >There is a case where L doesn't want to be part of the flow after Z-15 is
> selected, but obviously it needs to be in a TCP scenario if for no other
> reason than to forward the ack traffic to Z-15 - the fact that it continues
> to be involved
> > is really an artifact of the protocol - L isn't a typical on path
> middlebox; but spuds is still interesting here for its interaction with
> something like a client side NAT. This is an ordered flow (a tube?) with 3
> end points.
>
> I could imagine L sending a path declaration that allows Z-15 to take
> over, basically an in-flight hand-off.  We would have to get that protocol
> correct early on in the process so that everyone implements it, though.
>
>
​So, I don't think this is the right thing to do in a substrate.  You may
want to build a protocol that can do this on top of the substrate's
capabilities, but gating acceptance of the substrate on this particular use
case seems to me unwarranted fate sharing.

If you want an application-layer protocol that can handle service handoff,
information like "Z-15 has path to path information for tube-id N" as an
advisory message may be useful.    But if Z-15 has a different IP address,
as above, there is no guarantee that the path will remain the same;
anything from ECMP on up may change it.

Call me old-fashioned (or make me one, even better), but I believe it is
easier here to use anycast IP addressing for the source addresses while
allowing the tube-id to be used to dispatch to the right back end.  In an
SDN world, you might not even need that to be in L, but in the baseline
network elements matching tables.

regards,

Ted