Subject: RE: [midcom] framework models, related architectures , etc

From: "Moisand, Jerome" <[email-masked]>
Date: Fri, 6 Dec 2002 16:12:40 -0500

Juergen,

yes, I absolutely agree with you.

Practically speaking, I tend to believe the most typical scenario is a WAN
uplink and a middlebox (and related agent) on either side (CPE gear used by
enterprise or Edge Router used by Telco). Or an uplink between an access
provider and an ISP. Then the topology is constrained enough that this
"awareness" you mentioned is easy to achieve. And such "specific" scenario
is rather common, to say the least (we all love broadband, don't we? ;-)

I can see a couple of other scenarios with some reality on the field, but
they are more contorted. Of course, they will all share the property you
described. If somebody has another pretty common scenario in mind, I'm
interested to be educated!

This being said, I do agree with what Melinda stated in another e-mail. When
promoting the use of "off-path" signaling and then an application
endpoint/proxy of some sort pushing some policy rule on some "middlebox" on
the data path, one can sometimes forget about the difficulty to locate the
proper middlebox to act on. This only works for specific scenarios &
topologies. Yet I continue to believe these scenarios are important enough
that it's definitely worth the effort to develop good mechanisms for it.

Tx
Jerome

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 3:50 AM
To: Moisand, Jerome; [email-masked]'
Subject: RE: [midcom] framework models, related architectures and
protocol controversy 

Jerome,

-- Moisand, Jerome wrote on 04 December 2002 18:34 -0500:

>
> Melinda,
>
> yes, I don't disagree with you, scenarios where a middlebox of some sort
> would have to be dynamically provisioned for a given TCP/RTP session are
> making VERY SPECIFIC assumptions about the IP topology. It looks to me
that

I'd like to clarify this "very specific" you used.
The way I see it, the assumption is quite simple:

   The the set of agents involved in provisioning a given session needs
   to be aware of all relevant middleboxes that need to be configured for
   provisioning the session.

The awareness may be shared in a way that each involved agent is only aware
of a subset of the relevant middleboxes.

I agree that this does not match the general idea behind the Internet
architecture. It is much closer to telco-style architectures.

    Juergen

> the only realistic scenarios are at a domain boundary, typically the point
> where a service provider provides IP services (e.g. a WAN uplink). Then,
> either on the service user side (e.g. a NAT/FW CPE device) or on the
service
> provider side (e.g. a BRAS device), the topology is constrained enough
that
> such scenario makes sense.
>
> This being said, such specific scenarios are so important to both service
> users and service providers that I believe it's really the pain working on
> such middlebox/dynamic-session-management stories. And as I pointed out,
the
> whole picture involves filtering, NATting, firewalling and Qos
> differentiation.
>
> As to scaling, I hear the concern, but I'm not sure to entirely agree with
> you. There are solutions nowadays which can scale pretty well by the
> appropriate combinations of hardware & software.
>
> Finally, on the "protocol controversy" wording, I apologize if my wording
> was a bit too aggressive. I have to say I'm a bit tired of the endless
> discussion between SNMP, Diameter, COPS across multiple IETF work groups.
I
> tend to believe that all these protocols have a role to play, and we'd
> better be flexible, and define MIBs, PIBs and Diameter attributes for
> multiple functional areas (ok, when this makes "reasonable" sense, of
> course, which is hard to define!), instead of spending too much time
arguing
> in an often religious way. I hope that I'll not get a flame on this
> hopefully neutral statement...   ;-)
>
> Ok, all this philosophy aside, I vote for Megaco for Midcom. Nah, just
> kidding.
>
> Tx
> Jerome
>
>> One of the unfortunate things that's happened in the IETF
>> over the past <n> years is the drift away from architectural
>> frameworks that are idiomatic to IP - i.e. they interwork
>> with IP, particularly routing and topology, really, really
>> poorly.  I personally think that midcom is one of these, but
>> even if we were to go to end-to-end, on-path signaling
>> there's a need to have application endpoints (or proxies,
>> another can of worms) communicate directly with various
>> sorts of individual middleboxes which may not be on a data
>> path (or cannot be "known" to be on one).
>>
>> The notion of having devices in the network make
>> determinations and push those out to the endpoints has the
>> smell of Bell about it.  It's typically not something that
>> will work well in IP networks, where making network elements
>> visible to application endpoints can create a host of
>> problems, ranging from lack of robustness to inter-layer
>> duplication of function to inability to scale with the
>> number of endpoints.
>>
>> By the way, I don't think there is an "ongoing protocol
>> controversy."  There's been very little discussion at all.
>> If there's lack of progress it's because of lack of input,
>> not because participants in the working group are at
>> loggerheads.
>>
>> Melinda
>> _______________________________________________
>> midcom mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/midcom
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom

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