Subject: [midcom] framework document

From: Eliot Lear <[email-masked]>
Date: Thu, 17 May 2001 09:16:22 -0700

Hi,

Nice pictures.  Still, I thought we had agreed in March that the
In-Path/Out-of-path distinction was unnecessary for purposes of defining
requirements for a MIDCOM protocol.  The drawings in the draft even
indicate this.  So why mention it?  If necessary at all, diversion should
be an internal mechanism of the middle box.  What am I missing?

There is another concern the document only briefly discusses, which I
should now like to cover.  Do we need a separate protocol to communicate
policy between the middlebox and policy server or can it be the same as
that of the middlebox?

I submit that the answer itself is a policy question.  Since the caching
of policy would require the sharing of policy outside of the policy
server.  This is the COPS-PR argument The cost of not sharing is of course
performance, and perhaps some amount of reliability and latency.  The
opposite would be "mother may i", i.e., the COPS-RSVP mechanism.  What is
clear is that there is no requirement that the protocols be the same, and
there is no need to proceed on the basis that this is in fact true.  Thus,
in the framework document, I would suggest a modification in the diagram
to match what section 2.9 says, which is to draw the policy server line to
the side of the middlebox.

What is clear is that the midcom protocol itself must be a "mother may i"
mechanism.
--
Eliot Lear
[email-masked]

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 17 May 2001 12:26:56 -0500 (CDT)

> be an internal mechanism of the middle box.  What am I missing?

	My thinking is that these things are there to provide
context, to provide scope for the set of problems MIDCOM should
solve. MIDCOM itself is very narrowly scoped, so if we reduce
everything to stuff strictly in scope, all the pictures look
like this:

     +----------+                  +---------------+
     | MIDCOM   |    MIDCOM        | Middlebox     |
     |  Agent   |<---------------->|               |
     +----------+                  +---------------+

> policy between the middlebox and policy server or can it be the same as

	My opinion is that this is a separate protocol, and that
it's out of scope for MIDCOM. Again, policy servers and whatnot
are indicated, I think, to show scope. Also to quell that population
of MIDCOM participants who would wonder why a policy element was
NOT indicated, if it was not.

	Would it be helpful to update the framework document to
more clearly delineate the difference between stuff that's context,
and stuff that's In Scope? I don't find any problem distinguishing
myself, but I may well be way to close to it to judge.

	There is certainly no shortage of policy lookup protocols
available.

> What is clear is that the midcom protocol itself must be a "mother may i"

	I am unclear on what exactly this means.. If it means what I
think it might mean, I concur, but I could be wrong!

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 17 May 2001 14:35:10 -0400

>From: Andrew Molitor <[email-masked]>
> it's out of scope for MIDCOM. 

I guess the charter is not completely clear on your first
opinion but I do think that it's quite clear on the second.
From the charter:

The deliverables will be 
[ ... ]
o a document describing the requirements for a policy enity 

Elliot is quite correct that the midcom protocol itself
is a 'mother may I' kind of a thing - that's why we're
"middlebox communication" and not "middlebox control."

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 17 May 2001 19:45:38 -0700 (PDT)

--- Eliot Lear <[email-masked]> wrote:
> Nice pictures.  

Thanks.

>                 Still, I thought we had agreed in March that the
> requirements for a MIDCOM protocol.

I dont recall that. My own recollection is that folks felt Out-of-Path
agent description was not adequate and needed clearer explanation so
the distinction between In-Path and Out-of-Path agents is clearer.
That was why we spent so much effort trying to get the text on 
out-of-path agent clearer and used a timeline to illustrate the same.

>                                      The drawings in the draft even 

Which diagrams are you refering to? Did you mean figures 2 & 3? 
And, the timeline flow in section 8.1? Yet, you dont see the difference
between In-Path agent and OOP agent connections with middlebox?

> be an internal mechanism of the middle box.  What am I missing?
Sure, diversion would clearly be an internal component of the middlebox.
This component is required only as the middlebox interfaces with an
out-Of-path agent. This component is not required while interfacing
with the an In-path agent.

For an In-Path agent, Middlebox does not make divert the datagrams. 
The in-path entity terminates the packet session, after all.

> policy between the middlebox and policy server or can it be the same as

Section 2.9 explicitly states that the protocol facilitating the 
communication between a middlebox and Policy Server need not be 
part of MIDCOM protocol. 

> clear is that there is no requirement that the protocols be the same, and

Yes.

> there is no need to proceed on the basis that this is in fact true.  Thus,

Yes.

> the side of the middlebox.

I assume, you are refering to figure 1. Are you saying it is visually
better to place Policy Server to the side of middlebox. I had it that way
originally; and some folks wanted to see end-hosts by the sides. 
Well, there is only so much space that draft formatting allows.

Anyways, I dont believe, the diagram violates section 2.9 in any way.
So, why not leave the diagram as is. Thanks. 

> What is clear is that the midcom protocol itself must be a "mother may i"

cheers,
suresh

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 May 2001 06:45:08 -0700

Pyda,

Let me be a bit more clear.  You've chosen to take on this notion of
Out-of-Path middleboxes.  While such boxes *MAY* have their place, what
you're essentially saying is, "punt the packet to an ALG if you don't know
how to process it".  Only to do what you suggest requires lots more than
just a MIDCOM protocol- it requires policy-based routing or source-based
routing.  And it is not possible to do without additional interfaces
(either real or tunneled) if you are not modifying the packet.  Such
constrained topology requirements will make for high MTTR when things go
wrong.  Why go down this route at all?  Does this part of the requirement
offer you great utility?

> communication between a middlebox and Policy Server need not be

Right, but I would make the statement more emphatically.  Not only will it
"need not be", but that we will separately consider requirements for such
a protocol (hopefully briefly, since it looks like any other policy
issue).  In short, I want to cut short requirements discussion for policy
protocols when discussing requirements for MIDCOM protocols.
 
> Well, there is only so much space that draft formatting allows.

Actually, all I was suggesting was starting the line from the side, not
moving the box.  I didn't count columns to know if ASCII art would allow
you to do this.  If it does not, you want to make it clear that the policy
server is not using MIDCOM by drawing a dividing line, going north.  If it
would help I can send you a suggestion.
--
Eliot Lear
[email-masked]

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 18 May 2001 11:10:37 -0400

> protocols when discussing requirements for MIDCOM protocols.

You're correct in this regard, but I would add that we
need to think about the policy *data*.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 May 2001 12:11:46 -0500

> need to think about the policy *data*.

Maybe a bit more abstract - at least an informal policy model, even if you
don't want to go as far as the formal models of the POLICY WG. In any case
there is enough policy distribution work elsewhere in the IETF (SNMPCONF,
RAP) that it certainly shouldn't be a job for midcom.

  Brian