From internet-drafts@ietf.org Sat Jul 2 13:33:42 2011 Return-Path: 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 2DFD611E80FD; Sat, 2 Jul 2011 13:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz5JeWJn77Js; Sat, 2 Jul 2011 13:33:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD48511E80A6; Sat, 2 Jul 2011 13:33:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110702203341.1177.79346.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2011 13:33:41 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 20:33:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Requirements for Signaling of (Pre-) Congestion Informat= ion in a DiffServ Domain Author(s) : Georgios Karagiannis Tom Taylor Kwok Ho Chan Michael Menth Philip Eardley Filename : draft-ietf-pcn-signaling-requirements-06.txt Pages : 8 Date : 2011-07-02 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the latter case, (2) is not required). The signaling requirements pertain in particular to two edge behaviours, "controlled load (CL)" and "single marking (SM)" [draft-ietf-pcn-cl-edge- behaviour-09], [draft-ietf-pcn-sm-edge-behaviour-06]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-0= 6.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-06= .txt From karagian@cs.utwente.nl Sat Jul 2 13:37:05 2011 Return-Path: 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 AEB7911E80C1; Sat, 2 Jul 2011 13:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPNLK+PQQKoc; Sat, 2 Jul 2011 13:37:05 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id C4A8311E80A6; Sat, 2 Jul 2011 13:37:04 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p62KZWq3016962; Sat, 2 Jul 2011 22:35:32 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sat, 02 Jul 2011 20:37:07 +0000 To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Date: Sat, 02 Jul 2011 20:37:07 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <20110702203341.1177.79346.idtracker@ietfa.amsl.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sat, 02 Jul 2011 22:35:42 +0200 (MEST) Cc: "pcn@ietf.org" Subject: Re: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 20:37:05 -0000 Hi all During the process of specifying the signaling protocol that can be used to support the SM and CL drafts I found that the v.05 PCN signaling requirements draft did not include the following bullet realted to the report associated with the CL edge behaviour. o rate of not-marked PCN-traffic (NM-rate) in octets/second I have updated the PCN signaling requirements draft, including the above bullet. Best regards, Georgios On 7/2/2011, "internet-drafts@ietf.org" wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directori= es. This draft is a work item of the Congestion and Pre-Congestion Notificati= on Working Group of the IETF. > >=09Title : Requirements for Signaling of (Pre-) Congestion Informa= tion in a DiffServ Domain >=09Author(s) : Georgios Karagiannis > Tom Taylor > Kwok Ho Chan > Michael Menth > Philip Eardley >=09Filename : draft-ietf-pcn-signaling-requirements-06.txt >=09Pages : 8 >=09Date : 2011-07-02 > > Precongestion notification (PCN) is a means for protecting quality of > service for inelastic traffic admitted to a Diffserv domain. The > overall PCN architecture is described in RFC 5559. This memo > describes the requirements for the signaling applied within the PCN > domain: (1) PCN-feedback-information is carried from the PCN-egress- > node to the decision point;(2) the decision point may ask the PCN- > ingress-node to measure, and report back, the rate of sent PCN- > traffic between that PCN-ingress-node and PCN-egress-node. The > decision point may be either collocated with the PCN-ingress-node or > a centralized node (in the latter case, (2) is not required). The > signaling requirements pertain in particular to two edge behaviours, > "controlled load (CL)" and "single marking (SM)" > [draft-ietf-pcn-cl-edge- behaviour-09], > [draft-ietf-pcn-sm-edge-behaviour-06]. > > > >A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-06.= txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-06.= txt >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From internet-drafts@ietf.org Sat Jul 2 20:36:41 2011 Return-Path: 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 7011211E8139; Sat, 2 Jul 2011 20:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+ClxlqPqMRa; Sat, 2 Jul 2011 20:36:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA47B11E80BC; Sat, 2 Jul 2011 20:36:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110703033640.30710.15042.idtracker@ietfa.amsl.com> Date: Sat, 02 Jul 2011 20:36:40 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:36:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Requirements for Signaling of (Pre-) Congestion Informat= ion in a DiffServ Domain Author(s) : Georgios Karagiannis Tom Taylor Kwok Ho Chan Michael Menth Philip Eardley Filename : draft-ietf-pcn-signaling-requirements-07.txt Pages : 8 Date : 2011-07-02 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the latter case, (2) is not required). The signaling requirements pertain in particular to two edge behaviours, "controlled load (CL)" and "single marking (SM)" [draft-ietf-pcn-cl-edge- behaviour-09], [draft-ietf-pcn-sm-edge-behaviour-06]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-0= 7.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-07= .txt From slblake@petri-meat.com Sat Jul 2 20:41:54 2011 Return-Path: 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 F1D1A11E8154 for ; Sat, 2 Jul 2011 20:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkkyHHAk0f+G for ; Sat, 2 Jul 2011 20:41:53 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1A611E80B5 for ; Sat, 2 Jul 2011 20:41:52 -0700 (PDT) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1QdDZ8-0000cI-MI; Sat, 02 Jul 2011 23:41:50 -0400 From: Steven Blake To: Georgios Karagiannis In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 Jul 2011 23:41:50 -0400 Message-ID: <1309664510.5084.19.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: "pcn@ietf.org" Subject: Re: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 03:41:54 -0000 On Sat, 2011-07-02 at 20:37 +0000, Georgios Karagiannis wrote: > Hi all > > During the process of specifying the signaling protocol that can be used > to support the SM and CL drafts > I found that the v.05 PCN signaling requirements draft did not include > the following bullet realted to the report associated with the CL edge > behaviour. > > o rate of not-marked PCN-traffic (NM-rate) in octets/second > > I have updated the PCN signaling requirements draft, including the above > bullet. Hi, I just submitted draft-ietf-pcn-signaling-requirements-07.txt to correct one nit in -06 (pg. 2 too long). I have also (finally) completed the document shepherd write-ups for this draft and draft-pcn-encoding-comparison-06, which are now submitted to the IESG. I will be posting a proposed meeting agenda for IETF 81 tomorrow. Regards, // Steve From karagian@cs.utwente.nl Sun Jul 3 00:00:26 2011 Return-Path: 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 103AF11E8079 for ; Sun, 3 Jul 2011 00:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkcSt3cYAk5P for ; Sun, 3 Jul 2011 00:00:25 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2D21F8763 for ; Sun, 3 Jul 2011 00:00:25 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p636wrgo014414; Sun, 3 Jul 2011 08:58:53 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Jul 2011 07:00:29 +0000 To: "Steven Blake" Date: Sun, 03 Jul 2011 07:00:29 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1309664510.5084.19.camel@tachyon> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Jul 2011 08:59:02 +0200 (MEST) Cc: "pcn@ietf.org" Subject: Re: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:00:26 -0000 Hi Steve, Regarding version v06 of signaling requirements draft, I have used the nits tool (with all checking options set), see below, and there were no errors or warnings. I do not understand how these warning or error (long page warning or error) appear after submission! The tool I used before submission can be found via: http://tools.ietf.org/tools/idnits/ Best regards, Georgios On 7/3/2011, "Steven Blake" wrote: >On Sat, 2011-07-02 at 20:37 +0000, Georgios Karagiannis wrote: > >> Hi all >> >> During the process of specifying the signaling protocol that can be used >> to support the SM and CL drafts >> I found that the v.05 PCN signaling requirements draft did not include >> the following bullet realted to the report associated with the CL edge >> behaviour. >> >> o rate of not-marked PCN-traffic (NM-rate) in octets/second >> >> I have updated the PCN signaling requirements draft, including the above >> bullet. > >Hi, > >I just submitted draft-ietf-pcn-signaling-requirements-07.txt to correct >one nit in -06 (pg. 2 too long). I have also (finally) completed the >document shepherd write-ups for this draft and >draft-pcn-encoding-comparison-06, which are now submitted to the IESG. > >I will be posting a proposed meeting agenda for IETF 81 tomorrow. > > >Regards, > >// Steve From karagian@cs.utwente.nl Sun Jul 3 00:19:38 2011 Return-Path: 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 4149721F87D2 for ; Sun, 3 Jul 2011 00:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.019 X-Spam-Level: X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FTqK9uSNs1U for ; Sun, 3 Jul 2011 00:19:37 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8B21F87D3 for ; Sun, 3 Jul 2011 00:19:36 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p637HwXQ016832; Sun, 3 Jul 2011 09:17:58 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Jul 2011 07:19:34 +0000 To: "Steven Blake" Date: Sun, 03 Jul 2011 07:19:33 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1309664510.5084.19.camel@tachyon> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Jul 2011 09:18:07 +0200 (MEST) Cc: "pcn@ietf.org" Subject: Re: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:19:38 -0000 Hi Steve, Please note that before tomorrow's deadline, I will submit the following draft, which I would also like to present during the pcn meeting! Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 and IPv6 Reservations over PCN domains draft-karagiannis-pcn-tsvwg-RSVP-PCN-00 Best regards, Georgios On 7/3/2011, "Steven Blake" wrote: >On Sat, 2011-07-02 at 20:37 +0000, Georgios Karagiannis wrote: > >> Hi all >> >> During the process of specifying the signaling protocol that can be used >> to support the SM and CL drafts >> I found that the v.05 PCN signaling requirements draft did not include >> the following bullet realted to the report associated with the CL edge >> behaviour. >> >> o rate of not-marked PCN-traffic (NM-rate) in octets/second >> >> I have updated the PCN signaling requirements draft, including the above >> bullet. > >Hi, > >I just submitted draft-ietf-pcn-signaling-requirements-07.txt to correct >one nit in -06 (pg. 2 too long). I have also (finally) completed the >document shepherd write-ups for this draft and >draft-pcn-encoding-comparison-06, which are now submitted to the IESG. > >I will be posting a proposed meeting agenda for IETF 81 tomorrow. > > >Regards, > >// Steve From karagian@cs.utwente.nl Sun Jul 3 00:40:59 2011 Return-Path: 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 EE46221F8763; Sun, 3 Jul 2011 00:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMn0FOb4NHJb; Sun, 3 Jul 2011 00:40:59 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 4B55721F874C; Sun, 3 Jul 2011 00:40:59 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p637dLnh021160; Sun, 3 Jul 2011 09:39:21 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Jul 2011 07:40:57 +0000 To: "Steven Blake" , jmpolk@cisco.com, gorry@erg.abdn.ac.uk Date: Sun, 03 Jul 2011 07:40:57 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Jul 2011 09:39:32 +0200 (MEST) Cc: "pcn@ietf.org" , tsvwg@ietf.org Subject: [PCN] agenda slot for Aggregated RSVP over PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 07:41:00 -0000 Hi Steve, Hi Gorry, Hi James Please note that before tomorrow's deadline, I will submit the following draft, which I would also like to present during the pcn and tsvwg meetings. Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 and IPv6 Reservations over PCN domains draft-karagiannis-pcn-tsvwg-RSVP-PCN-00 It will be great if I could get for each of the meetings (PCN and tsvwg) a 20 minutes agenda slot. Best regards, Georgios From karagian@cs.utwente.nl Sun Jul 3 10:25:01 2011 Return-Path: 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 BA1F321F86BC; Sun, 3 Jul 2011 10:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj0cu6wekc2H; Sun, 3 Jul 2011 10:25:01 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0013121F86BA; Sun, 3 Jul 2011 10:25:00 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p63HNQ7j021355; Sun, 3 Jul 2011 19:23:26 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 03 Jul 2011 17:25:02 +0000 To: "pcn@ietf.org" , "tsvwg@ietf.org" Date: Sun, 03 Jul 2011 17:25:02 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Sun, 03 Jul 2011 19:23:37 +0200 (MEST) Subject: [PCN] uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 17:25:01 -0000 Hi all, I have just uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-00, see: http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-00.txt Filename: draft-karagiannis-pcn-tsvwg-rsvp-pcn Revision: 00 Title: Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 19 Abstract: This document specifies the extensions to the Aggregated RSVP [RFC3175] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. Comments are welcome! It will be great if I could get for each of the meetings (pcn and tsvwg) a 20 minutes agenda slot to present this draft! Best regards, Georgios On 7/3/2011, "Georgios Karagiannis" wrote: >Hi Steve, Hi Gorry, Hi James > >Please note that before tomorrow's deadline, I will submit the following >draft, which I would also like to present during the pcn and tsvwg >meetings. > >Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 and > IPv6 Reservations over PCN domains > draft-karagiannis-pcn-tsvwg-RSVP-PCN-00 > >It will be great if I could get for each of the meetings (PCN and tsvwg) >a 20 minutes agenda slot. > >Best regards, >Georgios From slblake@petri-meat.com Sun Jul 3 11:49:12 2011 Return-Path: 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 63C2C11E809E for ; Sun, 3 Jul 2011 11:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7KBwGZWSDAy for ; Sun, 3 Jul 2011 11:49:11 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6611E809B for ; Sun, 3 Jul 2011 11:49:11 -0700 (PDT) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1QdRj8-0003NB-6p for pcn@ietf.org; Sun, 03 Jul 2011 14:49:06 -0400 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-8my/7YWPLU4R7hfz3tSh" Date: Sun, 03 Jul 2011 14:49:10 -0400 Message-ID: <1309718950.32690.3.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] IETF-81 proposed agenda X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 18:49:12 -0000 --=-8my/7YWPLU4R7hfz3tSh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, Here is a proposed agenda for the WG meeting in Quebec City. Note that PCN only has a one-hour slot, but since it comes at the end of the afternoon sessions, it may be possible to spill over into the break. We need someone to lead the discussion of the 3-in-1 and edge behaviour drafts so that they can go (back) to the IESG. Please send comments to the list. Regards, // Steve --=-8my/7YWPLU4R7hfz3tSh Content-Disposition: attachment; filename="proposed-pcn-ietf81-agenda.txt" Content-Type: text/plain; name="proposed-pcn-ietf81-agenda.txt"; charset="UTF-8" Content-Transfer-Encoding: 7bit Congestion and Pre-Congestion Notification WG (pcn) IETF 81 Meeting Agenda CHAIRs: Scott Bradner Steven Blake (Absent) MONDAY, July 25, 2011 1510-1610 Afternoon Session II 204 B ==================================== AGENDA: o Administrivia chairs 5 min - Blue sheets - Scribe - Agenda bash - Milestones status o Resolving issues with CL and SM Edge Behaviour Drafts TBD 25 min draft-ietf-pcn-cl-edge-behaviour-09 draft-ietf-pcn-sm-edge-behaviour-06 o Resolving Issues with 3-in-1 Encoding Draft TBD 15 min draft-ietf-pcn-3-in-1-encoding-05 o Aggregation of RSVP over PCN Domains Karagiannis 15 min draft-karagiannis-pcn-tsvwg-rsvp-pcn-00 o WG futures break --=-8my/7YWPLU4R7hfz3tSh-- From tom111.taylor@bell.net Sun Jul 3 12:20:24 2011 Return-Path: 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 AE29A11E80A0 for ; Sun, 3 Jul 2011 12:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.418 X-Spam-Level: X-Spam-Status: No, score=-101.418 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MvDva+5As5o for ; Sun, 3 Jul 2011 12:20:24 -0700 (PDT) Received: from blu0-omc1-s22.blu0.hotmail.com (blu0-omc1-s22.blu0.hotmail.com [65.55.116.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2A211E809E for ; Sun, 3 Jul 2011 12:20:24 -0700 (PDT) Received: from BLU0-SMTP92 ([65.55.116.9]) by blu0-omc1-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jul 2011 12:20:23 -0700 X-Originating-IP: [65.94.104.44] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([65.94.104.44]) by BLU0-SMTP92.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jul 2011 12:20:23 -0700 Date: Sun, 3 Jul 2011 15:20:21 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: pcn@ietf.org References: <1309718950.32690.3.camel@tachyon> In-Reply-To: <1309718950.32690.3.camel@tachyon> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2011 19:20:23.0445 (UTC) FILETIME=[419B9C50:01CC39B6] Subject: Re: [PCN] IETF-81 proposed agenda X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 19:20:24 -0000 I can provide charts on the edge behaviour documents. I can also undertake to add the OAM portions in a further update before next week's deadline. We need the protocol work to complete all that. Georgios's document may be the answer, but as I told him, I'll be reading it with an open but critical mind. Basically, my understanding is that we can't send the documents back to the IESG until we get the protocol part done, so that's the critical path. On 03/07/2011 2:49 PM, Steven Blake wrote: > Hi, > > Here is a proposed agenda for the WG meeting in Quebec City. Note that > PCN only has a one-hour slot, but since it comes at the end of the > afternoon sessions, it may be possible to spill over into the break. > > We need someone to lead the discussion of the 3-in-1 and edge behaviour > drafts so that they can go (back) to the IESG. > > Please send comments to the list. > > > Regards, > > // Steve > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From fluffy@cisco.com Wed Jul 6 10:04:56 2011 Return-Path: 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 B1C8B21F87A8; Wed, 6 Jul 2011 10:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjFrq6uJIpik; Wed, 6 Jul 2011 10:04:56 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id 457BC21F8766; Wed, 6 Jul 2011 10:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=308; q=dns/txt; s=iport; t=1309971896; x=1311181496; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5SzzMOFrmv8SVDN+aR1BeteHuaYDeI9yzNN/jO6Zhvg=; b=U7Ggjw5qCZE9XHNg8/4VxOyfTaqaNQfqPsKvQ/v6cPrImWVJFtBSoC7Z JrlU1deVGRt6KRMVE1irsDW//mfVffUObAckEMz8S75sg0yrmmGtDjjNK x47M48Ix1MHjCppYtYJgsBtZXaa59aGygeR2B1wW60+QKC9lnKCuzi29/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF2VFE6rRDoH/2dsb2JhbABTqAV3iHqlN54ShjcEh0aKe4R6i2I X-IronPort-AV: E=Sophos;i="4.65,488,1304294400"; d="scan'208";a="362488161" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2011 17:04:56 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p66H4tsX007006; Wed, 6 Jul 2011 17:04:55 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 6 Jul 2011 11:04:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110527203800.13071.15398.idtracker@ietfa.amsl.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Wed, 06 Jul 2011 10:06:34 -0700 Cc: pcn@ietf.org, IETF-Discussion list Subject: Re: [PCN] Last Call: (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:04:56 -0000 On Jun 12, 2011, at 8:48 AM, Tom Taylor wrote: > What I propose is that I submit the documents with the fixes that were = carried out, and the IESG restart the Last Call process.=20 Tom, glad was caught this before this was an RFC. I think your proposal = sounds like the right way to proceed.=20 From internet-drafts@ietf.org Sun Jul 10 08:42:41 2011 Return-Path: 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 BF52821F86D0; Sun, 10 Jul 2011 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTR9-W+fbpw3; Sun, 10 Jul 2011 08:42:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A2F21F86BE; Sun, 10 Jul 2011 08:42:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110710154241.10084.66861.idtracker@ietfa.amsl.com> Date: Sun, 10 Jul 2011 08:42:41 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 15:42:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Encoding 3 PCN-States in the IP header using a single DS= CP Author(s) : Bob Briscoe Toby Moncaster Michael Menth Filename : draft-ietf-pcn-3-in-1-encoding-06.txt Pages : 22 Date : 2011-07-10 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to decision points which then decide whether to admit or block new flow requests or to terminate some already-admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding provides for up to three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC5696. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt From toby@moncaster.com Sun Jul 10 08:46:18 2011 Return-Path: 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 F20A221F8734 for ; Sun, 10 Jul 2011 08:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-e6SSsAblk5 for ; Sun, 10 Jul 2011 08:46:17 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 02AC521F86C2 for ; Sun, 10 Jul 2011 08:46:17 -0700 (PDT) Received: from TobysHP (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Mgw8O-1Qt5Lb2nho-00M0qo; Sun, 10 Jul 2011 17:46:16 +0200 From: "Toby Moncaster" To: Date: Sun, 10 Jul 2011 16:46:15 +0100 Message-ID: <005d01cc3f18$80aa2120$81fe6360$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CC3F20.E26E8920" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw/GIBT+nNR9qMGSf6rFTlbmF78hw== Content-Language: en-gb X-Provags-ID: V02:K0:3COxWRm804/6NB4e3WrN45pXXhzDi/bvKcilyCpNzI+ YgeGIfrx5NmXmK/h5zKUdpdfVH2z7rCTM0n39VLFtHoAyorSBn 8K9f1qqGS9W3JcMATcRSSAT8/oTzNxPidRyx19/R0rAz0ZJq6H fWpo1KDPb07DfTO9Bk+TvvYswcLT1lzRmt+dw7NcHi36Gs3IFL KQmqTK9qhI2+GUuBTLKyvRu9y6mBLk2AJl4TTmq6aU= Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 15:46:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005E_01CC3F20.E26E8920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, After much change and debate we have finally posted a revised version of the 3-in-1 encoding. Given the fairly significant changes since the document went through its first WGLC the WGCs may decide it needs another WGLC... http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg Diffs from version 5: http://moncaster.com/3-in-1-diff-05--06.html Toby ------=_NextPart_000_005E_01CC3F20.E26E8920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

