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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2001 17:14:19 -0500

In section 5.2.1 (pinhole specification)

>                  For IPv4:   source and destination IP address or group of 
>                              them determined by a netmask, protocol number, 
>                              TOS field 

This should be "differentiated services code point" since RFC 2474 updates RFC 791,
and you have to be very careful to exclude the ECN bits.

>                     
>                  For IPv6:   source and destination IP address or group of 
>                              them determined by a netmask, next header fields 
>                              (Note: multiple fields may need to be traversed 
>                              until a match is found)and traffic class field 

I think the IPv6 Flow Label needs to be included too.

   Brian

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2001 17:13:50 -0500

>   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.

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???

   Brian

---

From: John Ladwig <[email-masked]>
Date: Fri, 29 Jun 2001 00:06:44 -0500 (CDT)

> 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?

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jun 2001 08:59:23 -0500

> But isn't a middlebox useful as an enforcement point for whatever management

It might be, but then it should use the regular diffserv configuration
mechanisms (COPS, SNMPCONF). The last thing we need is yet another way
of doing it.

> to the midcom agent's specifications and policies.

So, you think it is an appropriate mixing of function to have the mechanism that
controls NAT and firewall penetration also used as a traffic engineering
tool? I think this is really using a hammer to operate a screw. It feels
*dead wrong* to mix these things up, and it is clearly charter-creep as far
as midcom is concerned.

> Why don't/wouldn't you?

Because we should keep things separate whenever possible. Simple and modular
is better than complex and monolithic.

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

Me too.

   Brian