Re: [OFF-PATH-BOF] SIP, naming, APIs and control

[Melinda Shore <[e-mail]>]

On 7/13/06 1:35 PM, "Teemu Koponen" <[e-mail]> wrote:
> o) Mixing the needs to persistently identify an end-point for machines
> and for users was distracting.  I do not think hierarchical names
> should remain the sole option to consider. Flat names are rather
> attractive option indeed to identify end-points for machines. In fact,
> I think one should support both.

I think it's probably early to bog down in deployment issues, but
I do think it's worth mentioning deployment issues *un*related to
compatibility issues and I think this is one of them, for two
reasons:

1) flat namespaces are just plain hard to manage, and
2) I'm not sure where Paul or anybody else stands on this
   but I've been laboring in these particular fields for a
   few years now and from my perspective the really hard problems
   relate to topology and "findability."  It's much harder to
   find your way around a flat namespace.

> The fundamental aspect I still do not understand is that how the
> decoupling of signaling and data paths helps at all. It strikes to be
> problem roaming only for me. (I think Bob Briscoe asked this without
> getting a decent answer.) I'm not sure whether I heard the word in
> some comment, but I think the group name misses a single word:
> control. This all is about getting the control back to the end-points
> and not that much about decoupling the paths.

When I first brought the proposal for on-path middlebox communication
to the IETF I described it as "topology insensitive," and I think that's
still the desired outcome.  However, what we've found over the past
few years is that on-path middlebox signaling is nearly impossible to deploy
in all but the most constrained networks.  I agree that focusing on
the question of whether or not the signaling is on-path or off-path
is largely orthogonal to the work that needs to be done, but by
now we know an awful lot about how to do both on-path and off-path
control/request/communications but not how to solve the extremely
difficult problems introduced by even modest topological complexity.
My opinion is that ultimately it's the path-decoupled stuff (I
guess "off-path" is kind of misleading in this context) that's going
to be *actually* useful in real networks, but obviously there's
not yet any consensus about this and some further discussion is
undoubtedly necessary.

But it is my feeling that the "control" aspect has kind of been done
to death and is well beyond the research stage.

Melinda

_______________________________________________
OFF-PATH-BOF mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/off-path-bof