After much change and debate we have finally posted a = revised version of the 3-in-1 encoding. Given the fairly significant = changes since the document went through its first WGLC the WGCs may = decide it needs another WGLC...

 

http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encod= ing-06.txt

= http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html<= /o:p>

h= ttp://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf

h= ttp://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml

= http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg<= /o:p>

 

 

Diffs = from version 5:

 

http://moncaster.co= m/3-in-1-diff-05--06.html

 

Toby

------=_NextPart_000_005E_01CC3F20.E26E8920-- From menth@informatik.uni-tuebingen.de Sun Jul 10 14:10:42 2011 Return-Path: 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 44F1521F87E9 for ; Sun, 10 Jul 2011 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy-b2fb6pQ+J for ; Sun, 10 Jul 2011 14:10:41 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 29F7B21F87C7 for ; Sun, 10 Jul 2011 14:10:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id A883A52B8 for ; Sun, 10 Jul 2011 23:10:38 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DGlC5mu5xEo for ; Sun, 10 Jul 2011 23:10:35 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6895E51B9 for ; Sun, 10 Jul 2011 23:10:35 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 036CB2084C73 for ; Sun, 10 Jul 2011 23:10:33 +0200 (CEST) Message-ID: <4E1A1542.7050200@informatik.uni-tuebingen.de> Date: Sun, 10 Jul 2011 23:10:26 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pcn@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 21:10:42 -0000 Hi Toby and all, I think we should clearly point out that threshold marking in pre-RFC6040 networks is not possible with 3-in-1 encoding which is a fundamental difference to baseline encoding. Section 4.3 could be improved in this respect (shorter and clearer): "The 3-in-1 encoding is applicable in situations where two marking behaviours are being used in the PCN-domain. The 3-in-1 encoding can also be used with only one marking behaviour, in which case one of the codepoints MUST NOT be used throughout the PCN-domain (see Section 5.2.3). For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN encapsulation and decapsulation rules set out in [RFC6040] (see Section 4.2). There is one exception to this rule outlined next. It may not be possible to upgrade every pre-RFC6040 tunnel endpoint within a PCN-domain. In such cirsumstances a limited version of the 3-in-1 encoding can still be used but only under the following stringent condition. If any pre-RFC6040 tunnel endpoint exists within a PCN-domain then every PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint. The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3.1. In all other situations where legacy tunnel endpoints might be present within the PCN domain, the 3-in-1 encoding is not applicable." -> "3-in-1 is applicable if all tunnel decapsulators comply with RFC6040. It is able to support excess-traffic marking and threshold marking. A subset of the encoding may also be used in pre-RFC6040 networks. Then, the ThM codepoint MUST NOT be used. As a consequence, it is possible to use excess-traffic marking in such networks but not threshold marking. This is a difference to the obsoleted RFC5696." Regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Sun Jul 10 14:10:58 2011 Return-Path: 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 2B18D21F881B for ; Sun, 10 Jul 2011 14:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxKN0O9ijCCC for ; Sun, 10 Jul 2011 14:10:57 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 8502A21F8804 for ; Sun, 10 Jul 2011 14:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 304B85278 for ; Sun, 10 Jul 2011 23:10:50 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUhaxkHmzVu4 for ; Sun, 10 Jul 2011 23:10:46 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3B9E85218 for ; Sun, 10 Jul 2011 23:10:45 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id A31EE2084C74 for ; Sun, 10 Jul 2011 23:10:45 +0200 (CEST) Message-ID: <4E1A1556.7060303@informatik.uni-tuebingen.de> Date: Sun, 10 Jul 2011 23:10:46 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pcn@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] 3-in-1: some more issues X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 21:10:58 -0000 Hi Toby and all, Section 5.2.3 I believe Section 5.2.3 can be dropped. It's the edge nodes that need to deal with unexpectedly marked packets. This would also make Appendix D redundant. Section 5.3 "If the PCN-domain is configured to use only excess-traffic marking, the PCN-egress node MUST treat ThM as ETM and if only threshold-marking is used it should treat ETM as ThM. However it SHOULD raise a management alarm in either instance since this means there is some misconfiguration in the PCN-domain." I don't think this advice for edge behaviors is not needed in this document so that this paragraph may be dropped. Section 6.1 "BCP 124 [RFC4774] gives guidelines for specifying alternative semantics for the ECN field. It sets out a number of factors to be taken into consideration. It also suggests various techniques to allow the co-existence of default ECN and alternative ECN semantics. The encoding specified in this document uses one of those techniques; it defines PCN-compatible Diffserv codepoints as no longer supporting the default ECN semantics." -> "... ECN semantics within PCN domains." Without this additions one may read it that packets with a CE-mark before entering a PCN domain may leave it without a CE-mark. This would violate RFC4774 as I read it. Regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Sun Jul 10 14:10:58 2011 Return-Path: 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 9515821F8804 for ; Sun, 10 Jul 2011 14:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+aHfCFE2v2i for ; Sun, 10 Jul 2011 14:10:58 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id A841521F8829 for ; Sun, 10 Jul 2011 14:10:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id AF12A527A for ; Sun, 10 Jul 2011 23:10:53 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx0OqqAsI8q6 for ; Sun, 10 Jul 2011 23:10:51 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 677D55218 for ; Sun, 10 Jul 2011 23:10:51 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id AD2B52084C75 for ; Sun, 10 Jul 2011 23:10:51 +0200 (CEST) Message-ID: <4E1A155C.1020507@informatik.uni-tuebingen.de> Date: Sun, 10 Jul 2011 23:10:52 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pcn@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] 3-in-1: minor nits X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 21:10:58 -0000 Hi Toby and all, Section 4.2 "If a PCN node Threshold-marks the outer header of a tunnelled packet with a Not-marked codepoint on the inner header, the legacy decapsulator will revert the Threshold-marking to Not-marked." -> "... will revert the Threshold-marked inner codepoint to Not-marked." Section 6.2 "However, thre is no known deployment of such an implementation and no reason to believe that such an implementation would ever have been built. Therefore, it seems safe to ignore this issue." -> "However, there is no known deployment of such an implementation to date. Therefore, it seems safe to ignore this issue." Appendix B "Two mechanisms can be used to identify such traffic: a. flow signalling associates a filterspec with a need for admission control (e.g. through RSVP or some equivalent message, e.g. from a SIP server to the ingress), and the PCN-ingress remarks traffic matching that filterspec to a PCN-compatible DSCP, as its chosen admission control mechanism. b. Traffic arrives with a DSCP that implies it requires admission control such as VOICE-ADMIT [RFC5865] or Interactive Real-Time, Broadcast TV when used for video on demand, and Multimedia Conferencing [RFC4594][RFC5865]." This needs reformulation since the two bullets do not enumerate mechanisms. Am I right that signalling and admission control is needed in both cases? Regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Sun Jul 10 14:11:23 2011 Return-Path: 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 44F2E21F8834 for ; Sun, 10 Jul 2011 14:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpG9YhoF7cbG for ; Sun, 10 Jul 2011 14:11:22 -0700 (PDT) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id E67E921F8829 for ; Sun, 10 Jul 2011 14:11:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1056052B8 for ; Sun, 10 Jul 2011 23:11:21 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx3.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx3.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzQRcmnsGIGu for ; Sun, 10 Jul 2011 23:11:17 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id D5F3151B9 for ; Sun, 10 Jul 2011 23:11:17 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 062E42084C8A for ; Sun, 10 Jul 2011 23:11:17 +0200 (CEST) Message-ID: <4E1A1576.9070406@informatik.uni-tuebingen.de> Date: Sun, 10 Jul 2011 23:11:18 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "pcn@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] 3-in-1: add some text on partially PCN-capable tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 21:11:23 -0000 Hi Toby and all, I see an issue with tunnels starting outside PCN domains and ending inside PCN domains. I believe this should be clarified in an appendix to 3-in-1 because this touches the coexistence between PCN and ECN. RFC5559 says: http://tools.ietf.org/html/rfc5559#section-4.7 Potential issues arise for a "partially PCN-capable tunnel", ie, where only one tunnel endpoint is in the PCN-domain: 1. The tunnel originates outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre- congestion. 2. The tunnel originates inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated, which could potentially confuse nodes beyond the tunnel egress. In line with the solution for partially capable Diffserv tunnels in [RFC2983], the following rules are applied: o For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the "copy on decapsulation" rule above. o For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the "copy on encapsulation" rule above. I believe the first bullet gives a wrong recommendation for case (1). If a CE-marked packet is tunneled, the rule clears that CE-mark and the packet may leave the PCN domain without CE-mark. This violates RFC4774. However, this issue could be solved by dropping such packets, but that would be a nasty solution because finding them might be tricky. Therefore, I'd be rather in favor to say that such tunnels SHOULD/MUST not be used. An appendix in the 3-in-1 doc could correct this issue. Regards, Michael -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From toby@moncaster.com Sun Jul 10 14:32:54 2011 Return-Path: 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 62BD021F877A for ; Sun, 10 Jul 2011 14:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4bsuEcWf1L0 for ; Sun, 10 Jul 2011 14:32:53 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id CAAD421F867F for ; Sun, 10 Jul 2011 14:32:45 -0700 (PDT) Received: from TobysHP (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LwXB1-1Ra44B3KW7-017cuw; Sun, 10 Jul 2011 23:32:45 +0200 From: "Toby Moncaster" To: "'Michael Menth'" , References: <4E1A1556.7060303@informatik.uni-tuebingen.de> In-Reply-To: <4E1A1556.7060303@informatik.uni-tuebingen.de> Date: Sun, 10 Jul 2011 22:32:41 +0100 Message-ID: <000601cc3f48$e659ecf0$b30dc6d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw/RfHdGT1bWSyNQ1er+OR/aWWf1AAApmfA Content-Language: en-gb X-Provags-ID: V02:K0:Ii0Lxn3vXuuBIyLdq2UXPaSygFTuDMNW2wAfj9LUruN XZf+OeAFdB8oWRo79frvYn9zrwcIOnTXb6uZmQ2JKT53Js4I2v GPJUREqV/E0uIzLvhw1QQikznwmJWmz5uZxEGoWHllvfomlMis rWA1n4LSgL49YggdEZ8ppf+u7g4JRNG3Gru23mj4RAet2DGj5q b/4baFSmbi/NliW6xHejnMdxyfC7xvs6a9C1pnCvMM= Subject: Re: [PCN] 3-in-1: some more issues X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 21:32:54 -0000 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: 10 July 2011 22:11 > To: pcn@ietf.org > Subject: [PCN] 3-in-1: some more issues > > Hi Toby and all, > > > Section 5.2.3 > > I believe Section 5.2.3 can be dropped. It's the edge nodes that need > to > deal with unexpectedly marked packets. This would also make Appendix D > redundant. And what happens if a misconfigured interior node marks something wrong? You can't just assume everything works perfectly all the time... > > Section 5.3 > > "If the PCN-domain is configured to use only excess-traffic marking, > the > PCN-egress node MUST treat ThM as ETM and if only threshold-marking is > used > it should treat ETM as ThM. However it SHOULD raise a management alarm > in > either instance since this means there is some misconfiguration in the > PCN-domain." > > I don't think this advice for edge behaviors is not needed in this > document so that this paragraph may be dropped. This is by way of being a caveat. If it isn't mentioned here, how will edge behaviour authors know what to do in this circumstance? > > Section 6.1 > > "BCP 124 [RFC4774] gives guidelines for specifying alternative > semantics for > the ECN field. It sets out a number of factors to be taken into > consideration. It also suggests various techniques to allow the co- > existence > of default ECN and alternative ECN semantics. The encoding specified in > this > document uses one of those techniques; it defines PCN-compatible > Diffserv > codepoints as no longer supporting the default ECN semantics." > > -> > > "... ECN semantics within PCN domains." > > Without this additions one may read it that packets with a CE-mark > before entering a PCN domain may leave it without a CE-mark. This would > violate RFC4774 as I read it. This needs a proper discussion in its own thread... Toby > > Regards, > > Michael > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Mon Jul 11 00:51:23 2011 Return-Path: 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 BAEB421F8667 for ; Mon, 11 Jul 2011 00:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGfzYFBKC8ar for ; Mon, 11 Jul 2011 00:51:22 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3764821F8610 for ; Mon, 11 Jul 2011 00:51:22 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 08:51:20 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 11 Jul 2011 08:51:20 +0100 From: To: , Date: Mon, 11 Jul 2011 08:51:40 +0100 Thread-Topic: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains Thread-Index: Acw/Re5v0B8ryyQ0T2yrpCAnybkGRwAWKCuQ Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D34A8C@EMV65-UKRD.domain1.systemhost.net> References: <4E1A1542.7050200@informatik.uni-tuebingen.de> In-Reply-To: <4E1A1542.7050200@informatik.uni-tuebingen.de> 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 Subject: Re: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 07:51:23 -0000 I dont mind some re-wording, however I'm not sure about your proposal. - the obsoleted 5696 doesn't mention 'threshold marking' - 5696 doesnt allow 01 marking - it leaves it open to be defined elsewhere = for EXP use - I think 5696 should be briefly mentioned in the Intro, but not talked abo= ut in the main part of the doc (ie the part that defines the standard shoul= d just define the std) - with 3in1 in a pre-6040 environemnt, ie where only the 11 encoding is us= ed and not 01. Although the obvious case is that this is set by the excess = traffic meter, I see no reason in principle why this shouldn't be set by th= e threshold meter Best wishes, phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: 10 July 2011 22:10 To: pcn@ietf.org Subject: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains Hi Toby and all, I think we should clearly point out that threshold marking in=20 pre-RFC6040 networks is not possible with 3-in-1 encoding which is a=20 fundamental difference to baseline encoding. Section 4.3 could be=20 improved in this respect (shorter and clearer): "The 3-in-1 encoding is applicable in situations where two marking=20 behaviours are being used in the PCN-domain. The 3-in-1 encoding can also be used with only one marking behaviour, in which case one of the codepoints MUST NOT be used throughout the PCN-domain (see Section 5.2.3). For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP and IPsec) within the PCN-domain MUST comply with the ECN encapsulation and decapsulation rules set out in [RFC6040] (see Section 4.2). There is one exception to this rule outlined next. It may not be possible to upgrade every pre-RFC6040 tunnel endpoint within = a PCN-domain. In such cirsumstances a limited version of the 3-in-1 encoding can still be used but only under the following stringent condition. If any pre-RFC6040 tunnel endpoint exists within a PCN-domain then every=20 PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint. The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3.1. In all other situations where legacy tunnel endpoints might be present within the PCN domain, the 3-in-1 encoding is not applicable." -> "3-in-1 is applicable if all tunnel decapsulators comply with RFC6040. It i= s able to support excess-traffic marking and threshold marking. A subset=20 of the encoding may also be used in pre-RFC6040 networks. Then, the ThM codepoint MUST NOT be used. As a consequence, it is possible to use excess-traffic marking in such networks but not threshold marking. This is a difference to the obsoleted RFC5696." Regards, Michael --=20 Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Mon Jul 11 00:56:52 2011 Return-Path: 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 E464521F84CB for ; Mon, 11 Jul 2011 00:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.871 X-Spam-Level: X-Spam-Status: No, score=-102.871 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RqCkKnTsPW8 for ; Mon, 11 Jul 2011 00:56:52 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9021F8439 for ; Mon, 11 Jul 2011 00:56:51 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 08:56:51 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 11 Jul 2011 08:56:50 +0100 From: To: , Date: Mon, 11 Jul 2011 08:57:11 +0100 Thread-Topic: [PCN] 3-in-1: some more issues Thread-Index: Acw/RfIPagGMwRjsTIK5a6/2LMY4mwAWZdXQ Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D34A9E@EMV65-UKRD.domain1.systemhost.net> References: <4E1A1556.7060303@informatik.uni-tuebingen.de> In-Reply-To: <4E1A1556.7060303@informatik.uni-tuebingen.de> 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 Subject: Re: [PCN] 3-in-1: some more issues X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 07:56:53 -0000 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: 10 July 2011 22:11 To: pcn@ietf.org Subject: [PCN] 3-in-1: some more issues Hi Toby and all, Section 5.2.3 I believe Section 5.2.3 can be dropped. It's the edge nodes that need to=20 deal with unexpectedly marked packets. This would also make Appendix D=20 redundant. [phil] 5,2,3 doesn't seem needed in the main body of the doc. Personally I = think Appendices that explain design choices are quite useful. Section 5.3 "If the PCN-domain is configured to use only excess-traffic marking, the PCN-egress node MUST treat ThM as ETM and if only threshold-marking is used it should treat ETM as ThM. However it SHOULD raise a management alarm in either instance since this means there is some misconfiguration in the PCN-domain." I don't think this advice for edge behaviors is not needed in this=20 document so that this paragraph may be dropped. [phil] probably this is most logical (although don't mind much either way) Section 6.1 "BCP 124 [RFC4774] gives guidelines for specifying alternative semantics fo= r the ECN field. It sets out a number of factors to be taken into consideration. It also suggests various techniques to allow the co-existenc= e of default ECN and alternative ECN semantics. The encoding specified in thi= s document uses one of those techniques; it defines PCN-compatible Diffserv codepoints as no longer supporting the default ECN semantics." -> "... ECN semantics within PCN domains." Without this additions one may read it that packets with a CE-mark=20 before entering a PCN domain may leave it without a CE-mark. This would=20 violate RFC4774 as I read it. Regards, Michael --=20 Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-tuebingen.de Mon Jul 11 01:06:44 2011 Return-Path: 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 02F9821F869C for ; Mon, 11 Jul 2011 01:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1HZkyBjWLk4 for ; Mon, 11 Jul 2011 01:06:43 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id 9DD4E21F86FD for ; Mon, 11 Jul 2011 01:06:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7A9205278; Mon, 11 Jul 2011 10:06:40 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY1-Dw1X+D1q; Mon, 11 Jul 2011 10:06:33 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E03FA5253; Mon, 11 Jul 2011 10:06:32 +0200 (MEST) Received: from [192.168.1.101] (HSI-KBW-078-043-115-059.hsi4.kabel-badenwuerttemberg.de [78.43.115.59]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9488E1231C3D; Mon, 11 Jul 2011 10:06:32 +0200 (CEST) Message-ID: <4E1AAF08.5000902@informatik.uni-tuebingen.de> Date: Mon, 11 Jul 2011 10:06:32 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: philip.eardley@bt.com References: <4E1A1542.7050200@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32E2D34A8C@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D34A8C@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 08:06:44 -0000 Hi Phil, Am 11.07.2011 09:51, schrieb philip.eardley@bt.com: > I dont mind some re-wording, however I'm not sure about your proposal. > > - the obsoleted 5696 doesn't mention 'threshold marking' > - 5696 doesnt allow 01 marking - it leaves it open to be defined elsewhere for EXP use > - I think 5696 should be briefly mentioned in the Intro, but not talked about in the main part of the doc (ie the part that defines the standard should just define the std) > - with 3in1 in a pre-6040 environemnt, ie where only the 11 encoding is used and not 01. Although the obvious case is that this is set by the excess traffic meter, I see no reason in principle why this shouldn't be set by the threshold meter Currently the document does not allow it. See http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-06#section-5.2.3.2 If we want to leave such a hole open, we must explicitly say that. Otherwise it's forbidden. I don't say that we need to do it, we just need to know what we standardize and clearly communicate that. Regards, Michael > Best wishes, > phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth > Sent: 10 July 2011 22:10 > To: pcn@ietf.org > Subject: [PCN] 3-in-1: no threshold-marking in pre-RFC6040 PCN domains > > Hi Toby and all, > > I think we should clearly point out that threshold marking in > pre-RFC6040 networks is not possible with 3-in-1 encoding which is a > fundamental difference to baseline encoding. Section 4.3 could be > improved in this respect (shorter and clearer): > > "The 3-in-1 encoding is applicable in situations where two marking > behaviours > are being used in the PCN-domain. The 3-in-1 encoding can also be used with > only one marking behaviour, in which case one of the codepoints MUST NOT be > used throughout the PCN-domain (see Section 5.2.3). > > For the full 3-in-1 encoding to apply, any tunnel endpoints (IP-in-IP and > IPsec) within the PCN-domain MUST comply with the ECN encapsulation and > decapsulation rules set out in [RFC6040] (see Section 4.2). There is one > exception to this rule outlined next. > > It may not be possible to upgrade every pre-RFC6040 tunnel endpoint within a > PCN-domain. In such cirsumstances a limited version of the 3-in-1 encoding > can still be used but only under the following stringent condition. If any > pre-RFC6040 tunnel endpoint exists within a PCN-domain then every > PCN-node in > the PCN-domain MUST be configured so that it never sets the ThM codepoint. > The behaviour of PCN-interior nodes in this case is defined in Section > 5.2.3.1. In all other situations where legacy tunnel endpoints might be > present within the PCN domain, the 3-in-1 encoding is not applicable." > > -> > > "3-in-1 is applicable if all tunnel decapsulators comply with RFC6040. It is > able to support excess-traffic marking and threshold marking. A subset > of the > encoding may also be used in pre-RFC6040 networks. Then, the ThM codepoint > MUST NOT be used. As a consequence, it is possible to use excess-traffic > marking in such networks but not threshold marking. This is a difference to > the obsoleted RFC5696." > > Regards, > > Michael > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From philip.eardley@bt.com Mon Jul 11 01:07:37 2011 Return-Path: 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 53E2221F8552 for ; Mon, 11 Jul 2011 01:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXnML36u2-i0 for ; Mon, 11 Jul 2011 01:07:36 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 88E3221F85D2 for ; Mon, 11 Jul 2011 01:07:36 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 09:07:34 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 11 Jul 2011 09:07:34 +0100 From: To: , Date: Mon, 11 Jul 2011 09:07:53 +0100 Thread-Topic: [PCN] 3-in-1: add some text on partially PCN-capable tunnels Thread-Index: Acw/Rfppx9Z+pi26Qsy5NQj+iLlivgAW5VwA Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D34ACB@EMV65-UKRD.domain1.systemhost.net> References: <4E1A1576.9070406@informatik.uni-tuebingen.de> In-Reply-To: <4E1A1576.9070406@informatik.uni-tuebingen.de> 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 Subject: Re: [PCN] 3-in-1: add some text on partially PCN-capable tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 08:07:37 -0000 I don't see why 3in1 is the right place to deal with this.=20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: 10 July 2011 22:11 To: pcn@ietf.org Subject: [PCN] 3-in-1: add some text on partially PCN-capable tunnels Hi Toby and all, I see an issue with tunnels starting outside PCN domains and ending=20 inside PCN domains. I believe this should be clarified in an appendix to=20 3-in-1 because this touches the coexistence between PCN and ECN. RFC5559 says: http://tools.ietf.org/html/rfc5559#section-4.7 Potential issues arise for a "partially PCN-capable tunnel", ie, where only one tunnel endpoint is in the PCN-domain: 1. The tunnel originates outside a PCN-domain and ends inside it. If the packet arrives at the tunnel ingress with the same encoding as used within the PCN-domain to indicate PCN-marking, then this could lead the PCN-egress-node to falsely measure pre- congestion. 2. The tunnel originates inside a PCN-domain and ends outside it. If the packet arrives at the tunnel ingress already PCN-marked, then it will still have the same encoding when it's decapsulated, which could potentially confuse nodes beyond the tunnel egress. In line with the solution for partially capable Diffserv tunnels in [RFC2983], the following rules are applied: o For case (1), the tunnel egress node clears any PCN-marking on the inner header. This rule is applied before the "copy on decapsulation" rule above. o For case (2), the tunnel ingress node clears any PCN-marking on the inner header. This rule is applied after the "copy on encapsulation" rule above. I believe the first bullet gives a wrong recommendation for case (1). If=20 a CE-marked packet is tunneled, the rule clears that CE-mark and the=20 packet may leave the PCN domain without CE-mark. This violates RFC4774.=20 However, this issue could be solved by dropping such packets, but that=20 would be a nasty solution because finding them might be tricky.=20 Therefore, I'd be rather in favor to say that such tunnels SHOULD/MUST=20 not be used. An appendix in the 3-in-1 doc could correct this issue. Regards, Michael --=20 Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From toby@moncaster.com Mon Jul 11 01:22:21 2011 Return-Path: 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 3AB9221F8576 for ; Mon, 11 Jul 2011 01:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV3BkNFW61ti for ; Mon, 11 Jul 2011 01:22:20 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 45C3F21F8571 for ; Mon, 11 Jul 2011 01:22:20 -0700 (PDT) Received: from TobysHP (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Mah1p-1QvwQ70zM1-00KAgX; Mon, 11 Jul 2011 10:22:18 +0200 From: "Toby Moncaster" To: , , References: <4E1A1556.7060303@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32E2D34A9E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D34A9E@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 11 Jul 2011 09:22:17 +0100 Message-ID: <001e01cc3fa3$a632d4b0$f2987e10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw/RfIPagGMwRjsTIK5a6/2LMY4mwAWZdXQAADtnEA= Content-Language: en-gb X-Provags-ID: V02:K0:oYAOujY1/rHqTKfcmg5HQHLKDGbm5JcJ/RCwdP9+S8a tpVWOXqNbBrdWmBIMBt86fQSSE5aJXHR81QQZHwkKRB9wkV4Mq sYnZBKyjAqmFRLynhuUMFV89wJXYp/Ty8ccHt73obBVSv5Hl4B ufrbIFY5hnk9Zss+YJ5tVXoL7GMRXF0UdtNgnTk+efHZSW3mga jw4DN8tPpVavP+UTr3dd12nieqxbOsaaHOAizpwQXQ= Subject: Re: [PCN] 3-in-1: some more issues X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 08:22:21 -0000 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 11 July 2011 08:57 > To: menth@informatik.uni-tuebingen.de; pcn@ietf.org > Subject: Re: [PCN] 3-in-1: some more issues > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: 10 July 2011 22:11 > To: pcn@ietf.org > Subject: [PCN] 3-in-1: some more issues > > Hi Toby and all, > > > Section 5.2.3 > > I believe Section 5.2.3 can be dropped. It's the edge nodes that need > to > deal with unexpectedly marked packets. This would also make Appendix D > redundant. > > [phil] 5,2,3 doesn't seem needed in the main body of the doc. > Personally I think Appendices that explain design choices are quite > useful. Although it appears as though 5.2.3 mandates that the behaviour with one mark is the same as with two marks, there are 2 key differences that make it necessary for this section to exist; Firstly, they mandate that the wrong marker be turned off (thus allowing ETM-only to work as legacy pre-6040 coding), secondly they mention providing management alarms... > > Section 5.3 > > "If the PCN-domain is configured to use only excess-traffic marking, > the > PCN-egress node MUST treat ThM as ETM and if only threshold-marking is > used > it should treat ETM as ThM. However it SHOULD raise a management alarm > in > either instance since this means there is some misconfiguration in the > PCN-domain." > > I don't think this advice for edge behaviors is not needed in this > document so that this paragraph may be dropped. > > [phil] probably this is most logical (although don't mind much either > way) I was keen to include it just to make sure it was stated Toby > > Section 6.1 > > "BCP 124 [RFC4774] gives guidelines for specifying alternative > semantics for > the ECN field. It sets out a number of factors to be taken into > consideration. It also suggests various techniques to allow the co- > existence > of default ECN and alternative ECN semantics. The encoding specified in > this > document uses one of those techniques; it defines PCN-compatible > Diffserv > codepoints as no longer supporting the default ECN semantics." > > -> > > "... ECN semantics within PCN domains." > > Without this additions one may read it that packets with a CE-mark > before entering a PCN domain may leave it without a CE-mark. This would > violate RFC4774 as I read it. > > Regards, > > Michael > > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Mon Jul 11 01:24:54 2011 Return-Path: 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 0474B21F886B for ; Mon, 11 Jul 2011 01:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPCo2Xh67cZC for ; Mon, 11 Jul 2011 01:24:53 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 127AE21F880D for ; Mon, 11 Jul 2011 01:24:53 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 09:24:52 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Mon, 11 Jul 2011 09:24:52 +0100 From: To: , , Date: Mon, 11 Jul 2011 09:25:06 +0100 Thread-Topic: [PCN] 3-in-1: some more issues Thread-Index: Acw/RfIPagGMwRjsTIK5a6/2LMY4mwAWZdXQAADtnEAAAC2mAA== Message-ID: <9510D26531EF184D9017DF24659BB87F32E2D34B1C@EMV65-UKRD.domain1.systemhost.net> References: <4E1A1556.7060303@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32E2D34A9E@EMV65-UKRD.domain1.systemhost.net> <001e01cc3fa3$a632d4b0$f2987e10$@com> In-Reply-To: <001e01cc3fa3$a632d4b0$f2987e10$@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 Subject: Re: [PCN] 3-in-1: some more issues X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 08:24:54 -0000 Toby Re 5.2.3 - you're quite right Thanks for the clarification, phil -----Original Message----- From: Toby Moncaster [mailto:toby@moncaster.com]=20 Sent: 11 July 2011 09:22 To: Eardley,PL,Philip,DES8 R; menth@informatik.uni-tuebingen.de; pcn@ietf.o= rg Subject: RE: [PCN] 3-in-1: some more issues > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 11 July 2011 08:57 > To: menth@informatik.uni-tuebingen.de; pcn@ietf.org > Subject: Re: [PCN] 3-in-1: some more issues >=20 >=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: 10 July 2011 22:11 > To: pcn@ietf.org > Subject: [PCN] 3-in-1: some more issues >=20 > Hi Toby and all, >=20 >=20 > Section 5.2.3 >=20 > I believe Section 5.2.3 can be dropped. It's the edge nodes that need > to > deal with unexpectedly marked packets. This would also make Appendix D > redundant. >=20 > [phil] 5,2,3 doesn't seem needed in the main body of the doc. > Personally I think Appendices that explain design choices are quite > useful. Although it appears as though 5.2.3 mandates that the behaviour with one mark is the same as with two marks, there are 2 key differences that make i= t necessary for this section to exist; Firstly, they mandate that the wrong marker be turned off (thus allowing ETM-only to work as legacy pre-6040 coding), secondly they mention providing management alarms... >=20 > Section 5.3 >=20 > "If the PCN-domain is configured to use only excess-traffic marking, > the > PCN-egress node MUST treat ThM as ETM and if only threshold-marking is > used > it should treat ETM as ThM. However it SHOULD raise a management alarm > in > either instance since this means there is some misconfiguration in the > PCN-domain." >=20 > I don't think this advice for edge behaviors is not needed in this > document so that this paragraph may be dropped. >=20 > [phil] probably this is most logical (although don't mind much either > way) I was keen to include it just to make sure it was stated Toby >=20 > Section 6.1 >=20 > "BCP 124 [RFC4774] gives guidelines for specifying alternative > semantics for > the ECN field. It sets out a number of factors to be taken into > consideration. It also suggests various techniques to allow the co- > existence > of default ECN and alternative ECN semantics. The encoding specified in > this > document uses one of those techniques; it defines PCN-compatible > Diffserv > codepoints as no longer supporting the default ECN semantics." >=20 > -> >=20 > "... ECN semantics within PCN domains." >=20 > Without this additions one may read it that packets with a CE-mark > before entering a PCN domain may leave it without a CE-mark. This would > violate RFC4774 as I read it. >=20 > Regards, >=20 > Michael >=20 > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://www-kn.informatik.uni-tuebingen.de >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-tuebingen.de Mon Jul 11 01:44:01 2011 Return-Path: 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 0B20021F8895 for ; Mon, 11 Jul 2011 01:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z33ItPR3wU2m for ; Mon, 11 Jul 2011 01:44:00 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id B3DFF21F8891 for ; Mon, 11 Jul 2011 01:43:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6A2B45262; Mon, 11 Jul 2011 10:43:58 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro1470meShfy; Mon, 11 Jul 2011 10:43:53 +0200 (MEST) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 8D95151CB; Mon, 11 Jul 2011 10:43:53 +0200 (MEST) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 7BAA91231F23; Mon, 11 Jul 2011 10:43:53 +0200 (CEST) Message-ID: <4E1AB7CB.1040509@informatik.uni-tuebingen.de> Date: Mon, 11 Jul 2011 10:43:55 +0200 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: philip.eardley@bt.com References: <4E1A1576.9070406@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32E2D34ACB@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E2D34ACB@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1: add some text on partially PCN-capable tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 08:44:01 -0000 Am 11.07.2011 10:07, schrieb philip.eardley@bt.com: > I don't see why 3in1 is the right place to deal with this. The encoding doc is the right place to deal with the tunneling issues because we redefine the ECN field in this doc. Therefore, we must assure that the redefinition complies with RFC4774. Partially PCN-capable tunnels may violate RFC4774. That is why the encoding document is the right place for this issue. It's about the same reason why deal with the coexistence of ECN and PCN marking in the appendix. Makes sense? Regards, Michael > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth > Sent: 10 July 2011 22:11 > To: pcn@ietf.org > Subject: [PCN] 3-in-1: add some text on partially PCN-capable tunnels > > Hi Toby and all, > > I see an issue with tunnels starting outside PCN domains and ending > inside PCN domains. I believe this should be clarified in an appendix to > 3-in-1 because this touches the coexistence between PCN and ECN. > > RFC5559 says: http://tools.ietf.org/html/rfc5559#section-4.7 > > Potential issues arise for a "partially PCN-capable tunnel", ie, > where only one tunnel endpoint is in the PCN-domain: > > 1. The tunnel originates outside a PCN-domain and ends inside it. > If the packet arrives at the tunnel ingress with the same > encoding as used within the PCN-domain to indicate PCN-marking, > then this could lead the PCN-egress-node to falsely measure pre- > congestion. > > 2. The tunnel originates inside a PCN-domain and ends outside it. > If the packet arrives at the tunnel ingress already PCN-marked, > then it will still have the same encoding when it's decapsulated, > which could potentially confuse nodes beyond the tunnel egress. > > In line with the solution for partially capable Diffserv tunnels in > [RFC2983], the following rules are applied: > > o For case (1), the tunnel egress node clears any PCN-marking on the > inner header. This rule is applied before the "copy on > decapsulation" rule above. > > o For case (2), the tunnel ingress node clears any PCN-marking on > the inner header. This rule is applied after the "copy on > encapsulation" rule above. > > I believe the first bullet gives a wrong recommendation for case (1). If > a CE-marked packet is tunneled, the rule clears that CE-mark and the > packet may leave the PCN domain without CE-mark. This violates RFC4774. > However, this issue could be solved by dropping such packets, but that > would be a nasty solution because finding them might be tricky. > Therefore, I'd be rather in favor to say that such tunnels SHOULD/MUST > not be used. > > An appendix in the 3-in-1 doc could correct this issue. > > Regards, > > Michael > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From karagian@cs.utwente.nl Mon Jul 11 07:35:20 2011 Return-Path: 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 CB32021F8C58; Mon, 11 Jul 2011 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XKh3DthVJ0m; Mon, 11 Jul 2011 07:35:20 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 282FE21F8C56; Mon, 11 Jul 2011 07:35:19 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p6BEXaOg018737; Mon, 11 Jul 2011 16:33:36 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 11 Jul 2011 14:35:22 +0000 To: "tsvwg@ietf.org" , "pcn@ietf.org" Date: Mon, 11 Jul 2011 14:35:22 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <20110711142038.25971.69732.idtracker@ietfa.amsl.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Mon, 11 Jul 2011 16:33:45 +0200 (MEST) Cc: "anuragb@cisco.com" Subject: [PCN] uploaded Generic Aggregation RSVP over PCN (v01) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:35:20 -0000 Hi all, I have just uploaded draft-karagiannis-pcn-tsvwg-rsvp-pcn-01, see: http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt This document specifies the extensions to the Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The main changes of this version compared to the previous version is that the aggregation is mainly based on the Generic Aggregation RSVP (RFC4860], instead of being based on the Agggation RSVP (RFC3175}. Comments are welcome! This draft is relevant for both WGs, PCN and tsvwg. I would therefore very much like to also get an tsvwg agenda slot (of 15 minutes)! Best regards, Georgios From philip.eardley@bt.com Mon Jul 11 09:04:28 2011 Return-Path: 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 2A2B821F8E98 for ; Mon, 11 Jul 2011 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWzkSyH3JhYT for ; Mon, 11 Jul 2011 09:04:27 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id E29C621F8E91 for ; Mon, 11 Jul 2011 09:04:24 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 11 Jul 2011 17:04:23 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.6]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 11 Jul 2011 17:04:23 +0100 From: To: Date: Mon, 11 Jul 2011 17:04:12 +0100 Thread-Topic: [PCN] 3-in-1: add some text on partially PCN-capable tunnels Thread-Index: Acw/prBsC3Q3lFozSQKpAc8ft7FGuQAO7swg Message-ID: <9510D26531EF184D9017DF24659BB87F32E2E265C1@EMV65-UKRD.domain1.systemhost.net> References: <4E1A1576.9070406@informatik.uni-tuebingen.de> <9510D26531EF184D9017DF24659BB87F32E2D34ACB@EMV65-UKRD.domain1.systemhost.net> <4E1AB7CB.1040509@informatik.uni-tuebingen.de> In-Reply-To: <4E1AB7CB.1040509@informatik.uni-tuebingen.de> 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] 3-in-1: add some text on partially PCN-capable tunnels X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 16:04:28 -0000 Doesnt make sense to me. Firstly, if 5559 is wrong then let's do an Erratum. It is not really pertin= ent to this draft. Come to think of it, ecn considerations are not very rel= evant either. Suggest we have one draft that does one thing. Secondly, the issue anyway is complicated, since 5559 is correct for 6040 t= unnels. And in your scenario there are various possibilities for how to han= dle. 5559 may also be misleading - the "rules" are supposed to mean "do som= ething that has this effect, although not necessarily by this method". Anyw= ay, it needs some thought. Not only for us writing, but also for reviewers = & iesg - another reason to keep it separate. It will undoubtedly hold up th= e progress of the 3in1 draft whilst we try and get this right. Apart from t= his issue we seem ready to WG last call, so suggest we keep separate and pr= ogress the encoding - 'strike whilst the iron is hot' Phil/ -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de]=20 Sent: 11 July 2011 09:44 To: Eardley,PL,Philip,DES8 R Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1: add some text on partially PCN-capable tunnels Am 11.07.2011 10:07, schrieb philip.eardley@bt.com: > I don't see why 3in1 is the right place to deal with this. The encoding doc is the right place to deal with the tunneling issues=20 because we redefine the ECN field in this doc. Therefore, we must assure=20 that the redefinition complies with RFC4774. Partially PCN-capable=20 tunnels may violate RFC4774. That is why the encoding document is the=20 right place for this issue. It's about the same reason why deal with the=20 coexistence of ECN and PCN marking in the appendix. Makes sense? Regards, Michael > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Mic= hael Menth > Sent: 10 July 2011 22:11 > To: pcn@ietf.org > Subject: [PCN] 3-in-1: add some text on partially PCN-capable tunnels > > Hi Toby and all, > > I see an issue with tunnels starting outside PCN domains and ending > inside PCN domains. I believe this should be clarified in an appendix to > 3-in-1 because this touches the coexistence between PCN and ECN. > > RFC5559 says: http://tools.ietf.org/html/rfc5559#section-4.7 > > Potential issues arise for a "partially PCN-capable tunnel", ie, > where only one tunnel endpoint is in the PCN-domain: > > 1. The tunnel originates outside a PCN-domain and ends inside it. > If the packet arrives at the tunnel ingress with the same > encoding as used within the PCN-domain to indicate PCN-marking, > then this could lead the PCN-egress-node to falsely measure pre- > congestion. > > 2. The tunnel originates inside a PCN-domain and ends outside it. > If the packet arrives at the tunnel ingress already PCN-marked, > then it will still have the same encoding when it's decapsulated= , > which could potentially confuse nodes beyond the tunnel egress. > > In line with the solution for partially capable Diffserv tunnels in > [RFC2983], the following rules are applied: > > o For case (1), the tunnel egress node clears any PCN-marking on th= e > inner header. This rule is applied before the "copy on > decapsulation" rule above. > > o For case (2), the tunnel ingress node clears any PCN-marking on > the inner header. This rule is applied after the "copy on > encapsulation" rule above. > > I believe the first bullet gives a wrong recommendation for case (1). If > a CE-marked packet is tunneled, the rule clears that CE-mark and the > packet may leave the PCN domain without CE-mark. This violates RFC4774. > However, this issue could be solved by dropping such packets, but that > would be a nasty solution because finding them might be tricky. > Therefore, I'd be rather in favor to say that such tunnels SHOULD/MUST > not be used. > > An appendix in the 3-in-1 doc could correct this issue. > > Regards, > > Michael > --=20 Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://www-kn.informatik.uni-tuebingen.de From toby@moncaster.com Mon Jul 11 13:04:50 2011 Return-Path: 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 B6AC011E81CE for ; Mon, 11 Jul 2011 13:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gWoXH-0VmYX for ; Mon, 11 Jul 2011 13:04:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id DE87111E8185 for ; Mon, 11 Jul 2011 13:04:48 -0700 (PDT) Received: from TobysHP (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LiYwK-1REbbf04EO-00ctAW; Mon, 11 Jul 2011 22:04:47 +0200 From: "Toby Moncaster" To: "'Toby Moncaster'" , References: <005d01cc3f18$80aa2120$81fe6360$@com> In-Reply-To: <005d01cc3f18$80aa2120$81fe6360$@com> Date: Mon, 11 Jul 2011 21:04:47 +0100 Message-ID: <006301cc4005$c9204090$5b60c1b0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01CC400E.2AE4A890" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acw/GIBT+nNR9qMGSf6rFTlbmF78hwA7IohQ Content-Language: en-gb X-Provags-ID: V02:K0:iWqKMvnz3d8pYoEtiW4WhxYvKs5Ge3eIp9gXcTBIGJn ovNzujqc7ypLxK4umXCtd8rWRc0DKW05QiNBU7oovoN7dqV8T5 MK4vHn2NrRL+uTXnUI4bOGNo2Ox1xPfeK9izL7GLENh+LQm8we mm/xzRlXfZK/vf7Zg72EPfHn4mmu2Hj+m24OgdtdiYayH1dewX fmmGSAP8nRv5OLlU5mPiOAsjTr+jbxQ5ArrQfrOA0Q= Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 20:04:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0064_01CC400E.2AE4A890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, There are a couple of nits with this version. Rather than issue a -07 version so soon after the -06 (and so near the deadline) I would rather hold these to any final revision following the WGLC (if there is another one). There is also one significant (potentially) outstanding issue, namely whether it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all cases. Some people are pushing for a slightly more complicated formulation where: . If both meters are being used to mark traffic, 01 MUST mean ThM and 11 MUST mean ETM. . If only ETM meter running, 11 MUST mean ETM . If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM Not sure if that's the clearest way of expressing it - basically the argument is if we restrict 11 to never mean ThM you restrict the applicability of this encoding in networks with pre-RFC6040 tunnels. This would be an excellent issue to get some discussion time in Quebec. Toby From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster Sent: 10 July 2011 16:46 To: pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt Hi All, After much change and debate we have finally posted a revised version of the 3-in-1 encoding. Given the fairly significant changes since the document went through its first WGLC the WGCs may decide it needs another WGLC... http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg Diffs from version 5: http://moncaster.com/3-in-1-diff-05--06.html Toby ------=_NextPart_000_0064_01CC400E.2AE4A890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

