Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt

From: "Cedric Aoun" <[email-masked]>
Date: Fri, 29 Jun 2001 13:20:42 +0100

John,
We all agree that the Middle Box is a policy enforcement point, but 
there is no need to define a PHB on per call, the main purpose of Diffserv
is to do traffic prioritization and assign a behavior for certain type of
traffic classified
by the flow priority (the DSCP in our case).
These PHBs are on the MB either by manual config or
by propping down policies from a Policy Decision Point.
I don't see the need to discuss that in the context of MIDCOM. 
I see bandwidth reservation functions required on low bandwidth access link
interface, where the access interface is 
between 2 Middle Boxes and the agent requires the bandwidth to be reserved
prior to establishing the call.
But let's focus on Firewalls and NAT for IETF51, we need to finish the
documents ...
Cedric
-----Original Message-----
From: John Ladwig [mailto:[email-masked]]
Sent: Friday, June 29, 2001 7:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [midcom] Re: draft-ietf-midcom-requirements-01.txt

> 
> >   9.     Resource control requirements
> ...
> >          The Middlebox may provide QoS transport facilities for packet
flows, 
> >          for example, by setting DS-bytes or MPLS mappings. 
> 
> I think this is wrong in general, and it is certainly wrong in the
> reference to diffserv.
> 
> Firstly the correct phrase is "DS code points" and they are 6 bits long, 
> not a byte. The reference is RFC 2474.
> 
> However, diffserv shouldn't be mentioned at all (see my previous comment
> on the scenarios). Diffserv management is complicated enough already,
> and we shouldn't add midcom to the mix.

But isn't a middlebox useful as an enforcement point for whatever management
you wish to implement?

> I am very doubtful in general whether midcom should go near QOS
management, so
> personally I would remove the MPLS reference too. Do you seriously want
hosts
> hidden behind a firewall to know about MPLS mappings used by some ISP???

Putting my ISP hat on for a moment, I *very much* want to have the middlebox
able to implement MPLS labeling on traffic so that packets may be steered 
along provisioned/quality-engineered pathways through my infrastructure,
to the midcom agent's specifications and policies.

Why don't/wouldn't you?

Apologies if this has been said, or obsoleted; I'm playing catch-up on the 
discussion points.

    -jml

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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 29 Jun 2001 09:10:04 -0400

----- Original Message -----
From: "Cedric Aoun" <[email-masked]>
To: "'John Ladwig'" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, June 29, 2001 8:20 AM
Subject: RE: [midcom] Re: draft-ietf-midcom-requirements-01.txt

> I don't see the need to discuss that in the context of MIDCOM.

I disagree. The idea is that a midcom agent be able to "assign" one of these
established PHBs to a flow it is enabling thru the middlebox. I don't think
anybody wants to use MIDCOM to define PHBs. We just need to be able set the
priority for a flow that would otherwise get ordinary best-efforts
treatment.

---

From: "Melinda Shore" <[email-masked]>
Date: Fri, 29 Jun 2001 10:04:08 -0400

> From: Bob Penfield <[email-masked]>
> To: Cedric Aoun <[email-masked]>; 'John Ladwig' <[email-masked]>; 
> [email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, June 29, 2001 9:10 AM

> priority for a flow that would otherwise get ordinary best-efforts

We need to leave open the possibility that someone could use midcom
to do that, but really, let's stick with the firewall/NAT questions.

Melinda