Subject: RE: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions?

From: "Moisand, Jerome" <[email-masked]>
Date: Thu, 5 Dec 2002 14:35:23 -0500

Please, see inline comments below.

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 2:00 PM
To: Moisand, Jerome
Cc: 'Harrington, David'; Martin Stiemerling; [email-masked];
[email-masked]
Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? 

> Well, to start with, please look again to my recent e-mail about the three
> types of policy management architecture I listed. Correct me if I'm wrong,
> but only one of them appears to be envisioned in the existing midcom
> requirements/proposed-architecture. 

Policy management is orthogonal to the midcom protocol.  We
assume that there's a policy component but we're not
specifying it.  What's envisioned is that there is one, but
the questions of where it's located, what policy decisions
are negotiated, and specifically what it will look like are
completely outside the scope of the current set of
deliverables.

=> well, this is kind of the whole point. The architecture currently
specified acts in the way you described, of course. And I have nothing
against it, on the contrary! I'm just saying that there are other
policy-oriented architectures, following the framework defined by the "rap"
group (and used by the "diffserv" and "ipsp" groups) which would reach the
same "fundamental goals" for managing middleboxes, using a dynamic policy
protocol in-between. And I believe we should not exclude such architectures.

> <<The Midcom protocol must allow a middlebox to communicate with more
>    than one Midcom agent simultaneously.>>
> 
> I see this as a fairly major issue, I don't believe we should restrict
> ourselves, and exclude policy management architectures which have been
> promoted by IETF in the context of the "rap" effort for several years. 

I doubt very much that you'd have luck finding *one*
participant who thinks it sufficient to have a middlebox
that's only capable of communicating with one agent.  In the
context of VoIP applications, as well as many others, it is
absolutely mandatory that more than one agent be able to
send requests to a middlebox.

=> well, if you're making the assumption that a stateless SIP proxy should
be the "midcom agent" and should directly interact with the middlebox,
you're absolutely right. Which is precisely the reason for which I do like
the architecture being proposed as one possible legitimate construct. 
=> But I fear this assumption is too restrictive. Why should the SIP proxy
be the component speaking with the middlebox? You may have more complex
software architectures, where multiple SIP proxies will speak to a single
policy decision point (aka policy server), which is in charge of a given set
of middleboxes. Or stateful SIP proxies also acting as policy servers. Etc.
The "rap" framework explains pretty well how to make this scale and be very
resilient (e.g. strong transaction semantics, plus strong failover
properties). Then we have only one middlebox agent speaking to a given
middlebox at a given point in time. And I don't see anything wrong about
that. As one possible architecture among others.

=> again, I apologize for possibly being disruptive and making such
statements quite late in the process, but well, I can't help it!  ;-)
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Melinda Shore <[email-masked]>
Date: Thu, 05 Dec 2002 14:49:31 -0500

> protocol in-between. And I believe we should not exclude such architectures.

Those architectures certainly are not excluded by the
current midcom framework.  We did have to constrain the
problem space, however, lest we become one of those working
groups who never produces anything (which is where we're
currently headed, BTW).

> you're absolutely right. 

We don't make that assumption.  We assume that any endpoint
or other device can make a request of a middlebox.  By
restricting it to a single agent we'd either have something
that didn't work for telephony applications (the ones
driving the work, incidentally), or something that wouldn't
scale at all.  In the latter case we'd effectively be moving
the midcom protocol to running from the endpoint to an agent
and a policy protocol between the agent and the middlebox,
and I gather that's what you're arguing for.  That's not a
good architecture in an environment in which you've
potentially got tens of thousands of endpoints.  

If you're going to propose architectural changes you've got
to be specific about what you want to do and why it's an
improvement over what we've got now.  The rap work would not
apply, I think, because the policy decisions are being
driven up by network events.  We're trying to make requests
of the network based on application events.  We're also
trying to restore end-to-end function in the face of funky
disruptive devices.  I don't think you've made a
particularly compelling argument for changing our
architecture, and unless you can do so we really do need to
move on.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 Dec 2002 13:45:57 -0800

> protocol in-between. And I believe we should not exclude such architectures.

Could you demonstrate how other architectures are excluded?  If your 
architecture requires only one agent, then the current design should 
handle it.  Remember, we're not talking about a protocol between the 
middlebox and policy server.  That we leave to others.  However, there 
needs to be a way for a single device to make a singular request to a 
middle box without the need for an intermediary.  That's a charter 
requirement.

Eliot