There are a couple of = nits with this version. Rather than issue a -07 version so soon after = the -06 (and so near the deadline) I would rather hold these to any = final revision following the WGLC (if there is another = one).

 

There is also one = significant (potentially) outstanding issue, namely whether it is right = to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all cases. Some = people are pushing for a slightly more complicated formulation = where:

 

·         = If both = meters are being used to mark traffic, 01 MUST mean ThM and 11 MUST mean = ETM.

·         = If only ETM = meter running, 11 MUST mean ETM

·         = If only ThM = meter running, 01 MUST mean ThM and 11 MAY mean = ETM

 

Not sure if that’s = the clearest way of expressing it – basically the argument is if = we restrict 11 to never mean ThM you restrict the applicability of this = encoding in networks with pre-RFC6040 tunnels.

 

This would be an = excellent issue to get some discussion time in = Quebec.

 

Toby

 

 

From:= = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Toby Moncaster
Sent: 10 July 2011 16:46
To: = pcn@ietf.org
Subject: Re: [PCN] New Version Notification for = draft-ietf-pcn-3-in-1-encoding-06.txt

 

Hi = All,

 

After much change and debate we have finally posted a = revised version of the 3-in-1 encoding. Given the fairly significant = changes since the document went through its first WGLC the WGCs may = decide it needs another WGLC...

 

