Subject: RE: [midcom] framework models, related architectures and protocol controversy

From: "Moisand, Jerome" <[email-masked]>
Date: Wed, 4 Dec 2002 18:34:16 -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
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

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 05 Dec 2002 09:50:06 +0100

Jerome,

> 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