RE: [PCN] I-D Action:draft-ietf-pcn-architecture-01.txt
"Geib, Ruediger" <Ruediger.Geib@t-systems.com> Thu, 22 November 2007 12:09 UTC
Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvArv-0000SE-MK; Thu, 22 Nov 2007 07:09:19 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IvAru-0000NS-2u for pcn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 07:09:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvArt-0000Hl-50 for pcn@ietf.org; Thu, 22 Nov 2007 07:09:17 -0500
Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvArq-0006MV-Ef for pcn@ietf.org; Thu, 22 Nov 2007 07:09:17 -0500
Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 22 Nov 2007 13:09:12 +0100
Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Nov 2007 13:09:12 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PCN] I-D Action:draft-ietf-pcn-architecture-01.txt
Date: Thu, 22 Nov 2007 13:09:12 +0100
Message-Id: <1B6169C658325341A3B8066E23919E1C4C14EE@S4DE8PSAANK.mitte.t-com.de>
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34396@E03MVZ1-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-architecture-01.txt
Thread-Index: AcgqxqGl81rUg3oXSxKQPQt45B53dQAATG8gAIiSlTAAA42YQAAB5JyQ
From: "Geib, Ruediger" <Ruediger.Geib@t-systems.com>
To: philip.eardley@bt.com
X-OriginalArrivalTime: 22 Nov 2007 12:09:12.0430 (UTC) FILETIME=[7E6BC0E0:01C82D00]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Cc: pcn@ietf.org
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Errors-To: pcn-bounces@ietf.org
Hi Phil, your suggestion is allright with me. I found this sentence in RFC2475: Ingress nodes must condition all other inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or must have their DS codepoints modified to acceptable values before being forwarded. As PCN may also modify ECN codepoints, the staement must be extended to cover these too. If only DSCPs are used, no traffic with "congestion experienced" marking must pass the ingress node unchanged. Regards, Rudiger |All Editorials - thanks will try to put into next version. | |> |> 5.2. PCN-ingress-node functions |> |> "Packet classify" and "Policing" are only required at the |> PCN ingress, if no other trusted edge system is doing that. |> |> If there's another edge system doing policing and |> classification, the PCN ingress node doesn't need |> to do this. | |true. In the scenarios it says: |o If the operator runs both the access network and the core network, | one deployment scenario is that only the core network uses PCN | admission control but per microflow policing is done at the | ingress to the access network and not at the PCN-ingress-node. | Note: to aid readability, the rest of this draft assumes that | policing is done by the PCN-ingress-nodes. | |However, I can add a small comment here & in section 10, as not |mentioning it is hindering rather than aiding readability! | |> |> "Note that packet classify/policing is only required by the |> PCN ingress node, if no other trusted upstream node operates |> these features." |> |> Further, the section misses a statement on what the ingress |> node is supposed to do, if a PCN coloured packet is |> received on an interface where it is not supposed |> to be received (given the flow is admitted): |> Ignore and remark or drop? | |Good point. Can we just refer to some Diffserv text? | |phil | | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn
- [PCN] I-D Action:draft-ietf-pcn-architecture-02.t… Internet-Drafts
- RE: [PCN] I-D Action:draft-ietf-pcn-architecture-… philip.eardley
- RE: [PCN] I-D Action:draft-ietf-pcn-architecture-… philip.eardley
- RE: [PCN] I-D Action:draft-ietf-pcn-architecture-… Jozef Babiarz
- RE: [PCN] I-D Action:draft-ietf-pcn-architecture-… Geib, Ruediger
- RE: [PCN] I-D Action:draft-ietf-pcn-architecture-… philip.eardley
- RE: [PCN] I-D Action:draft-ietf-pcn-architecture-… Geib, Ruediger
- RE: [PCN] I-D Action:draft-ietf-pcn-architecture-… Geib, Ruediger