http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encod= ing-06.txt

= http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html<= /o:p>

h= ttp://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf

h= ttp://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml

= http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg<= /o:p>

 

 

Diffs = from version 5:

 

http://moncaster.co= m/3-in-1-diff-05--06.html

 

Toby

------=_NextPart_000_0064_01CC400E.2AE4A890-- From philip.eardley@bt.com Tue Jul 12 01:34:03 2011 Return-Path: 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 07D4A21F90DB for ; Tue, 12 Jul 2011 01:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.879 X-Spam-Level: X-Spam-Status: No, score=-102.879 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sckpmNMTTMn for ; Tue, 12 Jul 2011 01:34:00 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.COM [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5753621F90DA for ; Tue, 12 Jul 2011 01:33:59 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 12 Jul 2011 09:33:58 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.162]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Tue, 12 Jul 2011 09:33:58 +0100 From: To: , Date: Tue, 12 Jul 2011 09:33:56 +0100 Thread-Topic: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt Thread-Index: Acw/GIBT+nNR9qMGSf6rFTlbmF78hwA7IohQABhuE+A= Message-ID: <9510D26531EF184D9017DF24659BB87F32E37168F6@EMV65-UKRD.domain1.systemhost.net> References: <005d01cc3f18$80aa2120$81fe6360$@com> <006301cc4005$c9204090$5b60c1b0$@com> In-Reply-To: <006301cc4005$c9204090$5b60c1b0$@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: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E37168F6EMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 08:34:03 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E37168F6EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's not how I'd put it, although you may illustrate that my suggestion i= s stupid. It's more like, * If only ThM meter running, then packets are either marked 01 or 1= 1; the same choice MUST be made by all nodes in the PCN-domain; the former = choice is the default but the latter MAY be used where a pre-RFC6040 tunnel= endpoint exists within the PCN-domain Maybe this is too complicated and doesn't give enough gain to be worth both= ering with, but the text changes would be something like:- In S4.3 The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3.1. =3D> The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3. {new text in brackets below} "Exception case" refers to S4.3 - this is where a "pre-RFC6040 tunnel endpo= int exists within a PCN-domain" (and "every PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint") 5.2.3.2. Marking using only the Threshold-meter Function The excess-traffic-meter function SHOULD be disabled and MUST NOT trigger any packet marking. {} The PCN-interior node SHOULD raise a management alarm if it receives an ETM packet, but the frequency of such alarms SHOULD be limited. If the threshold-meter function indicates a need to mark the packet: o the PCN-interior node MUST change NM to ThM; o the PCN-interior node MUST NOT change ETM to any other codepoint. It SHOULD raise an alarm as above. {} (probably easiest to insert it as a separate sub-section) phil From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby = Moncaster Sent: 11 July 2011 21:05 To: 'Toby Moncaster'; pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encod= ing-06.txt Hi All, There are a couple of nits with this version. Rather than issue a -07 versi= on so soon after the -06 (and so near the deadline) I would rather hold the= se to any final revision following the WGLC (if there is another one). There is also one significant (potentially) outstanding issue, namely wheth= er it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all= cases. Some people are pushing for a slightly more complicated formulation= where: * If both meters are being used to mark traffic, 01 MUST mean ThM a= nd 11 MUST mean ETM. * If only ETM meter running, 11 MUST mean ETM * If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM Not sure if that's the clearest way of expressing it - basically the argume= nt is if we restrict 11 to never mean ThM you restrict the applicability of= this encoding in networks with pre-RFC6040 tunnels. This would be an excellent issue to get some discussion time in Quebec. Toby From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby = Moncaster Sent: 10 July 2011 16:46 To: pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encod= ing-06.txt Hi All, After much change and debate we have finally posted a revised version of th= e 3-in-1 encoding. Given the fairly significant changes since the document = went through its first WGLC the WGCs may decide it needs another WGLC... http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg Diffs from version 5: http://moncaster.com/3-in-1-diff-05--06.html Toby --_000_9510D26531EF184D9017DF24659BB87F32E37168F6EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s not how I’d put it, although you may illus= trate that my suggestion is stupid.

