From Internet-Drafts@ietf.org Tue Jan 11 01:30:06 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457D33A69F8; Tue, 11 Jan 2011 01:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGrBLBCS3EIb; Tue, 11 Jan 2011 01:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C002D3A6A22; Tue, 11 Jan 2011 01:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111093001.3063.20587.idtracker@localhost> Date: Tue, 11 Jan 2011 01:30:01 -0800 Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-3-in-1-encoding-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:30:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Encoding 3 PCN-States in the IP header using a single DSCP Author(s) : B. Briscoe, et al. Filename : draft-ietf-pcn-3-in-1-encoding-04.txt Pages : 13 Date : 2011-01-11 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and 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 builds on the baseline encoding of RFC5696 and provides for 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-3-in-1-encoding-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11012353.I-D@ietf.org> --NextPart-- From toby@moncaster.com Tue Jan 11 01:35:01 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA3D3A6A13 for ; Tue, 11 Jan 2011 01:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBNUv5DPrK8u for ; Tue, 11 Jan 2011 01:35:00 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 4E38A3A6975 for ; Tue, 11 Jan 2011 01:35:00 -0800 (PST) Received: from TobysHP (host86-141-35-164.range86-141.btcentralplus.com [86.141.35.164]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0LphYc-1QFn2L0SsI-00etNX; Tue, 11 Jan 2011 10:37:15 +0100 From: "Toby Moncaster" To: "'pcn'" Date: Tue, 11 Jan 2011 09:37:16 -0000 Message-ID: <001401cbb173$22a7aa80$67f6ff80$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuxcZY6tbrRmbu7R3SxvMHMGJv3EgAADt5Q Content-Language: en-gb X-Provags-ID: V02:K0:ebNhe1p9roDmYG4f2V3UTlKBLBQLo3apCdN7rCvxj+o mDOZen3/z2Ihl92wpwHJNopbhF/uHjAZdq8BcP93ygcRfWnWyw /en4kCQNe1QJVi515jFrnDbliIXvTvUpdjntMIEH+6sT3xdXY4 qXO2qEWnbJmUt5OWijrDs29+sgPtJEb9qH4/4iH7AhHNxjfyHk 8jU8fiq1pd90gxI+AUENN7N8BuqmNDsOglJ91nxwuI= Subject: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:35:01 -0000 I have released an updated version of the 3-in-1 encoding reflecting the = recent publication of Bob's tunnelling RFC (RFC6040). Txt at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.txt HTML at: http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.html XML at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.xml UNPG at: http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.unpg = Diffs at: http://moncaster.com/PCN/PCN-3-in-1-diff-03--04.html=20 NEXT STEPS FOR WG: We now need to decide the next steps for the document. Originally this = was menat to be one of a set of experimental extensions to RFC5696 = baseline encoding. However that was changed with the publication of = RFC6040. Given that RFC6040 is standards track the suggestion from the authors is = that this document should become a standards track extension to baseline = encoding. That seems to give the greatest flexibility to operators: If you know your PCN-domain is fully compliant with RFC6040 and you want = to use both marking behaviours you choose 3-in-1 encoding If the PCN-domain uses legacy tunnels you have to use baseline encoding If the PCN-domain only uses threshold marking you use baseline encoding If (in future) an edge behaviour emerges calling for just = excess-traffic-marking then you use either baseline or 3-in-1 encoding. If the WG agree then the next version of this will be standards track, = and I believe this is probably in a fit state for WGLC... Toby=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 11 January 2011 09:24 > To: toby@moncaster.com > Cc: bob.briscoe@bt.com; menth@informatik.uni-tuebingen.de > Subject: New Version Notification for = draft-ietf-pcn-3-in-1-encoding-04 >=20 >=20 > A new version of I-D, draft-ietf-pcn-3-in-1-encoding-04.txt has been > successfully submitted by Toby Moncaster and posted to the IETF > repository. >=20 > Filename: draft-ietf-pcn-3-in-1-encoding > Revision: 04 > Title: Encoding 3 PCN-States in the IP header using a > single DSCP > Creation_date: 2011-01-11 > WG ID: pcn > Number_of_pages: 13 >=20 > Abstract: > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv domain. > On every link in the PCN domain, the overall rate of the PCN-traffic > is metered, and PCN-packets are appropriately marked when certain > configured rates are exceeded. Egress nodes provide decision points > with information about the PCN-marks of PCN-packets which allows them > to take decisions about whether to admit or block a new flow request, > and to terminate some already admitted flows during serious pre- > congestion. >=20 > 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 builds on the baseline > encoding of RFC5696 and provides for 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. >=20 >=20 >=20 > The IETF Secretariat. From menth@informatik.uni-tuebingen.de Tue Jan 11 01:52:24 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF863A69F8 for ; Tue, 11 Jan 2011 01:52:24 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuR2mbir1edD for ; Tue, 11 Jan 2011 01:52:22 -0800 (PST) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by core3.amsl.com (Postfix) with SMTP id 47CFF3A6975 for ; Tue, 11 Jan 2011 01:52:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3D4C0529E for ; Tue, 11 Jan 2011 10:54:34 +0100 (MET) 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 ck7FXti497ZT for ; Tue, 11 Jan 2011 10:54:29 +0100 (MET) 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 7B6365291 for ; Tue, 11 Jan 2011 10:54:29 +0100 (MET) Received: from [134.2.11.131] (chaos.Informatik.Uni-Tuebingen.De [134.2.11.131]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1616E109ED01 for ; Tue, 11 Jan 2011 10:54:29 +0100 (CET) Message-ID: <4D2C28D4.50206@informatik.uni-tuebingen.de> Date: Tue, 11 Jan 2011 10:54:28 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: pcn@ietf.org References: <001401cbb173$22a7aa80$67f6ff80$@com> In-Reply-To: <001401cbb173$22a7aa80$67f6ff80$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 09:52:24 -0000 A small addition ... Am 11.01.2011 10:37, schrieb Toby Moncaster: > I have released an updated version of the 3-in-1 encoding reflecting the recent publication of Bob's tunnelling RFC (RFC6040). > > Txt at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.txt > HTML at: http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.html > XML at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.xml > UNPG at: http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.unpg > > Diffs at: > > http://moncaster.com/PCN/PCN-3-in-1-diff-03--04.html > > NEXT STEPS FOR WG: > > We now need to decide the next steps for the document. Originally this was menat to be one of a set of experimental extensions to RFC5696 baseline encoding. However that was changed with the publication of RFC6040. > > Given that RFC6040 is standards track the suggestion from the authors is that this document should become a standards track extension to baseline encoding. That seems to give the greatest flexibility to operators: > > If you know your PCN-domain is fully compliant with RFC6040 ... or does not use tunnels inside the PCN domain ... (I think that's right? I hope we've captured that?) > and you want to use both marking behaviours you choose 3-in-1 encoding > > If the PCN-domain uses legacy tunnels you have to use baseline encoding > > If the PCN-domain only uses threshold marking you use baseline encoding > > If (in future) an edge behaviour emerges calling for just excess-traffic-marking then you use either baseline or 3-in-1 encoding. > > If the WG agree then the next version of this will be standards track, and I believe this is probably in a fit state for WGLC... > > Toby > >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: 11 January 2011 09:24 >> To: toby@moncaster.com >> Cc: bob.briscoe@bt.com; menth@informatik.uni-tuebingen.de >> Subject: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04 >> >> >> A new version of I-D, draft-ietf-pcn-3-in-1-encoding-04.txt has been >> successfully submitted by Toby Moncaster and posted to the IETF >> repository. >> >> Filename: draft-ietf-pcn-3-in-1-encoding >> Revision: 04 >> Title: Encoding 3 PCN-States in the IP header using a >> single DSCP >> Creation_date: 2011-01-11 >> WG ID: pcn >> Number_of_pages: 13 >> >> Abstract: >> The objective of Pre-Congestion Notification (PCN) is to protect the >> quality of service (QoS) of inelastic flows within a Diffserv domain. >> On every link in the PCN domain, the overall rate of the PCN-traffic >> is metered, and PCN-packets are appropriately marked when certain >> configured rates are exceeded. Egress nodes provide decision points >> with information about the PCN-marks of PCN-packets which allows them >> to take decisions about whether to admit or block a new flow request, >> and 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 builds on the baseline >> encoding of RFC5696 and provides for 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. >> >> >> >> The IETF Secretariat. > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Prof. Dr. habil. Michael Menth University of Tuebingen Wilhelm-Schickard-Institute 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.net2.uni-tuebingen.de From slblake@petri-meat.com Sat Jan 22 17:53:34 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278633A6BC3 for ; Sat, 22 Jan 2011 17:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6gokwTAFJDC for ; Sat, 22 Jan 2011 17:53:33 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 2C0453A6BC5 for ; Sat, 22 Jan 2011 17:53:32 -0800 (PST) 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 1PgpBg-0004EY-SV; Sat, 22 Jan 2011 20:56:16 -0500 From: Steven Blake To: Toby Moncaster In-Reply-To: <001401cbb173$22a7aa80$67f6ff80$@com> References: <001401cbb173$22a7aa80$67f6ff80$@com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 22 Jan 2011 20:56:15 -0500 Message-ID: <1295747775.32307.9.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' Subject: Re: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 01:53:34 -0000 On Tue, 2011-01-11 at 09:37 +0000, Toby Moncaster wrote: > I have released an updated version of the 3-in-1 encoding reflecting > the recent publication of Bob's tunnelling RFC (RFC6040). > > Txt at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.txt > HTML at: > http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.html > XML at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.xml > UNPG at: > http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.unpg > > Diffs at: > > http://moncaster.com/PCN/PCN-3-in-1-diff-03--04.html > > NEXT STEPS FOR WG: > > We now need to decide the next steps for the document. Originally this > was menat to be one of a set of experimental extensions to RFC5696 > baseline encoding. However that was changed with the publication of > RFC6040. > > Given that RFC6040 is standards track the suggestion from the authors > is that this document should become a standards track extension to > baseline encoding. That seems to give the greatest flexibility to > operators: > > If you know your PCN-domain is fully compliant with RFC6040 and you > want to use both marking behaviours you choose 3-in-1 encoding > > If the PCN-domain uses legacy tunnels you have to use baseline > encoding > > If the PCN-domain only uses threshold marking you use baseline > encoding > > If (in future) an edge behaviour emerges calling for just > excess-traffic-marking then you use either baseline or 3-in-1 > encoding. > > If the WG agree then the next version of this will be standards track, > and I believe this is probably in a fit state for WGLC... I am happy to start a WGLC on this draft, but the WG needs to decide whether or not to move it to standards track (assuming that is ok with the ADs). Any comments? Regards, // Steve From philip.eardley@bt.com Mon Jan 24 01:57:49 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AFB3A6837 for ; Mon, 24 Jan 2011 01:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXdPbEppwakd for ; Mon, 24 Jan 2011 01:57:48 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.COM [62.239.224.235]) by core3.amsl.com (Postfix) with ESMTP id 565FF3A681B for ; Mon, 24 Jan 2011 01:57:47 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 24 Jan 2011 10:00:40 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.68]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 24 Jan 2011 10:00:36 +0000 From: To: , Date: Mon, 24 Jan 2011 10:00:35 +0000 Thread-Topic: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04 Thread-Index: Acu6oMEYEuDP8pm2Rn2yYz+WNz+xmgBDJ2aQ Message-ID: <9510D26531EF184D9017DF24659BB87F3276A4DBFF@EMV65-UKRD.domain1.systemhost.net> References: <001401cbb173$22a7aa80$67f6ff80$@com> <1295747775.32307.9.camel@tachyon> In-Reply-To: <1295747775.32307.9.camel@tachyon> 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] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jan 2011 09:57:49 -0000 I'm happy with this approach, providing it won't delay it. In other words, = happy to be guided by the ADs advice -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steve= n Blake Sent: 23 January 2011 01:56 To: Toby Moncaster Cc: 'pcn' Subject: Re: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-e= ncoding-04 On Tue, 2011-01-11 at 09:37 +0000, Toby Moncaster wrote: > I have released an updated version of the 3-in-1 encoding reflecting > the recent publication of Bob's tunnelling RFC (RFC6040). >=20 > Txt at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.txt > HTML at: > http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.html > XML at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.xml > UNPG at: > http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.unpg=20 >=20 > Diffs at: >=20 > http://moncaster.com/PCN/PCN-3-in-1-diff-03--04.html=20 >=20 > NEXT STEPS FOR WG: >=20 > We now need to decide the next steps for the document. Originally this > was menat to be one of a set of experimental extensions to RFC5696 > baseline encoding. However that was changed with the publication of > RFC6040. >=20 > Given that RFC6040 is standards track the suggestion from the authors > is that this document should become a standards track extension to > baseline encoding. That seems to give the greatest flexibility to > operators: >=20 > If you know your PCN-domain is fully compliant with RFC6040 and you > want to use both marking behaviours you choose 3-in-1 encoding >=20 > If the PCN-domain uses legacy tunnels you have to use baseline > encoding >=20 > If the PCN-domain only uses threshold marking you use baseline > encoding >=20 > If (in future) an edge behaviour emerges calling for just > excess-traffic-marking then you use either baseline or 3-in-1 > encoding. >=20 > If the WG agree then the next version of this will be standards track, > and I believe this is probably in a fit state for WGLC... I am happy to start a WGLC on this draft, but the WG needs to decide whether or not to move it to standards track (assuming that is ok with the ADs). Any comments? Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Fri Jan 28 01:46:31 2011 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65EF53A6974 for ; Fri, 28 Jan 2011 01:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.507 X-Spam-Level: X-Spam-Status: No, score=0.507 tagged_above=-999 required=5 tests=[AWL=-0.385, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r8AOtLL3g6H for ; Fri, 28 Jan 2011 01:46:29 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 11CDB3A6967 for ; Fri, 28 Jan 2011 01:46:28 -0800 (PST) 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 p0S9nKu3028234; Fri, 28 Jan 2011 10:49:20 +0100 (MET) Received: from 130.89.12.129 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 28 Jan 2011 09:49:21 +0000 To: "philip.eardley@bt.com" , "slblake@petri-meat.com" , "toby@moncaster.com" Date: Fri, 28 Jan 2011 09:49:21 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <9510D26531EF184D9017DF24659BB87F3276A4DBFF@EMV65-UKRD.domain1.systemhost.net> 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]); Fri, 28 Jan 2011 10:49:29 +0100 (MET) Cc: "pcn@ietf.org" Subject: Re: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-encoding-04 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 09:46:31 -0000 Hi all I also agree with this proposal! Best regards, Georgios On 1/24/2011, "philip.eardley@bt.com" wrote: >I'm happy with this approach, providing it won't delay it. In other words, h= appy to be guided by the ADs advice > >-----Original Message----- >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steven= Blake >Sent: 23 January 2011 01:56 >To: Toby Moncaster >Cc: 'pcn' >Subject: Re: [PCN] FW: New Version Notification for draft-ietf-pcn-3-in-1-en= coding-04 > >On Tue, 2011-01-11 at 09:37 +0000, Toby Moncaster wrote: > >> I have released an updated version of the 3-in-1 encoding reflecting >> the recent publication of Bob's tunnelling RFC (RFC6040). >> >> Txt at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.txt >> HTML at: >> http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.html >> XML at: http://www.ietf.org/id/draft-ietf-pcn-3-in-1-encoding-04.xml >> UNPG at: >> http://moncaster.com/PCN/draft-ietf-pcn-3-in-1-encoding-04.unpg >> >> Diffs at: >> >> http://moncaster.com/PCN/PCN-3-in-1-diff-03--04.html >> >> NEXT STEPS FOR WG: >> >> We now need to decide the next steps for the document. Originally this >> was menat to be one of a set of experimental extensions to RFC5696 >> baseline encoding. However that was changed with the publication of >> RFC6040. >> >> Given that RFC6040 is standards track the suggestion from the authors >> is that this document should become a standards track extension to >> baseline encoding. That seems to give the greatest flexibility to >> operators: >> >> If you know your PCN-domain is fully compliant with RFC6040 and you >> want to use both marking behaviours you choose 3-in-1 encoding >> >> If the PCN-domain uses legacy tunnels you have to use baseline >> encoding >> >> If the PCN-domain only uses threshold marking you use baseline >> encoding >> >> If (in future) an edge behaviour emerges calling for just >> excess-traffic-marking then you use either baseline or 3-in-1 >> encoding. >> >> If the WG agree then the next version of this will be standards track, >> and I believe this is probably in a fit state for WGLC... > >I am happy to start a WGLC on this draft, but the WG needs to decide >whether or not to move it to standards track (assuming that is ok with >the ADs). > >Any comments? > > >Regards, > >// Steve > >_______________________________________________ >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