RE: Draft on Callout Protocol Requirements

-----Original Message-----
From: Maciocco, Christian 
[mailto:christian(_dot_)maciocco(_at_)intel(_dot_)com]
Sent: Wednesday, November 28, 2001 2:22 PM
To: 'Ian Cooper'; ietf-openproxy(_at_)imc(_dot_)org
Cc: Phil Rzewski; Penno, Reinaldo [SC9:T327:EXCH]
Subject: RE: Draft on Callout Protocol Requirements

I agree with Ian. An OPES service needs to be explicitely 
requested and must
not brake the end-to-end connection. The place to do this is 
on proxies the
client connects to, where the connections are terminated.

I don't see OPES services working out of an L3 sniffer kind of device.


Right, but that doesn't mean some vendor will not do it. OPES is a logical
entity, it can run in an appliance or in a router. It can run in a
edge/access router (or even in a DSL Router in somebody's home) and still
meet all the requirements. 

regards,

-RP


Christian

-----Original Message-----
From: Ian Cooper [mailto:ian(_at_)the-coopers(_dot_)org]
Sent: Wednesday, November 28, 2001 11:22 AM
To: ietf-openproxy(_at_)imc(_dot_)org
Cc: Phil Rzewski; Reinaldo Penno
Subject: RE: Draft on Callout Protocol Requirements

OK, it looks like the confusion here goes back to assumptions 
of what the 
phrase "IP connectivity" means - something I decided to not 
comment on 
earlier.

The point seems to be that you either have a content

network in place

before you overlay an OPES environment on it, or that you 
install a content 
network by installing an OPES environment box or boxes (the 
confusion here 
can probably summarized as "what is OPES?").  In the latter 
case, so far as 
you "only need IP connectivity" to do this, you're pretty 
much right.  But 
I don't think you can have OPES services without having some 
application 
layer intermediary/host on which to run them.  For example, 
my initial take 
on the "only need IP connectivity" point suggested you might 
be thinking of 
putting OPES services in something like a (L3) router... 
which is a big 
no-no.

--On Tuesday, November 27, 2001 16:26 -0800 Phil Rzewski 
<philr(_at_)inktomi(_dot_)com> wrote:


At 03:22 PM 11/27/2001 -0800, Reinaldo Penno wrote:

-----Original Message-----
From: Phil Rzewski
[<mailto:philr(_at_)inktomi(_dot_)com>mailto:philr(_at_)inktomi(_dot_)com]

Sent: Monday,

November 26, 2001 11:34 AM
To: Penno, Reinaldo [SC9:T327:EXCH]
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: Draft on Callout Protocol Requirements

<snip>


In brief, we know that in the routed world, once you put two
host machines on
the same ethernet wire, you technically have a "network". As
"networks" go,
it's on a whole different scale than one operated by AT&T or
the IT department
at your local enterprise, but this is why we have terms like
"public backbone
network", "LAN", "VPN", etc. Similarly, we would argue that
once you add ANY
proxy ("forward" or "reverse") you have created a type of
Content Network.


okay, I can agree with that since it actually adds to my

point that to

have OPES you only need
IP connectivity, nothing else. You do not need an CN (and

not by a long

shot a CDN) overlay network in place BEFORE you install

OPES devices.



I'm not sure how you get that from what I said, though

maybe I'm failing

to understand something. Back when I was first tracking OPES, the
services were assumed to be provided by either proxylets or

callouts to

external boxes. The device that was making those callouts

or calling

those proxylets was typically described as being a

surrogate or proxy of

some kind. If that's still true (is it not?), then by my

definition, you

WOULD have a Content Network before you layer OPES

proxylets/callouts on

top of it.


You end up having a CN (not an CDN) overlay network AFTER

you install an

OPES

device.



This I'd agree with, but I'm agreeing with the literal

statement. :)

That is, I'd say that any network that contains OPES services is a
Content Network (I think it had to be before you added the

OPES services,

even). It may be a CDN, since a CDN is just a specific type

of Content

Network. That's determined by whether it contains components like
distribution, request routing, etc.

--
Phil Rzewski - Senior Architect - Inktomi Corporation
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)