Re: [PCN] lets try again - a chair asking this time
<philip.eardley@bt.com> Wed, 21 March 2012 11:20 UTC
Return-Path: <philip.eardley@bt.com>
X-Original-To: pcn@ietfa.amsl.com
Delivered-To: pcn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C137A21F8639 for <pcn@ietfa.amsl.com>; Wed, 21 Mar 2012 04:20:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.447
X-Spam-Level:
X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me+67f9PUXko for <pcn@ietfa.amsl.com>; Wed, 21 Mar 2012 04:20:28 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF7221F8601 for <pcn@ietf.org>; Wed, 21 Mar 2012 04:20:28 -0700 (PDT)
Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 11:20:26 +0000
Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 21 Mar 2012 11:20:26 +0000
From: philip.eardley@bt.com
To: Ruediger.Geib@telekom.de, sob@harvard.edu
Date: Wed, 21 Mar 2012 11:20:28 +0000
Thread-Topic: lets try again - a chair asking this time
Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+5Z0XZ2QgAA833A=
Message-ID: <9510D26531EF184D9017DF24659BB87F331D442F31@EMV65-UKRD.domain1.systemhost.net>
References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com>
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: pcn@ietf.org
Subject: Re: [PCN] lets try again - a chair asking this time
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Mar 2012 11:20:29 -0000
Good spot! To me, either drop or re-mark to Best effort seem ok. I can see bob's argument that it is nicer internet behaviour to treat as best effort than to drop. Adding a mgt alert seems very good. Since it does indeed differ from pcn architecture, i guess it needs a statement in the 'header' "Modifies 5559" and something in the Intro (?) that states which para of 5559 is modified in what way. -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Ruediger.Geib@telekom.de Sent: 21 March 2012 08:08 To: sob@harvard.edu Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time Hi Scott, the passage you quote should result from a misconfiguration or an attack. Treatment of non-PCN-packets confused with a PCN-packet due to DSCP/ECN codepoinzt setting: ... In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. ... Clearing the ECN field is not an appropriate policing action, because a network node ought not to interfere with an e2e signal. Even if such packets seem like an attack, drop would be overkill, because such an attack can be neutralised by just re-marking the DSCP. And DSCP re-marking in the network is legitimate, because the DSCP is not considered an e2e signal. What's done here is remarking of a flow with a DSCP that has been agreed between two parties. On a consumer UNI, this may be an attack, on an NNI, this could indicate a misconfiguration. In the latter case, a management alert seems reasonable. Text to that may be added. I further quote the PCN architecture, which is informational, on the Ingress Node behaviour: Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Similarly, police packets that are part of a previously admitted flow, to check that the flow keeps to the agreed rate or flowspec (eg, see [RFC1633] for a microflow and its NSIS equivalent). This isn't in line with the proposed 3-in-1 (standards track) behaviour. Does this require an "Errata" atatement for RFC5559 (I'm not an expert on editing RFCs and may be wrong here)? Regards, Ruediger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Bradner, Scott Sent: Tuesday, March 20, 2012 5:37 PM To: pcn@ietf.org Subject: [PCN] lets try again - a chair asking this time please let the list know what you think Scott Scott O Bradner Senior Technology Consultant Begin forwarded message: Date: Mon, 12 Mar 2012 03:30:11 +0000 To: "PCN IETF list" <pcn@ietf.org> From: Bob Briscoe <bob.briscoe@bt.com> Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt PCN folks, Following IESG review (particularly Adrian Farrel's being the most comprehensive and useful), we've posted a new version of the PCN 3-in-1 encoding. As well as a number of editorial changes, some technical changes were needed in order to satisfy Adrian's request to specify exactly what an implementer has to do at the ingress to allow ECN to co-exist with PCN, and what defaults should be set to. In particular, for a non-PCN packet (i.e. doesn't match any flow-state) that clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 is: * re-mark the DSCP to a DSCP that is not PCN-compatible; [...] In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. Actually, the whole of the ingress behaviour section (5.1) has been re-written, incorporating material that was previously repeated in both edge-behaviours (agreed with IESG and with edge-behaviour authors, of course). Altho it largely does the same thing technically, it is written to cover the complete range of possible scenarios, and it now gives defaults and recommended choices. I don't think it's controversial, but shout if it is. < http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 <http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1> > Bob PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: * Added note about fail-safe to protect other traffic in the event of tunnel misconfiguration. * Changed section heading to be about applicability of environments to the encoding, rather than the encoding to the environments. * Completely re-wrote PCN-ingress Node Behaviour section. * Changed PCN interior node to PCN-node where the term was intended to include all PCN-nodes. * Clarified status of ECN/PCN co-existence appendix. Removed inconsistent assertion in this appendix that an admission- control DSCP alone can indicate that arriving traffic is PCN- traffic. * A few clarifying editorial amendments and updated refs. From: <internet-drafts@ietf.org> To: <pcn-chairs@tools.ietf.org>, <draft-ietf-pcn-3-in-1-encoding@tools.ietf.org>, <ietfdbh@comcast.net>, <adrian@olddog.co.uk>, <rjsparks@nostrum.com> Date: Sun, 11 Mar 2012 17:52:23 -0700 Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.txt. http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09 IETF Secretariat. ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn
- [PCN] lets try again - a chair asking this time Bradner, Scott
- Re: [PCN] lets try again - a chair asking this ti… philip.eardley
- Re: [PCN] lets try again - a chair asking this ti… Toby Moncaster
- Re: [PCN] lets try again - a chair asking this ti… karagian
- Re: [PCN] lets try again - a chair asking this ti… James M. Polk
- Re: [PCN] lets try again - a chair asking this ti… Michael Menth
- Re: [PCN] lets try again - a chair asking this ti… Ruediger.Geib
- Re: [PCN] lets try again - a chair asking this ti… philip.eardley
- Re: [PCN] lets try again - a chair asking this ti… philip.eardley
- Re: [PCN] lets try again - a chair asking this ti… Bob Briscoe
- Re: [PCN] lets try again - a chair asking this ti… Bob Briscoe
- Re: [PCN] lets try again - a chair asking this ti… Bradner, Scott
- Re: [PCN] lets try again - a chair asking this ti… Bob Briscoe
- Re: [PCN] lets try again - a chair asking this ti… Bradner, Scott
- Re: [PCN] lets try again - a chair asking this ti… Michael Menth
- Re: [PCN] lets try again - a chair asking this ti… Ruediger.Geib
- Re: [PCN] lets try again - a chair asking this ti… philip.eardley
- Re: [PCN] lets try again - a chair asking this ti… Toby Moncaster
- Re: [PCN] lets try again - a chair asking this ti… karagian
- Re: [PCN] lets try again - a chair asking this ti… Bob Briscoe
- Re: [PCN] lets try again - a chair asking this ti… Michael Menth
- Re: [PCN] lets try again - a chair asking this ti… Bob Briscoe