Subject: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies

From: <[email-masked]>
Date: Tue, 15 Mar 2011 15:43:27 +0100

Re-,
 
Since the CGN nodes will be introduced into service providers networks, some QoS functions are required:
 
* Set the value of DSCP field (default behaviour)
* Ability to configure DSCP re-marking policies
* For the DS-Lite case, some extra functions are required to map between the contents of the Differentiated Services field of the IPv4 header and the Differentiated Services field of the IPv6 header for downstream traffic (vice versa).
* Support of DiffServ capabilities (traffic classification and marking, traffic conditioning and scheduling, traffic discarding)
* Etc.

Cheers,
Med

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 08:51:11 -0400

On 2011-03-15 10:43, [email-masked] wrote:
> Since the CGN nodes will be introduced into service providers
> networks, some QoS functions are required:
> 
> * Support of DiffServ capabilities (traffic classification and
> marking, traffic conditioning and scheduling, traffic discarding)

Why should QoS capabilities be required of a CGN and not of a normal router?

> * For the DS-Lite case, some extra functions are required to map
> between the contents of the Differentiated Services field of the IPv4
> header and the Differentiated Services field of the IPv6 header for
> downstream traffic (vice versa).

This this is specific to DS-Lite, I think it should go in
draft-ietf-softwire-dual-stack-lite instead.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 15:06:06 +0100

Dear Simon,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 16 mars 2011 13:51
À : [email-masked]
Objet : Re: [BEHAVE] CGN REG: Diffserv and DSCP marking/re-marking policies

Med: You point is valid when the CGN function is embedded in a CGN but a CGN function may be embedded in a standalone device (not a router); hence the need to support those functions.

Med: The DS-Lite Spec does not elaborate on how NAT is done and in particular for the DSCP marking of NATed packets. This IMO should be handled in the CGN I-D.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 11:16:48 -0400

On 2011-03-16 10:06, [email-masked] wrote:
> Med: You point is valid when the CGN function is embedded in a CGN
> but a CGN function may be embedded in a standalone device (not a
> router); hence the need to support those functions.

You missed my point.

I'm not saying that QoS capabilities are in routers, and a CGN is a
router, therefore it has QoS for free. That's not my point.

What I'm saying is that if an ISP wants a router, and requires QoS from
that router, it just buys a router with QoS. There is no document in the
IETF saying that all routers need QoS. Change "router" with "CGN" and
you have an identical situation.

To me, it looks like QoS should be a bullet in an RFP...

Simon