It’s more like,

<=
span style=3D'mso-list:Ignore'>·         If only ThM meter running, then=
 packets are either marked 01 or 11; the same choice MUST be made by all no=
des in the PCN-domain; the former choice is the default but the latter MAY =
be used where a pre-RFC6040 tunnel endpoint exists within the PCN-do=
main

 

Maybe this is too complicated and doe= sn’t give enough gain to be worth bothering with, but the text change= s would be something like:-

 

<= span style=3D'color:#1F497D'>In S4.3

The behaviou= r of

   PCN-interior nodes in this case= is defined in Section 5.2.3.1.

=3D>

The behaviour of
   PCN-interior node=
s in this case is defined in Section 5.2.3.
 =
;
 
{new text in brackets below}<=
o:p>
“Exception case” refers to S4.3 – th=
is is where a “pre-RFC6040 tunnel endpoint exists
   within a PCN-domain” (and “every PCN-node in the= PCN-domain MUST be
   configured so that it=
 never sets the ThM codepoint”)
 
 

5.2.3.2.  Mar= king using only the Threshold-meter Function

=  

 

 &nb= sp; The excess-traffic-meter function SHOULD be disabled and MUST NOT<= /o:p>

   trigger any packet marking.

 

{<new/ In normal circums= tances the following applies:/new>}

 &nbs= p; The PCN-interior node SHOULD raise a management alarm if it receives

   an ETM packet, but the frequency of suc= h alarms SHOULD be limited.

 

   If the threshold-meter function indicates a need t= o mark the packet:

 

 

   o  t= he PCN-interior node MUST NOT change ETM to any other codepoint.=

      It SHOULD raise an alarm as = above.

 
{<new/ In the &#=
8220;Exception case” described in Section 4.3, it is possible for eit=
her the excess-traffic-meter or for the threshold-meter to trigger packets =
to be marked ‘11’. All PCN-nodes in the PCN-domain MUST be conf=
igured with the same choice. The excess-traffic-meter case was described in=
 Section 5.2.3.1. For the threshold-meter case the following rules apply:

   The PCN-interior node SHOULD raise a manag= ement alarm if it receives

   an 01 pac= ket, but the frequency of such alarms SHOULD be limited.<= /p>

 

   If the threshold-mete= r function indicates a need to mark the packet:

<= o:p> 

   o  the PCN-interior node = MUST change NM to 11;

 

   o  the PCN-interior node MUST NOT change 10 to any = other codepoint.

      I= t SHOULD raise an alarm as above.

/new>}

 

(probably easiest to insert it a= s a separate sub-section)

 

phil

<= span style=3D'color:#1F497D'> 

From: pcn-bounces@ietf.org [mailto= :pcn-bounces@ietf.org] On Behalf Of Toby Moncaster
Sent: 1= 1 July 2011 21:05
To: 'Toby Moncaster'; pcn@ietf.org
Subjec= t: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encodin= g-06.txt

 <= /o:p>

Hi All,

 = ;

There = are a couple of nits with this version. Rather than issue a -07 version so = soon after the -06 (and so near the deadline) I would rather hold these to = any final revision following the WGLC (if there is another one).=

 

There is = also one significant (potentially) outstanding issue, namely whether it is = right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all cases. S= ome people are pushing for a slightly more complicated formulation where:

 

·      &nb= sp;  If b= oth meters are being used to mark traffic, 01 MUST mean ThM and 11 MUST mea= n ETM.

·     &nbs= p;   If only ETM meter running, 11 MUST mean ETM

<= ![if !supportLists]>·         <= ![endif]>If only ThM meter running, 01 MUST m= ean ThM and 11 MAY mean ETM

 

<= span style=3D'color:#1F497D'>Not sure if that’s the clearest way of e= xpressing it – basically the argument is if we restrict 11 to never m= ean ThM you restrict the applicability of this encoding in networks with pr= e-RFC6040 tunnels.

 

This would be an excellent issue to get some discussion= time in Quebec.

 

Toby

 

 

<= p class=3DMsoNormal>From: pcn-bounces@ietf.org [mai= lto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster
Sent: 10 July 2011 16:46
To: pcn@ietf.org
Subject: Re: [PCN= ] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt

 

Hi All,

 =

After much change and debate we have finally poste= d a revised version of the 3-in-1 encoding. Given the fairly significant ch= anges since the document went through its first WGLC the WGCs may decide it= needs another WGLC...

 =

http://www.ietf.org/internet-drafts/= draft-ietf-pcn-3-in-1-encoding-06.txt

http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html

http://moncaster.com/PCN/draft-ietf-pc= n-3-in-1-encoding-06.pdf

http://= moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml

<= p class=3DMsoPlainText>http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-enco= ding-06.unpg

 

 

Diffs= from version 5:

 

http://moncaster.com/3-in-1-diff-05--06.html

 

Toby<= /p>

= --_000_9510D26531EF184D9017DF24659BB87F32E37168F6EMV65UKRDdoma_-- From philip.eardley@bt.com Thu Jul 14 01:44:06 2011 Return-Path: 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 E3EC021F8520 for ; Thu, 14 Jul 2011 01:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.888 X-Spam-Level: X-Spam-Status: No, score=-102.888 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReJ+QrN55-DN for ; Thu, 14 Jul 2011 01:44:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4D621F84E7 for ; Thu, 14 Jul 2011 01:44:02 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 14 Jul 2011 09:44:00 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.162]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 14 Jul 2011 09:44:01 +0100 From: To: , Date: Thu, 14 Jul 2011 09:43:59 +0100 Thread-Topic: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt Thread-Index: Acw/GIBT+nNR9qMGSf6rFTlbmF78hwA7IohQABhuE+AAZsjqMA== Message-ID: <9510D26531EF184D9017DF24659BB87F32E3AA192C@EMV65-UKRD.domain1.systemhost.net> References: <005d01cc3f18$80aa2120$81fe6360$@com> <006301cc4005$c9204090$5b60c1b0$@com> <9510D26531EF184D9017DF24659BB87F32E37168F6@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E37168F6@EMV65-UKRD.domain1.systemhost.net> 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: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E3AA192CEMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 08:44:07 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E3AA192CEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ok, Bob has persuaded me my suggestion is stupid. It creates ambiguity. There is no demand for this capability. So let's forg= et about it. Phil/ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of phili= p.eardley@bt.com Sent: 12 July 2011 09:34 To: toby@moncaster.com; pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encod= ing-06.txt That's not how I'd put it, although you may illustrate that my suggestion i= s stupid. It's more like, * If only ThM meter running, then packets are either marked 01 or 1= 1; the same choice MUST be made by all nodes in the PCN-domain; the former = choice is the default but the latter MAY be used where a pre-RFC6040 tunnel= endpoint exists within the PCN-domain Maybe this is too complicated and doesn't give enough gain to be worth both= ering with, but the text changes would be something like:- In S4.3 The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3.1. =3D> The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3. {new text in brackets below} "Exception case" refers to S4.3 - this is where a "pre-RFC6040 tunnel endpo= int exists within a PCN-domain" (and "every PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint") 5.2.3.2. Marking using only the Threshold-meter Function The excess-traffic-meter function SHOULD be disabled and MUST NOT trigger any packet marking. {} The PCN-interior node SHOULD raise a management alarm if it receives an ETM packet, but the frequency of such alarms SHOULD be limited. If the threshold-meter function indicates a need to mark the packet: o the PCN-interior node MUST change NM to ThM; o the PCN-interior node MUST NOT change ETM to any other codepoint. It SHOULD raise an alarm as above. {} (probably easiest to insert it as a separate sub-section) phil From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby = Moncaster Sent: 11 July 2011 21:05 To: 'Toby Moncaster'; pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encod= ing-06.txt Hi All, There are a couple of nits with this version. Rather than issue a -07 versi= on so soon after the -06 (and so near the deadline) I would rather hold the= se to any final revision following the WGLC (if there is another one). There is also one significant (potentially) outstanding issue, namely wheth= er it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all= cases. Some people are pushing for a slightly more complicated formulation= where: * If both meters are being used to mark traffic, 01 MUST mean ThM a= nd 11 MUST mean ETM. * If only ETM meter running, 11 MUST mean ETM * If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM Not sure if that's the clearest way of expressing it - basically the argume= nt is if we restrict 11 to never mean ThM you restrict the applicability of= this encoding in networks with pre-RFC6040 tunnels. This would be an excellent issue to get some discussion time in Quebec. Toby From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby = Moncaster Sent: 10 July 2011 16:46 To: pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encod= ing-06.txt Hi All, After much change and debate we have finally posted a revised version of th= e 3-in-1 encoding. Given the fairly significant changes since the document = went through its first WGLC the WGCs may decide it needs another WGLC... http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg Diffs from version 5: http://moncaster.com/3-in-1-diff-05--06.html Toby --_000_9510D26531EF184D9017DF24659BB87F32E3AA192CEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ok, Bob has persuaded me my suggestion is stupid.

It creates ambiguity. There is no dem= and for this capability. So let’s forget about it.<= /p>

Phil/<= /p>

 

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of p= hilip.eardley@bt.com
Sent: 12 July 2011 09:34
To: toby@= moncaster.com; pcn@ietf.org
Subject: Re: [PCN] New Version Notifi= cation for draft-ietf-pcn-3-in-1-encoding-06.txt

 

That’s not how I’d put it, although yo= u may illustrate that my suggestion is stupid.

It’s more like,

·         If only ThM meter ru=
nning, then packets are either marked 01 or 11; the same choice MUST be mad=
e by all nodes in the PCN-domain; the former choice is the default but the =
latter MAY be used where a pre-RFC6040 tunnel endpoint exists within=
 the PCN-domain

 

Maybe this is too complica= ted and doesn’t give enough gain to be worth bothering with, but the = text changes would be something like:-

 

In S4.3

T= he behaviour of

   PCN-interior nodes i= n this case is defined in Section 5.2.3.1.

=3D>

The behaviour of
   PCN-in=
terior nodes in this case is defined in Section 5.2.3.
 
 
{new text in brack=
ets below}
“Exception case” refers to S4.3=
 – this is where a “pre-RFC6040 tunnel endpoint exists
   within a PCN-domain” (and “every PCN-=
node in the PCN-domain MUST be
   configured=
 so that it never sets the ThM codepoint”)
=
 
 

5.2.3.2= .  Marking using only the Threshold-meter Function

 

 

   trigger any packet marking.

 

{<new/ In norma= l circumstances the following applies:/new>}

&= nbsp;  The PCN-interior node SHOULD raise a management alarm if it rec= eives

   an ETM packet, but the frequen= cy of such alarms SHOULD be limited.

 <= /o:p>

   If the threshold-meter function indicates= a need to mark the packet:

 

   o  the PCN-interior node MUST change NM to Th= M;

 

   = o  the PCN-interior node MUST NOT change ETM to any other codepoint.

      It SHOULD raise an = alarm as above.

 
{<new/ =
In the “Exception case” described in Section 4.3, it is possibl=
e for either the excess-traffic-meter or for the threshold-meter to trigger=
 packets to be marked ‘11’. All PCN-nodes in the PCN-domain MUS=
T be configured with the same choice. The excess-traffic-meter case was des=
cribed in Section 5.2.3.1. For the threshold-meter case the following rules=
 apply:

   The PCN-interior node SHOULD rais= e a management alarm if it receives

   = an 01 packet, but the frequency of such alarms SHOULD be limited.

 

   If the thres= hold-meter function indicates a need to mark the packet:<= /p>

 

   o  the PCN-inter= ior node MUST change NM to 11;

 <= /span>

   o  the PCN-interior node MUST NOT change 1= 0 to any other codepoint.

    = ;  It SHOULD raise an alarm as above.

/new>}

 

=

(probably easiest to ins= ert it as a separate sub-section)

 

phil

 

From: pcn-bounces@ietf.o= rg [mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster
S= ent: 11 July 2011 21:05
To: 'Toby Moncaster'; pcn@ietf.orgSubject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in= -1-encoding-06.txt

 

Hi Al= l,

=  

There are a couple of nits with this version. Rather than issue a -07 v= ersion so soon after the -06 (and so near the deadline) I would rather hold= these to any final revision following the WGLC (if there is another one).<= o:p>

 

There is also one significant (potentially) outstanding issue, namely whet= her it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in al= l cases. Some people are pushing for a slightly more complicated formulatio= n where:

 

&midd= ot;    &nb= sp;    If both meters are being used to mark traffic, 01 MUST mean ThM and= 11 MUST mean ETM.

·   &nb= sp;     If only ETM meter running, 11 MUST mean ETM=

·         If only ThM meter runnin= g, 01 MUST mean ThM and 11 MAY mean ETM

 

Not sure if that’s the cle= arest way of expressing it – basically the argument is if we restrict= 11 to never mean ThM you restrict the applicability of this encoding in ne= tworks with pre-RFC6040 tunnels.

=  

This would be an excellent issue to get s= ome discussion time in Quebec.

 

Toby

 

 

From: pcn-bounces@= ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby MoncasterSent: 10 July 2011 16:46
To: pcn@ietf.org
Subject:= Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-= 06.txt

 

Hi All,

 

After much change and debate we have = finally posted a revised version of the 3-in-1 encoding. Given the fairly s= ignificant changes since the document went through its first WGLC the WGCs = may decide it needs another WGLC...

 

http://www.ietf.org/int= ernet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt

http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-= 06.html

http://moncaster.com/PCN/= draft-ietf-pcn-3-in-1-encoding-06.pdf

http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml

http://moncaster.com/PCN/draft-ietf-pcn= -3-in-1-encoding-06.unpg

&nb= sp;

 

Diffs from version 5:

&nb= sp;

http://moncaster.com/3-in-1-diff-05--06.html

 

Toby=

= --_000_9510D26531EF184D9017DF24659BB87F32E3AA192CEMV65UKRDdoma_-- From toby@moncaster.com Sat Jul 16 03:55:22 2011 Return-Path: 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 3C8B821F84FE for ; Sat, 16 Jul 2011 03:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI133BdPBp2F for ; Sat, 16 Jul 2011 03:55:19 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7244021F84EC for ; Sat, 16 Jul 2011 03:55:16 -0700 (PDT) Received: from TobysHP (host86-156-55-237.range86-156.btcentralplus.com [86.156.55.237]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MNeGY-1QpCCA3uos-006pDI; Sat, 16 Jul 2011 12:55:14 +0200 From: "Toby Moncaster" To: References: <005d01cc3f18$80aa2120$81fe6360$@com> <006301cc4005$c9204090$5b60c1b0$@com> <9510D26531EF184D9017DF24659BB87F32E37168F6@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F32E3AA192C@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F32E3AA192C@EMV65-UKRD.domain1.systemhost.net> Date: Sat, 16 Jul 2011 11:55:08 +0100 Message-ID: <001401cc43a6$d58d9680$80a8c380$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01CC43AF.3751FE80" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acw/GIBT+nNR9qMGSf6rFTlbmF78hwA7IohQABhuE+AAZsjqMABpIOkA Content-Language: en-gb X-Provags-ID: V02:K0:bg42bzUpNodAartWYB7+4Mw1unYbVW/g33TXNjgYxDA S0bdJbPjATu9kgIDyVmnpa8XcjSnNBWukEpQo8vrDuYozncgBM sM6RpJwuHfnmbT9B22SQXkwFYkIgqnXsbGhKl6c8crf0aaJn/G 37NYZ7yu2ZrJhCdoEAVfi0WOsTVJcT3bWkAV8I9tvPNJ1Xa89G rxnsTGzSdVGSlIvGbVEWQkn4Lstz5y+TEfBp1WpbaE= Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2011 10:55:22 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01CC43AF.3751FE80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK, that means the current document is ready to ship apart from a couple of minor nits (one typo and one where I used the phrase "single marking schemes" where I meant to say "schemes only using one PCN marking") I am not sure if either of the other authors is in Quebec, if so perhaps they can summarise the state of the document to the WG and seek guidance on whether we need to get another WGLC or not. Toby From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: 14 July 2011 09:44 To: toby@moncaster.com; pcn@ietf.org Subject: RE: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt Ok, Bob has persuaded me my suggestion is stupid. It creates ambiguity. There is no demand for this capability. So let's forget about it. Phil/ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 12 July 2011 09:34 To: toby@moncaster.com; pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt That's not how I'd put it, although you may illustrate that my suggestion is stupid. It's more like, . If only ThM meter running, then packets are either marked 01 or 11; the same choice MUST be made by all nodes in the PCN-domain; the former choice is the default but the latter MAY be used where a pre-RFC6040 tunnel endpoint exists within the PCN-domain Maybe this is too complicated and doesn't give enough gain to be worth bothering with, but the text changes would be something like:- In S4.3 The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3.1 . => The behaviour of PCN-interior nodes in this case is defined in Section 5.2.3. {new text in brackets below} "Exception case" refers to S4.3 - this is where a "pre-RFC6040 tunnel endpoint exists within a PCN-domain" (and "every PCN-node in the PCN-domain MUST be configured so that it never sets the ThM codepoint") 5.2.3.2. Marking using only the Threshold-meter Function The excess-traffic-meter function SHOULD be disabled and MUST NOT trigger any packet marking. {} The PCN-interior node SHOULD raise a management alarm if it receives an ETM packet, but the frequency of such alarms SHOULD be limited. If the threshold-meter function indicates a need to mark the packet: o the PCN-interior node MUST change NM to ThM; o the PCN-interior node MUST NOT change ETM to any other codepoint. It SHOULD raise an alarm as above. {} (probably easiest to insert it as a separate sub-section) phil From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster Sent: 11 July 2011 21:05 To: 'Toby Moncaster'; pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt Hi All, There are a couple of nits with this version. Rather than issue a -07 version so soon after the -06 (and so near the deadline) I would rather hold these to any final revision following the WGLC (if there is another one). There is also one significant (potentially) outstanding issue, namely whether it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all cases. Some people are pushing for a slightly more complicated formulation where: . If both meters are being used to mark traffic, 01 MUST mean ThM and 11 MUST mean ETM. . If only ETM meter running, 11 MUST mean ETM . If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM Not sure if that's the clearest way of expressing it - basically the argument is if we restrict 11 to never mean ThM you restrict the applicability of this encoding in networks with pre-RFC6040 tunnels. This would be an excellent issue to get some discussion time in Quebec. Toby From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster Sent: 10 July 2011 16:46 To: pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt Hi All, After much change and debate we have finally posted a revised version of the 3-in-1 encoding. Given the fairly significant changes since the document went through its first WGLC the WGCs may decide it needs another WGLC... http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg Diffs from version 5: http://moncaster.com/3-in-1-diff-05--06.html Toby ------=_NextPart_000_0015_01CC43AF.3751FE80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, that means the current document is ready to = ship apart from a couple of minor nits (one typo and one where I used = the phrase “single marking schemes” where I meant to say = “schemes only using one PCN = marking”)

 

I am not sure if either = of the other authors is in Quebec, if so perhaps they can summarise the = state of the document to the WG and seek guidance on whether we need to = get another WGLC or not.

 

Toby

 

From:= = philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: 14 = July 2011 09:44
To: toby@moncaster.com; = pcn@ietf.org
Subject: RE: [PCN] New Version Notification for = draft-ietf-pcn-3-in-1-encoding-06.txt

 

Ok, Bob has persuaded me my suggestion is = stupid.

It creates ambiguity. There is no demand for = this capability. So let’s forget about it.

Phil/=

 

From:= = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: 12 July 2011 = 09:34
To: toby@moncaster.com; pcn@ietf.org
Subject: = Re: [PCN] New Version Notification for = draft-ietf-pcn-3-in-1-encoding-06.txt

 

That’s not how I’d put it, although = you may illustrate that my suggestion is stupid.

It’s more = like,

·         =
If only ThM =
meter running, then packets are either marked 01 or 11; the same choice =
MUST be made by all nodes in the PCN-domain; the former choice is the =
default but the latter MAY be used where a pre-RFC6040 tunnel =
endpoint exists within the PCN-domain

 

Maybe this is too = complicated and doesn’t give enough gain to be worth bothering = with, but the text changes would be something = like:-

 

In = S4.3

The behaviour = of

   = PCN-interior nodes in this case is defined in Section 5.2.3.1.

=3D>

The behaviour =
of
   PCN-interior nodes in this case is =
defined in Section =
5.2.3.
 
 =

{new text in brackets =
below}
“Exception case” refers to S4.3 =
– this is where a “pre-RFC6040 tunnel endpoint =
exists
   within a PCN-domain” (and =
“every PCN-node in the PCN-domain MUST =
be
   configured so that it never sets =
the ThM =
codepoint”)
 
&=
nbsp;

5.2.3.2.  Marking = using only the Threshold-meter Function

 

 

   The = excess-traffic-meter function SHOULD be disabled and MUST = NOT

   = trigger any packet marking.

 

{<new/ In normal = circumstances the following applies:/new>}

   The PCN-interior node SHOULD raise a management alarm = if it receives

   an ETM = packet, but the frequency of such alarms SHOULD be = limited.

 

   If the = threshold-meter function indicates a need to mark the = packet:

 

   = o  the PCN-interior node MUST change NM to = ThM;

 

   = o  the PCN-interior node MUST NOT change ETM to any other = codepoint.

      It SHOULD raise an alarm as = above.

 
{<new/ In the =
“Exception case” described in Section 4.3, it is possible =
for either the excess-traffic-meter or for the threshold-meter to =
trigger packets to be marked ‘11’. All PCN-nodes in the =
PCN-domain MUST be configured with the same choice. The =
excess-traffic-meter case was described in Section 5.2.3.1. For the =
threshold-meter case the following rules apply:

   The PCN-interior node SHOULD raise a management alarm = if it receives

   an 01 = packet, but the frequency of such alarms SHOULD be = limited.

 

   If the = threshold-meter function indicates a need to mark the = packet:

 

   = o  the PCN-interior node MUST change NM to = 11;

 

   = o  the PCN-interior node MUST NOT change 10 to any other = codepoint.

      It SHOULD raise an alarm as = above.

/new>}

 

(probably easiest to = insert it as a separate sub-section)

 

phil

 

From:= = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Toby Moncaster
Sent: 11 July 2011 21:05
To: = 'Toby Moncaster'; pcn@ietf.org
Subject: Re: [PCN] New Version = Notification for = draft-ietf-pcn-3-in-1-encoding-06.txt

 

Hi All,

 

There are a couple of = nits with this version. Rather than issue a -07 version so soon after = the -06 (and so near the deadline) I would rather hold these to any = final revision following the WGLC (if there is another = one).

 

There is also one = significant (potentially) outstanding issue, namely whether it is right = to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all cases. Some = people are pushing for a slightly more complicated formulation = where:

 

·         = If both = meters are being used to mark traffic, 01 MUST mean ThM and 11 MUST mean = ETM.

·         = If only ETM = meter running, 11 MUST mean ETM

·         = If only ThM = meter running, 01 MUST mean ThM and 11 MAY mean = ETM

 

Not sure if that’s = the clearest way of expressing it – basically the argument is if = we restrict 11 to never mean ThM you restrict the applicability of this = encoding in networks with pre-RFC6040 tunnels.

 

This would be an = excellent issue to get some discussion time in = Quebec.

 

Toby

 

 

From:= = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Toby Moncaster
Sent: 10 July 2011 16:46
To: = pcn@ietf.org
Subject: Re: [PCN] New Version Notification for = draft-ietf-pcn-3-in-1-encoding-06.txt

 

Hi = All,

 

After much change and debate we have finally posted a = revised version of the 3-in-1 encoding. Given the fairly significant = changes since the document went through its first WGLC the WGCs may = decide it needs another WGLC...

 

http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encod= ing-06.txt

= http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html<= /o:p>

h= ttp://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf

h= ttp://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml

= http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg<= /o:p>

 

 

Diffs = from version 5:

 

http://moncaster.co= m/3-in-1-diff-05--06.html

 

Toby

------=_NextPart_000_0015_01CC43AF.3751FE80-- From karagian@cs.utwente.nl Thu Jul 21 13:35:49 2011 Return-Path: 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 5D28B21F8876; Thu, 21 Jul 2011 13:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.038 X-Spam-Level: X-Spam-Status: No, score=0.038 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BP+5brg1WN56; Thu, 21 Jul 2011 13:35:48 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by ietfa.amsl.com (Postfix) with ESMTP id 535FC21F886A; Thu, 21 Jul 2011 13:35:48 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id p6LKXq3V011782; Thu, 21 Jul 2011 22:33:52 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 21 Jul 2011 20:35:53 +0000 To: "tsvwg@ietf.org" , "pcn@ietf.org" Date: Thu, 21 Jul 2011 20:35:53 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Thu, 21 Jul 2011 22:34:01 +0200 (MEST) Subject: [PCN] soliciting comments for "Generic aggregation RSVP over PCN" draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 20:35:49 -0000 Hi all, You might know that the following draft has been submitted to the PCN WG and the tsvwg: http://www.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt We solicit comments on this draft from the members of PCN WG and tsvwg, since this draft might be relevant for both WGs. Below we are providing some information regarding the motivation of writing this draft and the additions to RFC 4860 and the PCN edge behaviour drafts, specified in this draft: Motivation (problem statement): ------------- o) All PCN charter items are fulfilled, except: Submit Encoding and Transport of PCN from the Domain Egress to the Ingress to the IESG for consideration as a Proposed Standard RFC: o) Pairs of PCN-ingress-node and PCN-egress-node use ingress-egress-aggregates (IEA): collection of PCN-packets from all PCN-flows that travel in one direction between a specific pair of PCN-boundary-nodes: =3D> Need a signaling protocol to transport PCN information from PCN-egress-node to PCN-ingress-node that is able to maintain ingress-egress-aggregate between each pair of PCN-ingress-node and PCN-egress-node Possible IETF QoS signaling protocols to solve the above problem: ----------------------------------- o) Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979) o) Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175) o) Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860) All can be used, but for time being we selected RFC 4860 due to: o) possible deployment interest o) Supports RFC 3175 and additonal features such as: *) support of multiple IEAs from same pair of PCN edge nodes *) support of bandwidth reduction for individual flows (RFC 4495) Some augmentations needed for RFC 4860, see below: ---------------------------------------------------- o) Four new (2 for CL and 2 for SM) objects specified to include PCN information to be transported from PCN-egress-node to PCN-ingress-node o) Each Aggregator and Deaggregator support policies to initiate and maintain for each combination of a PCN-boundary-node and all other PCN-boundary-nodes of the same PCN domain one RSVP SESSION for generic aggregated reservations *) RSVP SESSION for generic aggregated reservations can match to one or more than one ingress-egress-aggregates. o) For each supported IEA, PCN-egress-node, periodically (end of each PCN measurement interval) generates Aggregated Resv messages and include new PCN object and send it to associated PCN-ingress-node o) PCN-interior-nodes are not using E2E RSVP or Generic Aggregated RSVP messages, but treated as normal packets. o) E2E RSVP session admission in PCN-domain: *) Each Aggregator support policies and PCN functionalities to admit or reject an incoming e2e RSVP Path message (in RFC4086 this is done by Deaggregator) and send a PathErr towards the sender. o) E2E RSVP flow termination in PCN-domain: *) Each Aggregator support policies and PCN functionalities to support the initiation of termination of one or more active E2E RSVP sessions and/or to reduce the bandwidth of one or more active individual existing RSVP sessions, in order to solve congestion in PCN-domain *) Same mechanisms for terminating or reducing bandwidth of an e2e RSVP session can be followed as specified in [RFC4495] Some augmentations might be needed for PCN CL and SM edge behavior drafts, see below: ---------------------------------------------------- In order to use all the advanced features of the Generic aggregation RSVP, minor augmentations on the CL and SM edge behavior drafts might be needed: Considered that PCN-ingress-node collocated with Decision point o) More than one IEAs between the same pair of PCN edge nodes should be supported, each of them using a different PHB-ID value o) When IEA supported by a PCN-ingress-node is in PCN-admission state, then based on a local policy, the requesting e2e RSVP session should be either rejected or should be mapped to another IEA that is NOT in PCN-admission-state o) When for an IEA supported by a PCN-ingress-node incoming traffic needs to be reduced (to reduce congestion in PCN-domain), then based on a local policy and for same IEA, select a number of e2e RSVP sessions: either to be terminated and/or to reduce the reserved bandwidth of e2e RSVP sessions, in order to decrease total incoming amount of incoming traffic associated with IEA by amount of traffic to be terminated Best regards, Georgios From bob.briscoe@bt.com Mon Jul 25 01:52:40 2011 Return-Path: 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 5676B21F8B3C for ; Mon, 25 Jul 2011 01:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl-TLvE9da98 for ; Mon, 25 Jul 2011 01:52:39 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by ietfa.amsl.com (Postfix) with ESMTP id 748DF21F8B38 for ; Mon, 25 Jul 2011 01:52:39 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 09:52:37 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 09:52:37 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1311583955622; Mon, 25 Jul 2011 09:52:35 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.195.121]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6P8qXXd032132; Mon, 25 Jul 2011 09:52:34 +0100 Message-Id: <201107250852.p6P8qXXd032132@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Jul 2011 09:52:29 +0100 To: Steven Blake From: Bob Briscoe In-Reply-To: <1309718950.32690.3.camel@tachyon> References: <1309718950.32690.3.camel@tachyon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Jul 2011 08:52:37.0312 (UTC) FILETIME=[33EE5400:01CC4AA8] Cc: pcn Subject: Re: [PCN] IETF-81 proposed agenda X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 08:52:40 -0000 Steve, I'm the TBD for the 3-in-1 encoding slot. Sorry I've just woken up to there not being a name against the slot. Bob At 19:49 03/07/2011, Steven Blake wrote: >Hi, > >Here is a proposed agenda for the WG meeting in Quebec City. Note that >PCN only has a one-hour slot, but since it comes at the end of the >afternoon sessions, it may be possible to spill over into the break. > >We need someone to lead the discussion of the 3-in-1 and edge behaviour >drafts so that they can go (back) to the IESG. > >Please send comments to the list. > > >Regards, > >// Steve > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Mon Jul 25 04:54:34 2011 Return-Path: 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 E2C3D21F8515 for ; Mon, 25 Jul 2011 04:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.792 X-Spam-Level: X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=-0.590, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDuW3k+sVXDR for ; Mon, 25 Jul 2011 04:54:33 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 224A721F8BBE for ; Mon, 25 Jul 2011 03:53:44 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 11:53:43 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 11:53:43 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1311591221172; Mon, 25 Jul 2011 11:53:41 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.195.121]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6PArcxq032728; Mon, 25 Jul 2011 11:53:38 +0100 Message-Id: <201107251053.p6PArcxq032728@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Jul 2011 11:53:38 +0100 To: Toby Moncaster From: Bob Briscoe In-Reply-To: <001401cc43a6$d58d9680$80a8c380$@com> References: <005d01cc3f18$80aa2120$81fe6360$@com> <006301cc4005$c9204090$5b60c1b0$@com> <9510D26531EF184D9017DF24659BB87F32E37168F6@EMV65-UKRD.domain1.systemhost.net> <9510D26531EF184D9017DF24659BB87F32E3AA192C@EMV65-UKRD.domain1.systemhost.net> <001401cc43a6$d58d9680$80a8c380$@com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_39392243==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Jul 2011 10:53:43.0545 (UTC) FILETIME=[1EF17E90:01CC4AB9] Cc: pcn@ietf.org Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 11:54:35 -0000 --=====================_39392243==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Toby, For the benefit of the list, I did a thorough=20 read through and I produced an update, but we=20 decided not to post before the deadline. I would argue that we should post this update for=20 WGLC rather than merging it with any other=20 requests for update from the WGLC. There are=20 significant improvements to clarity, which will=20 otherwise not be reviewed. In particular, both=20 the following changes are fairly major reworkings of text: * Clarified that each operator not the IETF chooses which DSCP(s) are PCN-compatible, and made it unambiguous that only PCN-nodes recognise that PCN-compatible DSCPs enable the 3-in-1 encoding. * Corrected the final para of "Rational for Different Behaviours in Schemes with Only One Marking" (new heading for Appendix D) Bob At 11:55 16/07/2011, Toby Moncaster wrote: >Content-Type: multipart/alternative; > boundary=3D"----=3D_NextPart_000_0015_01CC43AF.3751FE80" >Content-Language: en-gb > >OK, that means the current document is ready to=20 >ship apart from a couple of minor nits (one typo=20 >and one where I used the phrase =93single marking=20 >schemes=94 where I meant to say =93schemes only using one PCN marking=94) > >I am not sure if either of the other authors is=20 >in Quebec, if so perhaps they can summarise the=20 >state of the document to the WG and seek=20 >guidance on whether we need to get another WGLC or not. > >Toby > >From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >Sent: 14 July 2011 09:44 >To: toby@moncaster.com; pcn@ietf.org >Subject: RE: [PCN] New Version Notification for=20 >draft-ietf-pcn-3-in-1-encoding-06.txt > >Ok, Bob has persuaded me my suggestion is stupid. >It creates ambiguity. There is no demand for=20 >this capability. So let=92s forget about it. >Phil/ > >From: pcn-bounces@ietf.org=20 >[mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com >Sent: 12 July 2011 09:34 >To: toby@moncaster.com; pcn@ietf.org >Subject: Re: [PCN] New Version Notification for=20 >draft-ietf-pcn-3-in-1-encoding-06.txt > >That=92s not how I=92d put it, although you may=20 >illustrate that my suggestion is stupid. >It=92s more like, > >=B7 If only ThM meter running, then=20 >packets are either marked 01 or 11; the same=20 >choice MUST be made by all nodes in the=20 >PCN-domain; the former choice is the default but=20 >the latter MAY be used where a pre-RFC6040=20 >tunnel endpoint exists within the PCN-domain > >Maybe this is too complicated and doesn=92t give=20 >enough gain to be worth bothering with, but the=20 >text changes would be something like:- > >In S4.3 >The behaviour of > PCN-interior nodes in this case is defined=20 > in=20 >= Section=20 > 5.2.3.1. >=3D> > >The behaviour of > > PCN-interior nodes in this case is defined in Section 5.2.3. > > > > > >{new text in brackets below} > >=93Exception case=94 refers to S4.3 =96 this is where=20 >a =93pre-RFC6040 tunnel endpoint exists > > within a PCN-domain=94 (and =93every PCN-node in the PCN-domain MUST be > > configured so that it never sets the ThM codepoint=94) > > > > 5.2.3.2. Marking using only the Threshold-meter Function > > > The excess-traffic-meter function SHOULD be disabled and MUST NOT > trigger any packet marking. > >{} > The PCN-interior node SHOULD raise a management alarm if it receives > an ETM packet, but the frequency of such alarms SHOULD be limited. > > If the threshold-meter function indicates a need to mark the packet: > > o the PCN-interior node MUST change NM to ThM; > > o the PCN-interior node MUST NOT change ETM to any other codepoint. > It SHOULD raise an alarm as above. > > > >{Section 4.3, it is possible for either the=20 >excess-traffic-meter or for the threshold-meter=20 >to trigger packets to be marked =9111=92. All=20 >PCN-nodes in the PCN-domain MUST be configured=20 >with the same choice. The excess-traffic-meter=20 >case was described in Section 5.2.3.1. For the=20 >threshold-meter case the following rules=20 >apply: The PCN-interior node SHOULD raise a management alarm if it= receives > an 01 packet, but the frequency of such alarms SHOULD be limited. > > If the threshold-meter function indicates a need to mark the packet: > > o the PCN-interior node MUST change NM to 11; > > o the PCN-interior node MUST NOT change 10 to any other codepoint. > It SHOULD raise an alarm as above. >/new>} > >(probably easiest to insert it as a separate sub-section) > >phil > >From: pcn-bounces@ietf.org=20 >[mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster >Sent: 11 July 2011 21:05 >To: 'Toby Moncaster'; pcn@ietf.org >Subject: Re: [PCN] New Version Notification for=20 >draft-ietf-pcn-3-in-1-encoding-06.txt > >Hi All, > >There are a couple of nits with this version.=20 >Rather than issue a -07 version so soon after=20 >the -06 (and so near the deadline) I would=20 >rather hold these to any final revision=20 >following the WGLC (if there is another one). > >There is also one significant (potentially)=20 >outstanding issue, namely whether it is right to=20 >mandate that 01 MUST mean ThM and 11 MUST mean=20 >ETM in all cases. Some people are pushing for a=20 >slightly more complicated formulation where: > >=B7 If both meters are being used to mark=20 >traffic, 01 MUST mean ThM and 11 MUST mean ETM. >=B7 If only ETM meter running, 11 MUST mean ETM >=B7 If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM > >Not sure if that=92s the clearest way of=20 >expressing it =96 basically the argument is if we=20 >restrict 11 to never mean ThM you restrict the=20 >applicability of this encoding in networks with pre-RFC6040 tunnels. > >This would be an excellent issue to get some discussion time in Quebec. > >Toby > > >From: pcn-bounces@ietf.org=20 >[mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster >Sent: 10 July 2011 16:46 >To: pcn@ietf.org >Subject: Re: [PCN] New Version Notification for=20 >draft-ietf-pcn-3-in-1-encoding-06.txt > >Hi All, > >After much change and debate we have finally=20 >posted a revised version of the 3-in-1 encoding.=20 >Given the fairly significant changes since the=20 >document went through its first WGLC the WGCs=20 >may decide it needs another WGLC... > >= http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt >http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html >http://monc= aster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf >http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml >http://mon= caster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg > > >Diffs from version 5: > >http://moncaster.com/3-in-1-d= iff-05--06.html=20 > > >Toby >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 --=====================_39392243==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Toby,

For the benefit of the list, I did a thorough read through and I produced an update, but we decided not to post before the deadline.

I would argue that we should post this update for WGLC rather than merging it with any other requests for update from the WGLC. There are significant improvements to clarity, which will otherwise not be reviewed. In particular, both the following changes are fairly major reworkings of text:

* Clarified that each operator not the IETF chooses which DSCP(s)
are PCN-compatible, and made it unambiguous that only PCN-nodes
recognise that PCN-compatible DSCPs enable the 3-in-1 encoding.
* Corrected the final para of "Rational for Different Behaviours
in Schemes with Only One Marking" (new heading for Appendix D)



Bob

At 11:55 16/07/2011, Toby Moncaster wrote:
Content-Type: multipart/alternative;
         boundary=3D"----=3D_NextPart_000_0015_01CC43AF.3751FE80"
Content-Language: en-gb

OK, that means the current document is ready to ship apart from a couple of minor nits (one typo and one where I used the phrase =93single marking schemes=94 where I meant to say =93schemes only using one PCN marking=94)  
I am not sure if either of the other authors is in Quebec, if so perhaps they can summarise the state of the document to the WG and seek guidance on whether we need to get another WGLC or not.
 
Toby
 
From: philip.eardley@bt.com [ mailto:philip.eardley@bt.com]
Sent: 14 July 2011 09:44
To: toby@moncaster.com; pcn@ietf.org
Subject: RE: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt
 
Ok, Bob has persuaded me my suggestion is stupid.
It creates ambiguity. There is no demand for this capability. So let=92s forget about it.
Phil/
 
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 12 July 2011 09:34
To: toby@moncaster.com; pcn@ietf.org
Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt
 
That=92s not how I=92d put it, although you may illustrate that my suggestio= n is stupid.
It=92s more like,

=B7         If only ThM meter
running, then packets are either marked 01 or 11; the same choice MUST be
made by all nodes in the PCN-domain; the former choice is the default but
the latter MAY be used where a pre-RFC6040 tunnel endpoint exists within
the PCN-domain

 
Maybe this is too complicated and doesn=92t give enough gain to be worth bothering with, but the text changes would be something like:-
 
In S4.3
The behaviour of
   PCN-interior nodes in this case is defined in Section 5.2.3.1.
=3D>

The behaviour of


   PCN-interior nodes in this case is defined in Section
5.2.3.


 


 


{new text in brackets below}


=93Exception case=94 refers to S4.3 =96 this is where a =93pre-RFC6040
tunnel endpoint exists


   within a PCN-domain=94 (and =93every PCN-node in the
PCN-domain MUST be


   configured so that it never sets the ThM
codepoint=94)


 


 
5.2.3.2.  Marking using only the Threshold-meter Function
 
 
   The excess-traffic-meter function SHOULD be disabled and MUST NOT
   trigger any packet marking.
 
{<new/ In normal circumstances the following applies:/new>}
   The PCN-interior node SHOULD raise a management alarm if it receives
   an ETM packet, but the frequency of such alarms SHOULD be limited.
 
   If the threshold-meter function indicates a need to mark the packet:
 
   o  the PCN-interior node MUST change NM to ThM;
 
   o  the PCN-interior node MUST NOT change ETM to any other codepoint.
      It SHOULD raise an alarm as above.

 


{<new/ In the =93Exception case=94 described in Section 4.3, it is
possible for either the excess-traffic-meter or for the threshold-meter
to trigger packets to be marked =9111=92. All PCN-nodes in the PCN-domain
MUST be configured with the same choice. The excess-traffic-meter case
was described in Section 5.2.3.1. For the threshold-meter case the
following rules apply:
   The PCN-interior node SHOULD raise a management alarm if it receives
   an 01 packet, but the frequency of such alarms SHOULD be limited.
 
   If the threshold-meter function indicates a need to mark the packet:
 
   o  the PCN-interior node MUST change NM to 11;
 
   o  the PCN-interior node MUST NOT change 10 to any other codepoint.
      It SHOULD raise an alarm as above.
/new>}
 
(probably easiest to insert it as a separate sub-section)
 
phil
 
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster
Sent: 11 July 2011 21:05
To: 'Toby Moncaster'; pcn@ietf.org
Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt
 
Hi All,
 
There are a couple of nits with this version. Rather than issue a -07 version so soon after the -06 (and so near the deadline) I would rather hold these to any final revision following the WGLC (if there is another one).
 
There is also one significant (potentially) outstanding issue, namely whether it is right to mandate that 01 MUST mean ThM and 11 MUST mean ETM in all cases. Some people are pushing for a slightly more complicated formulation where:
 
=B7         If both meters are being used to mark traffic, 01 MUST mean ThM and 11 MUST mean ETM.
=B7         If only ETM meter running, 11 MUST mean ETM
=B7         If only ThM meter running, 01 MUST mean ThM and 11 MAY mean ETM
 
Not sure if that=92s the clearest way of expressing it =96 basically the argument is if we restrict 11 to never mean ThM you restrict the applicability of this encoding in networks with pre-RFC6040 tunnels.
 
This would be an excellent issue to get some discussion time in Quebec.
 
Toby
 
 
From: pcn-bounces@ietf.org [ mailto:pcn-bounces@ietf.org] On Behalf Of Toby Moncaster
Sent: 10 July 2011 16:46
To: pcn@ietf.org
Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-3-in-1-encoding-06.txt
 
Hi All,
 
After much change and debate we have finally posted a revised version of the 3-in-1 encoding. Given the fairly significant changes since the document went through its first WGLC the WGCs may decide it needs another WGLC...
 
http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-06.txt
http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.html
http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.pdf
http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.xml
http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-06.unpg
 
 
Diffs from version 5:
 
http://moncaster.com/3-in-1-diff-05--06.html
 
Toby
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,           &n= bsp;            =         BT Innovate & Design --=====================_39392243==.ALT-- From bob.briscoe@bt.com Mon Jul 25 09:18:06 2011 Return-Path: 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 D7D4421F8C1D for ; Mon, 25 Jul 2011 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q26DPgviXMk for ; Mon, 25 Jul 2011 09:18:04 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by ietfa.amsl.com (Postfix) with ESMTP id 04ED121F8F47 for ; Mon, 25 Jul 2011 08:49:32 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 16:49:32 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jul 2011 16:49:31 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1311608970337; Mon, 25 Jul 2011 16:49:30 +0100 Received: from MUT.jungle.bt.co.uk ([10.73.128.74]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id p6PFnQff001830; Mon, 25 Jul 2011 16:49:28 +0100 Message-Id: <201107251549.p6PFnQff001830@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 25 Jul 2011 16:49:27 +0100 To: Scott O Bradner , Steven BLAKE From: Bob Briscoe In-Reply-To: <6496C9BE-4CE8-41E1-8DE7-B8E6BFEDD885@sobco.com> References: <1309718950.32690.3.camel@tachyon> <201107250852.p6P8qXXd032132@bagheera.jungle.bt.co.uk> <6496C9BE-4CE8-41E1-8DE7-B8E6BFEDD885@sobco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_57140974==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Jul 2011 15:49:31.0459 (UTC) FILETIME=[71864130:01CC4AE2] Cc: Michael Menth , PCN IETF list Subject: [PCN] draft-ietf-pcn-3-in-1-encoding slides for w-g session this pm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:18:07 -0000 --=====================_57140974==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed PCN Chairs, Slides for <draft-ietf-pcn-3-in-1-encoding-06.txt> are at: Bob At 13:36 25/07/2011, Scott O Bradner wrote: >ack > >On Jul 25, 2011, at 4:52 AM, Bob Briscoe wrote: > > > Steve, > > > > I'm the TBD for the 3-in-1 encoding slot. > > > > Sorry I've just woken up to there not being a name against the slot. > > > > > > Bob > > > > At 19:49 03/07/2011, Steven Blake wrote: > >> Hi, > >> > >> Here is a proposed agenda for the WG meeting in Quebec City. Note that > >> PCN only has a one-hour slot, but since it comes at the end of the > >> afternoon sessions, it may be possible to spill over into the break. > >> > >> We need someone to lead the discussion of the 3-in-1 and edge behaviour > >> drafts so that they can go (back) to the IESG. > >> > >> Please send comments to the list. > >> > >> > >> Regards, > >> > >> // Steve > >> > >> > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcn > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_57140974==.ALT Content-Type: text/html; charset="us-ascii" PCN Chairs,

Slides for < draft-ietf-pcn-3-in-1-encoding-06.txt> are at:

< http://bobbriscoe.net/presents/1107ietf/1107pcn-enc-3-in-1.ppt>
< http://bobbriscoe.net/presents/1107ietf/1107pcn-enc-3-in-1.pdf>


Bob

At 13:36 25/07/2011, Scott O Bradner wrote:

ack

On Jul 25, 2011, at 4:52 AM, Bob Briscoe wrote:

> Steve,
>
> I'm the TBD for the 3-in-1 encoding slot.
>
> Sorry I've just woken up to there not being a name against the slot.
>
>
> Bob
>
> At 19:49 03/07/2011, Steven Blake wrote:
>> Hi,
>>
>> Here is a proposed agenda for the WG meeting in Quebec City.  Note that
>> PCN only has a one-hour slot, but since it comes at the end of the
>> afternoon sessions, it may be possible to spill over into the break.
>>
>> We need someone to lead the discussion of the 3-in-1 and edge behaviour
>> drafts so that they can go (back) to the IESG.
>>
>> Please send comments to the list.
>>
>>
>> Regards,
>>
>> // Steve
>>
>>
>> _______________________________________________
>> PCN mailing list
>> PCN@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcn
>
> ________________________________________________________________
> Bob Briscoe,                                BT Innovate & Design
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_57140974==.ALT-- From philip.eardley@bt.com Wed Jul 27 14:41:24 2011 Return-Path: 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 D2D8311E8082 for ; Wed, 27 Jul 2011 14:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaElsXmhTKq4 for ; Wed, 27 Jul 2011 14:41:23 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBCC11E80F5 for ; Wed, 27 Jul 2011 14:41:23 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 22:41:21 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.162]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 27 Jul 2011 22:41:22 +0100 From: To: Date: Wed, 27 Jul 2011 22:41:21 +0100 Thread-Topic: PCN Signalling documents Thread-Index: AQHMTKXslJJC+QVdjEqb6gnJFaARhg== Message-ID: <9510D26531EF184D9017DF24659BB87F32E39B3ECC@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E39B3ECCEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [PCN] PCN Signalling documents X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 21:41:24 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E39B3ECCEMV65UKRDdoma_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to summarise a chat that Bob & I had with Dave H after the WG meeting = - which personally I found very useful in clarifying the (potential) way fo= rward. ie what should be in which documents. * in the signalling requirements doc, we currently list what each message c= ontains (such as "rate of PCN-marked traffic (PM-rate)". The suggestion is = to add a definition of the format of the info (I guess something like, "a n= byte field in octets/second") * say that in circumstances then you SHOULD use - but if your circumstances are different then this may not be the right= signalling but you're on your own to decide what to do * in the RSVP doc define the signalling of the info (Bob, Dave - Hope I got right what we discussed) Does this sound sensible? best wishes phil/ --_000_9510D26531EF184D9017DF24659BB87F32E39B3ECCEMV65UKRDdoma_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Just to= summarise a chat that Bob & I had with Dave H after the WG meeting&nbs= p;- which personally I found very useful in clarifying the (potential) way = forward. ie what should be in which documents.
 
* in the signalling requirements doc= , we currently list what each message contains (such as "r= ate of PCN-marked traffic (PM-rate)". The suggestion is to add a defin= ition of the format of the info (I guess something like, "a n byte field in octets/second")

 

* say that in <these> circumstances then you= SHOULD use <rsvp signalling doc> - but if your circumstances are dif= ferent then this may not be the right signalling but you're on your own to = decide what to do

 

* in the RSVP doc define the signalling of the inf= o

 

(Bob, Dave - Hope I got right what we discussed)

 

Does this sound sensible?

 

best wishes

phil/

--_000_9510D26531EF184D9017DF24659BB87F32E39B3ECCEMV65UKRDdoma_-- From internet-drafts@ietf.org Sat Jul 30 09:38:50 2011 Return-Path: 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 2C73521F889A; Sat, 30 Jul 2011 09:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Pi58us7XmXT; Sat, 30 Jul 2011 09:38:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BE121F8781; Sat, 30 Jul 2011 09:38:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.57 Message-ID: <20110730163849.16585.15293.idtracker@ietfa.amsl.com> Date: Sat, 30 Jul 2011 09:38:49 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 16:38:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Encoding 3 PCN-States in the IP header using a single DS= CP Author(s) : Bob Briscoe Toby Moncaster Michael Menth Filename : draft-ietf-pcn-3-in-1-encoding-07.txt Pages : 23 Date : 2011-07-30 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to decision points which then decide whether to admit or block new flow requests or to terminate some already-admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding provides for up to three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC5696. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-07.txt From toby@moncaster.com Sat Jul 30 09:44:04 2011 Return-Path: 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 D58DB21F8A7A for ; Sat, 30 Jul 2011 09:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpb0eK9BCLmI for ; Sat, 30 Jul 2011 09:44:04 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id CD91C21F8A4F for ; Sat, 30 Jul 2011 09:44:03 -0700 (PDT) Received: from TobysHP (host86-141-39-82.range86-141.btcentralplus.com [86.141.39.82]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M5P83-1RbijE1x43-00zSZo; Sat, 30 Jul 2011 18:44:04 +0200 From: "Toby Moncaster" To: Date: Sat, 30 Jul 2011 17:44:01 +0100 Message-ID: <001c01cc4ed7$e331ab00$a9950100$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CC4EE0.44F61300" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxO1+KODGr/p0woQKGCThlDpTtFRA== Content-Language: en-gb X-Provags-ID: V02:K0:fYFfNyAQZc6666t8xKWk+O/r38u6DRHCEQ/honPZrGZ lIAij0p6A54Qebcg2JXsNzwmD7L2MsI35KvrEXaBup0hUUHiFb lwcA+UnNEER5IjMW4foVomW44Bm+Wn8Hz1SPBssmHxzFA2dSnH THjT7QxpK/audvI/Y37w+LqqnfxMORivj8udo1ehy1UEv0Lzgz YUopXLsowPt5Ak7nsoENvCsXHGJFNIXDkR6bpEq95Y= Subject: [PCN] new version of 3-in-1 encoding X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 16:44:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001D_01CC4EE0.44F61300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, I have just uploaded the (hopefully) final revision of draft-ietf-pcn-3-in-1-encoding. This should now be ready for another WGLC. Files: Diffs: Toby ------=_NextPart_000_001D_01CC4EE0.44F61300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

I have just uploaded the (hopefully) final revision of = draft-ietf-pcn-3-in-1-encoding. This should now be ready for another = WGLC.

 

Files:

<http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encod= ing-07.txt>

<http://www.moncaster.com/PCN/draft-ietf-pcn-3-in= -1-encoding-07.xml>

<http://www.moncaster.com/PCN/draft-ietf-pcn-3-in= -1-encoding-07.html>

<http://www.moncaster.com/PCN/draft-ietf-pcn-3-in= -1-encoding-07.unpg>

 

Diffs: =

<http://= www.moncaster.com/PCN/diff-PCN-3-in-1-06--07.html>

<= p class=3DMsoPlainText> 

 

Toby

------=_NextPart_000_001D_01CC4EE0.44F61300-- From sob@harvard.edu Sat Jul 30 12:39:46 2011 Return-Path: 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 8D46421F8A7D for ; Sat, 30 Jul 2011 12:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6TrBrtjfTHH for ; Sat, 30 Jul 2011 12:39:41 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3F21F8752 for ; Sat, 30 Jul 2011 12:39:41 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 34034D99DE1; Sat, 30 Jul 2011 15:39:42 -0400 (EDT) To: pcn@ietf.org Message-Id: <20110730193942.34034D99DE1@newdev.eecs.harvard.edu> Date: Sat, 30 Jul 2011 15:39:42 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jul 2011 19:39:46 -0000 this starts a WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt comments by July 15 please Scott From toby@moncaster.com Sun Jul 31 03:10:07 2011 Return-Path: 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 D8B0E21F87F9 for ; Sun, 31 Jul 2011 03:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJDgYvvVocnM for ; Sun, 31 Jul 2011 03:10:07 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2861A21F85B2 for ; Sun, 31 Jul 2011 03:10:07 -0700 (PDT) Received: from TobysHP (host86-141-39-82.range86-141.btcentralplus.com [86.141.39.82]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M03oK-1RfZ1I2OhI-00uf5R; Sun, 31 Jul 2011 12:09:44 +0200 From: "Toby Moncaster" To: "'Scott O. Bradner'" , References: <20110730193942.34034D99DE1@newdev.eecs.harvard.edu> In-Reply-To: <20110730193942.34034D99DE1@newdev.eecs.harvard.edu> Date: Sun, 31 Jul 2011 11:09:42 +0100 Message-ID: <000c01cc4f69$f7d6c670$e7845350$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxO8HNGjG0YXJDmTbKPumikx1PHUAAeWw8A Content-Language: en-gb X-Provags-ID: V02:K0:Jw3Ha2AvGgbE3WKJJ6ycAbOQO8GlZ4FgT6TxB+/XHqo 93WZ2n2y4bcDiBdHl5NJe3jikmuCkpTkrgtZfCeFPJvuBewpbU Nvn+wucYUzfZufPiym0H24RIy+e73516HppMTNsqOy2/IS7uM4 zjYqY1V4B9CVwCXZhlaYiFT4VpuDH8Hn2kYAkigmtG3UjX7zQo l/vUFyeRbBfC/9fcLkaxwfSTGcPLYcZML85F5MSshM= Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2011 10:10:08 -0000 I'm guessing you mean comments by August 15? (otherwise this will be a ~350 day LC!) Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Scott O. Bradner > Sent: 30 July 2011 20:40 > To: pcn@ietf.org > Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt > > > this starts a WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt > > comments by July 15 please > > Scott > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From sob@harvard.edu Sun Jul 31 17:55:51 2011 Return-Path: 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 719A721F86D8 for ; Sun, 31 Jul 2011 17:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.063 X-Spam-Level: X-Spam-Status: No, score=-102.063 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5lh8WGRhzyA for ; Sun, 31 Jul 2011 17:55:50 -0700 (PDT) Received: from barracuda.ethostream.com (gleek.ethostream.com [66.195.129.15]) by ietfa.amsl.com (Postfix) with ESMTP id 86BF121F8777 for ; Sun, 31 Jul 2011 17:55:50 -0700 (PDT) X-ASG-Debug-ID: 1312159617-5d8000030000-3O2MQJ X-Barracuda-URL: http://66.195.129.15:8000/cgi-bin/mark.cgi Received: from relay.ethostream.com (www3.ethostream.com [66.195.129.13]) by barracuda.ethostream.com (Spam & Virus Firewall) with ESMTP id 608A911D1116 for ; Sun, 31 Jul 2011 19:46:57 -0500 (CDT) Received: from relay.ethostream.com (www3.ethostream.com [66.195.129.13]) by barracuda.ethostream.com with ESMTP id V40eBzra5tUcFGVk for ; Sun, 31 Jul 2011 19:46:57 -0500 (CDT) Received: from ethoserver.ezone.net (173-167-136-97-illinois.hfc.comcastbusiness.net [173.167.136.97]) by relay.ethostream.com (Postfix) with ESMTPA id 3AA89890356 for ; Sun, 31 Jul 2011 19:46:54 -0500 (CDT) Received: from soblap3.sobco.com (unknown [172.16.1.172]) by ethoserver.ezone.net (Postfix) with ESMTP id 22529A1F6AF for ; Sun, 31 Jul 2011 19:46:43 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by soblap3.sobco.com (Postfix) with ESMTP id 645353BBC01; Sun, 31 Jul 2011 13:38:05 -0400 (EDT) X-ASG-Orig-Subj: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-8-966719948 From: Scott O Bradner In-Reply-To: <000c01cc4f69$f7d6c670$e7845350$@com> Date: Sun, 31 Jul 2011 13:38:05 -0400 Message-Id: References: <20110730193942.34034D99DE1@newdev.eecs.harvard.edu> <000c01cc4f69$f7d6c670$e7845350$@com> To: Toby Moncaster X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: www3.ethostream.com[66.195.129.13] X-Barracuda-Start-Time: 1312159617 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at ethostream.com X-Barracuda-Spam-Score: 1.11 X-Barracuda-Spam-Status: No, SCORE=1.11 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1.4 tests=DATE_IN_PAST_06_12, DATE_IN_PAST_06_12_2, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.70548 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date 0.00 HTML_MESSAGE BODY: HTML included in message 1.10 DATE_IN_PAST_06_12_2 DATE_IN_PAST_06_12_2 Cc: pcn@ietf.org Subject: Re: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 00:55:51 -0000 --Apple-Mail-8-966719948 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii sigh - tooooo long a IETF meeting :-) Scott On Jul 31, 2011, at 6:09 AM, Toby Moncaster wrote: > I'm guessing you mean comments by August 15? (otherwise this will be a ~350 > day LC!) > > Toby > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Scott O. Bradner >> Sent: 30 July 2011 20:40 >> To: pcn@ietf.org >> Subject: [PCN] WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt >> >> >> this starts a WGLC for draft-ietf-pcn-3-in-1-encoding-07.txt >> >> comments by July 15 please >> >> Scott >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > Scott Bradner Harvard University Information Technology Security | Policy, Risk & Compliance +1 617 495 3864 29 Oxford St., Room 407 Cambridge, MA 02138 www.harvard.edu/huit --Apple-Mail-8-966719948 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii sigh = - tooooo long a IETF meeting =  :-)

Scott

On Jul 31, = 2011, at 6:09 AM, Toby Moncaster wrote:

I'm = guessing you mean comments by August 15? (otherwise this will be a = ~350
day LC!)

Toby

-----Original Message-----
From: pcn-bounces@ietf.org = [mailto:pcn-bounces@ietf.org] On Behalf Of
Scott O. Bradner
Sent: 30 July 2011 20:40
To: pcn@ietf.org
Subject: [PCN] WGLC for = draft-ietf-pcn-3-in-1-encoding-07.txt


this starts a = WGLC for = draft-ietf-pcn-3-in-1-encoding-07.txt

comments by = July 15 please

Scott
_______________________________________________
PCN mailing = list
PCN@ietf.org
https://www.ietf.org/ma= ilman/listinfo/pcn


Scott = Bradner

Harvard University Information = Technology
Security | Policy, Risk & = Compliance
+1 617 495 3864
29 Oxford St., Room = 407
Cambridge, MA 02138
<= div>



= --Apple-Mail-8-966719948--