From tm444@hermes.cam.ac.uk Fri Mar 2 01:45:21 2012 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 5966021F8B3C for ; Fri, 2 Mar 2012 01:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtnzVCw8Xfmx for ; Fri, 2 Mar 2012 01:45:20 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 99C5D21F8AB7 for ; Fri, 2 Mar 2012 01:45:20 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:63381) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1S3P38-0007GO-rh (Exim 4.72) for pcn@ietf.org (return-path ); Fri, 02 Mar 2012 09:45:18 +0000 From: Toby Moncaster Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Mar 2012 09:45:17 +0000 Message-Id: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> To: pcn Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Sender: "T. Moncaster" Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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: Fri, 02 Mar 2012 09:45:21 -0000 Adrian Farrel is keen to find out what the WG intentions are regarding = the "other" WG encoding drafts. Just to remind everyone, the original = idea was to have the baseline encoding and a set of 3 experimental = encodings that built on it. Then Bob got RFC6040 published and we = decided to push 3-in-1 encoding as the main standard. This left the = other experimental encodings in limbo. They are: draft-ietf-pcn-psdm-encoding-01 = draft-ietf-pcn-3-state-encoding-01 = These are both cited in the encoding comparison draft which poses some = potential problems. Firstly we are not meant to refer to IDs in RFCs, = secondly these have both long expired so will eventually disappear from = any archives, thirdly I believe Michael may still want to use PSDM = experimentally? There would seem to be 3 possible courses of action: 1) We ask for these to be published as historical RFCs so they can be = referenced from encoding comparison 2) we ask for these to be published as experimental schemes so they can = be referenced and can be used 3) we remove all reference from the encoding comparison OPtion 1 is probably the easiest as (hopefully) they would not need too = much updating. Option 2 requires more work on the drafts (in light of = the fact we are obsolete RFC5696 which they both depend on), but would = at least hold the door open to future work. Option 3 partially defeats = the point of the encoding comparison document.=20 I have a very slight preference for option 1, but what do other people = think?=20 Toby= From menth@informatik.uni-tuebingen.de Fri Mar 2 01:51:04 2012 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 AA7EF21F8B2A for ; Fri, 2 Mar 2012 01:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQIvVUqvg7jl for ; Fri, 2 Mar 2012 01:51:04 -0800 (PST) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id B910821F8B29 for ; Fri, 2 Mar 2012 01:51:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 633E75316 for ; Fri, 2 Mar 2012 10:51:01 +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 7bLlVXEoJGcG for ; Fri, 2 Mar 2012 10:50:58 +0100 (MET) 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 562DF5222 for ; Fri, 2 Mar 2012 10:50:58 +0100 (MET) 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 665BF17F5BC0 for ; Fri, 2 Mar 2012 10:50:57 +0100 (CET) Message-ID: <4F509804.1020307@informatik.uni-tuebingen.de> Date: Fri, 02 Mar 2012 10:51:00 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: pcn@ietf.org References: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> In-Reply-To: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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: Fri, 02 Mar 2012 09:51:04 -0000 Hi Toby, I am also in favor of option 1. Kind regards, Michael Am 02.03.2012 10:45, schrieb Toby Moncaster: > Adrian Farrel is keen to find out what the WG intentions are regarding the "other" WG encoding drafts. Just to remind everyone, the original idea was to have the baseline encoding and a set of 3 experimental encodings that built on it. Then Bob got RFC6040 published and we decided to push 3-in-1 encoding as the main standard. This left the other experimental encodings in limbo. They are: > > draft-ietf-pcn-psdm-encoding-01 > > draft-ietf-pcn-3-state-encoding-01 > > These are both cited in the encoding comparison draft which poses some potential problems. Firstly we are not meant to refer to IDs in RFCs, secondly these have both long expired so will eventually disappear from any archives, thirdly I believe Michael may still want to use PSDM experimentally? > > There would seem to be 3 possible courses of action: > > 1) We ask for these to be published as historical RFCs so they can be referenced from encoding comparison > 2) we ask for these to be published as experimental schemes so they can be referenced and can be used > 3) we remove all reference from the encoding comparison > > OPtion 1 is probably the easiest as (hopefully) they would not need too much updating. Option 2 requires more work on the drafts (in light of the fact we are obsolete RFC5696 which they both depend on), but would at least hold the door open to future work. Option 3 partially defeats the point of the encoding comparison document. > > I have a very slight preference for option 1, but what do other people think? > > Toby > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- 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://kn.inf.uni-tuebingen.de From karagian@cs.utwente.nl Fri Mar 2 02:30:19 2012 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 17B1B21F8B21 for ; Fri, 2 Mar 2012 02:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHk4LB3hqUog for ; Fri, 2 Mar 2012 02:30:18 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7345C21F8B20 for ; Fri, 2 Mar 2012 02:30:14 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 2 Mar 2012 11:30:26 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.150]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 2 Mar 2012 11:30:13 +0100 From: To: , Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: AQHM+FkxhTXOfjwcgkGGPdMD7WPldZZWzcQQ Date: Fri, 2 Mar 2012 10:30:12 +0000 Message-ID: References: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> In-Reply-To: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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: Fri, 02 Mar 2012 10:30:19 -0000 Hi, I agree with Toby that Option 1 is probably the best one to choose! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Toby Moncaster > Sent: vrijdag 2 maart 2012 10:45 > To: pcn > Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison >=20 > Adrian Farrel is keen to find out what the WG intentions are regarding th= e > "other" WG encoding drafts. Just to remind everyone, the original idea wa= s > to have the baseline encoding and a set of 3 experimental encodings that > built on it. Then Bob got RFC6040 published and we decided to push 3-in-1 > encoding as the main standard. This left the other experimental encodings= in > limbo. They are: >=20 > draft-ietf-pcn-psdm-encoding-01 psdm-encoding-01> >=20 > draft-ietf-pcn-3-state-encoding-01 pcn-3-state-encoding-01> >=20 > These are both cited in the encoding comparison draft which poses some > potential problems. Firstly we are not meant to refer to IDs in RFCs, sec= ondly > these have both long expired so will eventually disappear from any archiv= es, > thirdly I believe Michael may still want to use PSDM experimentally? >=20 > There would seem to be 3 possible courses of action: >=20 > 1) We ask for these to be published as historical RFCs so they can be > referenced from encoding comparison > 2) we ask for these to be published as experimental schemes so they can b= e > referenced and can be used > 3) we remove all reference from the encoding comparison >=20 > OPtion 1 is probably the easiest as (hopefully) they would not need too m= uch > updating. Option 2 requires more work on the drafts (in light of the fact= we > are obsolete RFC5696 which they both depend on), but would at least hold > the door open to future work. Option 3 partially defeats the point of the > encoding comparison document. >=20 > I have a very slight preference for option 1, but what do other people th= ink? >=20 > Toby > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Fri Mar 2 03:05:57 2012 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 E5B8621F8B2A for ; Fri, 2 Mar 2012 03:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0djnAK8cIpbM for ; Fri, 2 Mar 2012 03:05:57 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id AB92B21F8B24 for ; Fri, 2 Mar 2012 03:05:56 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 2 Mar 2012 11:05:53 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.72]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 2 Mar 2012 11:05:53 +0000 From: To: , , Date: Fri, 2 Mar 2012 11:05:53 +0000 Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: AQHM+FkxhTXOfjwcgkGGPdMD7WPldZZWzcQQgAAI4bA= Message-ID: <9510D26531EF184D9017DF24659BB87F331C4B6FD6@EMV65-UKRD.domain1.systemhost.net> References: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> In-Reply-To: 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] IESG feedback from 3-in-1 encoding/ encoding comparison 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: Fri, 02 Mar 2012 11:05:58 -0000 Just a correction, lots of RFCs refer to internet drafts. I don't think Adrian's comment was one about the mechanics of references, b= ut what the status is of these other encodings. So the solution is simple, the comparison doc spells out (more) clearly tha= t they were ones we thought about, recorded here for posterity, but are now= no longer being pursued - in favour of 3-in-1 << It appears that there are a number of alternative encoding being=20 proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding,=20 draft-ietf-pcn-psdm-encoding, etc., and as discussed in=20 draft-ietf-pcn-encoding-comparison. It isn't clear to me whether these encodings are being proposed to co-exist, to be used by different=20 operators depending on specific environments, or whether they are being floated to see which one gets more market-place support.>> -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of karag= ian@cs.utwente.nl Sent: 02 March 2012 10:30 To: toby.moncaster@cl.cam.ac.uk; pcn@ietf.org Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Hi, I agree with Toby that Option 1 is probably the best one to choose! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Toby Moncaster > Sent: vrijdag 2 maart 2012 10:45 > To: pcn > Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison >=20 > Adrian Farrel is keen to find out what the WG intentions are regarding th= e > "other" WG encoding drafts. Just to remind everyone, the original idea wa= s > to have the baseline encoding and a set of 3 experimental encodings that > built on it. Then Bob got RFC6040 published and we decided to push 3-in-1 > encoding as the main standard. This left the other experimental encodings= in > limbo. They are: >=20 > draft-ietf-pcn-psdm-encoding-01 psdm-encoding-01> >=20 > draft-ietf-pcn-3-state-encoding-01 pcn-3-state-encoding-01> >=20 > These are both cited in the encoding comparison draft which poses some > potential problems. Firstly we are not meant to refer to IDs in RFCs, sec= ondly > these have both long expired so will eventually disappear from any archiv= es, > thirdly I believe Michael may still want to use PSDM experimentally? >=20 > There would seem to be 3 possible courses of action: >=20 > 1) We ask for these to be published as historical RFCs so they can be > referenced from encoding comparison > 2) we ask for these to be published as experimental schemes so they can b= e > referenced and can be used > 3) we remove all reference from the encoding comparison >=20 > OPtion 1 is probably the easiest as (hopefully) they would not need too m= uch > updating. Option 2 requires more work on the drafts (in light of the fact= we > are obsolete RFC5696 which they both depend on), but would at least hold > the door open to future work. Option 3 partially defeats the point of the > encoding comparison document. >=20 > I have a very slight preference for option 1, but what do other people th= ink? >=20 > Toby > _______________________________________________ > 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 bob.briscoe@bt.com Fri Mar 2 11:51:57 2012 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 C99FF21E8067 for ; Fri, 2 Mar 2012 11:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmy8SoqmAKNa for ; Fri, 2 Mar 2012 11:51:57 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED221E803D for ; Fri, 2 Mar 2012 11:51:56 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 2 Mar 2012 19:51:55 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 2 Mar 2012 19:51:54 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.1.323.0; Fri, 2 Mar 2012 19:51:52 +0000 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 1330717912940; Fri, 2 Mar 2012 19:51:52 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q22JpoKL022102; Fri, 2 Mar 2012 19:51:50 GMT Message-ID: <201203021951.q22JpoKL022102@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 2 Mar 2012 19:51:49 +0000 To: From: Bob Briscoe In-Reply-To: References: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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: Fri, 02 Mar 2012 19:51:57 -0000 +1 At 10:30 02/03/2012, karagian@cs.utwente.nl wrote: >Hi, > >I agree with Toby that Option 1 is probably the best one to choose! > >Best regards, >Georgios > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Toby Moncaster > > Sent: vrijdag 2 maart 2012 10:45 > > To: pcn > > Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison > > > > Adrian Farrel is keen to find out what the WG intentions are regarding the > > "other" WG encoding drafts. Just to remind everyone, the original idea was > > to have the baseline encoding and a set of 3 experimental encodings that > > built on it. Then Bob got RFC6040 published and we decided to push 3-in-1 > > encoding as the main standard. This left the other experimental > encodings in > > limbo. They are: > > > > draft-ietf-pcn-psdm-encoding-01 > psdm-encoding-01> > > > > draft-ietf-pcn-3-state-encoding-01 > pcn-3-state-encoding-01> > > > > These are both cited in the encoding comparison draft which poses some > > potential problems. Firstly we are not meant to refer to IDs in > RFCs, secondly > > these have both long expired so will eventually disappear from > any archives, > > thirdly I believe Michael may still want to use PSDM experimentally? > > > > There would seem to be 3 possible courses of action: > > > > 1) We ask for these to be published as historical RFCs so they can be > > referenced from encoding comparison > > 2) we ask for these to be published as experimental schemes so they can be > > referenced and can be used > > 3) we remove all reference from the encoding comparison > > > > OPtion 1 is probably the easiest as (hopefully) they would not > need too much > > updating. Option 2 requires more work on the drafts (in light of > the fact we > > are obsolete RFC5696 which they both depend on), but would at least hold > > the door open to future work. Option 3 partially defeats the point of the > > encoding comparison document. > > > > I have a very slight preference for option 1, but what do other > people think? > > > > Toby > > _______________________________________________ > > 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 ________________________________________________________________ Bob Briscoe, BT Innovate & Design From slblake@petri-meat.com Fri Mar 2 12:27:32 2012 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 3DEF021F861F for ; Fri, 2 Mar 2012 12:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4WDp6mg-Try for ; Fri, 2 Mar 2012 12:27:31 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5A21F861D for ; Fri, 2 Mar 2012 12:27:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=Upx/9ra2fUgEQacLzddvQHzF7Yx6kdo1vN1UgCUUMFkCYITsx88p4ZHhAIxw4nklftAwN5x2T+pi94OPlBappLkPqZkO4M1ZXWaoVUwcn43AoCiPrBXZ3+h4DnhRUGcd; Received: from cpe-071-065-237-221.nc.res.rr.com ([71.65.237.221]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S3Z4X-0000uB-Td; Fri, 02 Mar 2012 15:27:26 -0500 From: Steven Blake To: philip.eardley@bt.com Date: Fri, 02 Mar 2012 15:27:29 -0500 In-Reply-To: <9510D26531EF184D9017DF24659BB87F331C4B6FD6@EMV65-UKRD.domain1.systemhost.net> References: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> <9510D26531EF184D9017DF24659BB87F331C4B6FD6@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1330720050.2600.20.camel@tachyon> Mime-Version: 1.0 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] IESG feedback from 3-in-1 encoding/ encoding comparison 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: Fri, 02 Mar 2012 20:27:32 -0000 On Fri, 2012-03-02 at 11:05 +0000, philip.eardley@bt.com wrote: > Just a correction, lots of RFCs refer to internet drafts. > > I don't think Adrian's comment was one about the mechanics of > references, but what the status is of these other encodings. > So the solution is simple, the comparison doc spells out (more) > clearly that they were ones we thought about, recorded here for > posterity, but are now no longer being pursued - in favour of 3-in-1 > > << It appears that there are a number of alternative encoding being > proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, > draft-ietf-pcn-psdm-encoding, etc., and as discussed in > draft-ietf-pcn-encoding-comparison. It isn't clear to me whether these > encodings are being proposed to co-exist, to be used by different > operators depending on specific environments, or whether they are > being floated to see which one gets more market-place support.>> +1 I think publishing the abandoned encoding drafts as RFCs would just confuse a situation that is going to be confusing enough with RFC5696 and 3-in-1 both extant. Plus, it's extra load on the IESG and the gen-art folks. Regards, // Steve From sob@sobco.com Sat Mar 3 15:16:56 2012 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 9BA4421F861F for ; Sat, 3 Mar 2012 15:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hssYW-ml1tlQ for ; Sat, 3 Mar 2012 15:16:56 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8121F861C for ; Sat, 3 Mar 2012 15:16:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 9F7D22707A7F; Sat, 3 Mar 2012 18:16:54 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3utnHu-crYrX; Sat, 3 Mar 2012 18:16:52 -0500 (EST) Received: from [10.0.1.3] (unknown [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id 2A4A52707A70; Sat, 3 Mar 2012 18:16:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Scott O. Bradner" In-Reply-To: <201203021951.q22JpoKL022102@bagheera.jungle.bt.co.uk> Date: Sat, 3 Mar 2012 18:16:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6F96443C-6A8C-469E-B250-BA93B953EEB9@sobco.com> References: <9C874ADA-1419-4AF4-B075-47FEDA98E999@cl.cam.ac.uk> <201203021951.q22JpoKL022102@bagheera.jungle.bt.co.uk> To: Bob Briscoe X-Mailer: Apple Mail (2.1257) Cc: pcn@ietf.org, toby.moncaster@cl.cam.ac.uk Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 03 Mar 2012 23:16:56 -0000 +1 - having the formal historical record seems like a good idea Scott On Mar 2, 2012, at 2:51 PM, Bob Briscoe wrote: > +1 >=20 > At 10:30 02/03/2012, karagian@cs.utwente.nl wrote: >> Hi, >>=20 >> I agree with Toby that Option 1 is probably the best one to choose! >>=20 >> Best regards, >> Georgios >>=20 >> > -----Original Message----- >> > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of >> > Toby Moncaster >> > Sent: vrijdag 2 maart 2012 10:45 >> > To: pcn >> > Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding = comparison >> > >> > Adrian Farrel is keen to find out what the WG intentions are = regarding the >> > "other" WG encoding drafts. Just to remind everyone, the original = idea was >> > to have the baseline encoding and a set of 3 experimental encodings = that >> > built on it. Then Bob got RFC6040 published and we decided to push = 3-in-1 >> > encoding as the main standard. This left the other experimental = encodings in >> > limbo. They are: >> > >> > draft-ietf-pcn-psdm-encoding-01 = psdm-encoding-01> >> > >> > draft-ietf-pcn-3-state-encoding-01 = pcn-3-state-encoding-01> >> > >> > These are both cited in the encoding comparison draft which poses = some >> > potential problems. Firstly we are not meant to refer to IDs in = RFCs, secondly >> > these have both long expired so will eventually disappear from any = archives, >> > thirdly I believe Michael may still want to use PSDM = experimentally? >> > >> > There would seem to be 3 possible courses of action: >> > >> > 1) We ask for these to be published as historical RFCs so they can = be >> > referenced from encoding comparison >> > 2) we ask for these to be published as experimental schemes so they = can be >> > referenced and can be used >> > 3) we remove all reference from the encoding comparison >> > >> > OPtion 1 is probably the easiest as (hopefully) they would not need = too much >> > updating. Option 2 requires more work on the drafts (in light of = the fact we >> > are obsolete RFC5696 which they both depend on), but would at least = hold >> > the door open to future work. Option 3 partially defeats the point = of the >> > encoding comparison document. >> > >> > I have a very slight preference for option 1, but what do other = people think? >> > >> > Toby >> > _______________________________________________ >> > 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 >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Mon Mar 5 02:46:29 2012 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 5C82021F8710 for ; Mon, 5 Mar 2012 02:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQZiWIakDyaa for ; Mon, 5 Mar 2012 02:46:28 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57E21F8573 for ; Mon, 5 Mar 2012 02:46:28 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 5 Mar 2012 11:46:28 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.191]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Mon, 5 Mar 2012 11:46:24 +0100 From: To: , , Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: Acz6vTUiKhNr0JLnQgC8zFfWWnh+xw== Date: Mon, 5 Mar 2012 10:46:23 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 05 Mar 2012 10:46:29 -0000 Hi Phil, Do you mean that you are rather against publishing the other encodings draf= ts as historical RFCs. In a previous email I have mentioned that Option 1 (publish encodings draft= s as historical RFCs) proposed by Toby is probably the best choice. However, I will not strongly insist on this option. I am also fine if we wi= ll not publish these encodings drafts as historical RFCs. The encoding comp= arison draft provides then the historical record of what these other encodi= ngs are (with the reference to the current I-Ds) like and the reasons pro/a= nti them. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: vrijdag 2 maart 2012 12:06 > To: Karagiannis, G. (Georgios); toby.moncaster@cl.cam.ac.uk; pcn@ietf.org > Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding > comparison >=20 > Just a correction, lots of RFCs refer to internet drafts. >=20 > I don't think Adrian's comment was one about the mechanics of references, > but what the status is of these other encodings. > So the solution is simple, the comparison doc spells out (more) clearly t= hat > they were ones we thought about, recorded here for posterity, but are now > no longer being pursued - in favour of 3-in-1 >=20 > << It appears that there are a number of alternative encoding being > proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, draf= t- > ietf-pcn-psdm-encoding, etc., and as discussed in draft-ietf-pcn-encoding= - > comparison. It isn't clear to me whether these encodings are being propos= ed > to co-exist, to be used by different operators depending on specific > environments, or whether they are being floated to see which one gets > more market-place support.>> >=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > karagian@cs.utwente.nl > Sent: 02 March 2012 10:30 > To: toby.moncaster@cl.cam.ac.uk; pcn@ietf.org > Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding > comparison >=20 > Hi, >=20 > I agree with Toby that Option 1 is probably the best one to choose! >=20 > Best regards, > Georgios >=20 > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Toby Moncaster > > Sent: vrijdag 2 maart 2012 10:45 > > To: pcn > > Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison > > > > Adrian Farrel is keen to find out what the WG intentions are regarding > > the "other" WG encoding drafts. Just to remind everyone, the original > > idea was to have the baseline encoding and a set of 3 experimental > > encodings that built on it. Then Bob got RFC6040 published and we > > decided to push 3-in-1 encoding as the main standard. This left the > > other experimental encodings in limbo. They are: > > > > draft-ietf-pcn-psdm-encoding-01 > > > psdm-encoding-01> > > > > draft-ietf-pcn-3-state-encoding-01 > > > pcn-3-state-encoding-01> > > > > These are both cited in the encoding comparison draft which poses some > > potential problems. Firstly we are not meant to refer to IDs in RFCs, > > secondly these have both long expired so will eventually disappear > > from any archives, thirdly I believe Michael may still want to use PSDM > experimentally? > > > > There would seem to be 3 possible courses of action: > > > > 1) We ask for these to be published as historical RFCs so they can be > > referenced from encoding comparison > > 2) we ask for these to be published as experimental schemes so they > > can be referenced and can be used > > 3) we remove all reference from the encoding comparison > > > > OPtion 1 is probably the easiest as (hopefully) they would not need > > too much updating. Option 2 requires more work on the drafts (in light > > of the fact we are obsolete RFC5696 which they both depend on), but > > would at least hold the door open to future work. Option 3 partially > > defeats the point of the encoding comparison document. > > > > I have a very slight preference for option 1, but what do other people > think? > > > > Toby > > _______________________________________________ > > 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 Mar 5 03:22:33 2012 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 0DDE321F8753 for ; Mon, 5 Mar 2012 03:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.111 X-Spam-Level: X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZVuBdD5VRF6 for ; Mon, 5 Mar 2012 03:22:32 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id D43BF21F8751 for ; Mon, 5 Mar 2012 03:22:31 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 5 Mar 2012 11:22:30 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Mon, 5 Mar 2012 11:22:30 +0000 From: To: , , Date: Mon, 5 Mar 2012 11:22:29 +0000 Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: Acz6vTUiKhNr0JLnQgC8zFfWWnh+xwABLrnw Message-ID: <9510D26531EF184D9017DF24659BB87F331CDBF70A@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: 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] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 05 Mar 2012 11:22:33 -0000 Yes - I think the encoding comparison draft provides a good historical reco= rd of the various encodings that we thought of and their pros/cons. Publishing the encodings as historical RFCs doesn't seem to me to add much = value, and creates extra work for WG /iesg /ietf reviewers phil -----Original Message----- From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl]=20 Sent: 05 March 2012 10:46 To: Eardley,PL,Philip,DUB8 R; toby.moncaster@cl.cam.ac.uk; pcn@ietf.org Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison= =20 Hi Phil, Do you mean that you are rather against publishing the other encodings draf= ts as historical RFCs. In a previous email I have mentioned that Option 1 (publish encodings draft= s as historical RFCs) proposed by Toby is probably the best choice. However, I will not strongly insist on this option. I am also fine if we wi= ll not publish these encodings drafts as historical RFCs. The encoding comp= arison draft provides then the historical record of what these other encodi= ngs are (with the reference to the current I-Ds) like and the reasons pro/a= nti them. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: vrijdag 2 maart 2012 12:06 > To: Karagiannis, G. (Georgios); toby.moncaster@cl.cam.ac.uk; pcn@ietf.org > Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding > comparison >=20 > Just a correction, lots of RFCs refer to internet drafts. >=20 > I don't think Adrian's comment was one about the mechanics of references, > but what the status is of these other encodings. > So the solution is simple, the comparison doc spells out (more) clearly t= hat > they were ones we thought about, recorded here for posterity, but are now > no longer being pursued - in favour of 3-in-1 >=20 > << It appears that there are a number of alternative encoding being > proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, draf= t- > ietf-pcn-psdm-encoding, etc., and as discussed in draft-ietf-pcn-encoding= - > comparison. It isn't clear to me whether these encodings are being propos= ed > to co-exist, to be used by different operators depending on specific > environments, or whether they are being floated to see which one gets > more market-place support.>> >=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > karagian@cs.utwente.nl > Sent: 02 March 2012 10:30 > To: toby.moncaster@cl.cam.ac.uk; pcn@ietf.org > Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding > comparison >=20 > Hi, >=20 > I agree with Toby that Option 1 is probably the best one to choose! >=20 > Best regards, > Georgios >=20 > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Toby Moncaster > > Sent: vrijdag 2 maart 2012 10:45 > > To: pcn > > Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison > > > > Adrian Farrel is keen to find out what the WG intentions are regarding > > the "other" WG encoding drafts. Just to remind everyone, the original > > idea was to have the baseline encoding and a set of 3 experimental > > encodings that built on it. Then Bob got RFC6040 published and we > > decided to push 3-in-1 encoding as the main standard. This left the > > other experimental encodings in limbo. They are: > > > > draft-ietf-pcn-psdm-encoding-01 > > > psdm-encoding-01> > > > > draft-ietf-pcn-3-state-encoding-01 > > > pcn-3-state-encoding-01> > > > > These are both cited in the encoding comparison draft which poses some > > potential problems. Firstly we are not meant to refer to IDs in RFCs, > > secondly these have both long expired so will eventually disappear > > from any archives, thirdly I believe Michael may still want to use PSDM > experimentally? > > > > There would seem to be 3 possible courses of action: > > > > 1) We ask for these to be published as historical RFCs so they can be > > referenced from encoding comparison > > 2) we ask for these to be published as experimental schemes so they > > can be referenced and can be used > > 3) we remove all reference from the encoding comparison > > > > OPtion 1 is probably the easiest as (hopefully) they would not need > > too much updating. Option 2 requires more work on the drafts (in light > > of the fact we are obsolete RFC5696 which they both depend on), but > > would at least hold the door open to future work. Option 3 partially > > defeats the point of the encoding comparison document. > > > > I have a very slight preference for option 1, but what do other people > think? > > > > Toby > > _______________________________________________ > > 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 ietfdbh@comcast.net Tue Mar 6 10:23:42 2012 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 E7A3D21F88A1 for ; Tue, 6 Mar 2012 10:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vXlhLzcVlPX for ; Tue, 6 Mar 2012 10:23:42 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id F24C721F8618 for ; Tue, 6 Mar 2012 10:23:41 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id iJMk1i0020vyq2s5AJPi2C; Tue, 06 Mar 2012 18:23:42 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta05.westchester.pa.mail.comcast.net with comcast id iJPh1i0123Ecudz3RJPhjg; Tue, 06 Mar 2012 18:23:42 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 06 Mar 2012 13:23:38 -0500 From: David Harrington To: , , , Message-ID: Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison In-Reply-To: <9510D26531EF184D9017DF24659BB87F331CDBF70A@EMV65-UKRD.domain1.systemhost.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 06 Mar 2012 18:23:43 -0000 Hi, It appears to me the drafts have already expired. You can refer to expired drafts in an Informational document, using an approach similar to this: The XYZ encoding was proposed in a draft document submitted to the PCN WG in . The PCN WG chose to not advance this draft. This way there is no reference to the expired draft, and the intentions to not carry the drafts forward is easy to see. Now, as to whether publishing them as historical is the right way: How much more detail is in the drafts that will be lost if we just let them expire? Is it important to the industry to keep a record of that historical detail, or just a summary of the ideas in those drafts and why they didn't work. I can understand that academically, it might be nice to have these published as historical records, but I tend to agree that having them published as RFCs could confuse people who are not really knowledgeable about IETF practice and the difference in types of RFCs. If the summary seems adequate, then I recommend letting the drafts disappear. You should make sure all your documents do not contain any references to those drafts. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/5/12 6:22 AM, "philip.eardley@bt.com" wrote: >Yes - I think the encoding comparison draft provides a good historical >record of the various encodings that we thought of and their pros/cons. >Publishing the encodings as historical RFCs doesn't seem to me to add >much value, and creates extra work for WG /iesg /ietf reviewers > >phil > >-----Original Message----- >From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >Sent: 05 March 2012 10:46 >To: Eardley,PL,Philip,DUB8 R; toby.moncaster@cl.cam.ac.uk; pcn@ietf.org >Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding >comparison > >Hi Phil, > >Do you mean that you are rather against publishing the other encodings >drafts as historical RFCs. > >In a previous email I have mentioned that Option 1 (publish encodings >drafts as historical RFCs) proposed by Toby is probably the best choice. > >However, I will not strongly insist on this option. I am also fine if we >will not publish these encodings drafts as historical RFCs. The encoding >comparison draft provides then the historical record of what these other >encodings are (with the reference to the current I-Ds) like and the >reasons pro/anti them. > >Best regards, >Georgios > > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: vrijdag 2 maart 2012 12:06 >> To: Karagiannis, G. (Georgios); toby.moncaster@cl.cam.ac.uk; >>pcn@ietf.org >> Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding >> comparison >> >> Just a correction, lots of RFCs refer to internet drafts. >> >> I don't think Adrian's comment was one about the mechanics of >>references, >> but what the status is of these other encodings. >> So the solution is simple, the comparison doc spells out (more) clearly >>that >> they were ones we thought about, recorded here for posterity, but are >>now >> no longer being pursued - in favour of 3-in-1 >> >> << It appears that there are a number of alternative encoding being >> proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, >>draft- >> ietf-pcn-psdm-encoding, etc., and as discussed in >>draft-ietf-pcn-encoding- >> comparison. It isn't clear to me whether these encodings are being >>proposed >> to co-exist, to be used by different operators depending on specific >> environments, or whether they are being floated to see which one gets >> more market-place support.>> >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> karagian@cs.utwente.nl >> Sent: 02 March 2012 10:30 >> To: toby.moncaster@cl.cam.ac.uk; pcn@ietf.org >> Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding >> comparison >> >> Hi, >> >> I agree with Toby that Option 1 is probably the best one to choose! >> >> Best regards, >> Georgios >> >> > -----Original Message----- >> > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> > Toby Moncaster >> > Sent: vrijdag 2 maart 2012 10:45 >> > To: pcn >> > Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison >> > >> > Adrian Farrel is keen to find out what the WG intentions are regarding >> > the "other" WG encoding drafts. Just to remind everyone, the original >> > idea was to have the baseline encoding and a set of 3 experimental >> > encodings that built on it. Then Bob got RFC6040 published and we >> > decided to push 3-in-1 encoding as the main standard. This left the >> > other experimental encodings in limbo. They are: >> > >> > draft-ietf-pcn-psdm-encoding-01 >> > > > psdm-encoding-01> >> > >> > draft-ietf-pcn-3-state-encoding-01 >> > > > pcn-3-state-encoding-01> >> > >> > These are both cited in the encoding comparison draft which poses some >> > potential problems. Firstly we are not meant to refer to IDs in RFCs, >> > secondly these have both long expired so will eventually disappear >> > from any archives, thirdly I believe Michael may still want to use >>PSDM >> experimentally? >> > >> > There would seem to be 3 possible courses of action: >> > >> > 1) We ask for these to be published as historical RFCs so they can be >> > referenced from encoding comparison >> > 2) we ask for these to be published as experimental schemes so they >> > can be referenced and can be used >> > 3) we remove all reference from the encoding comparison >> > >> > OPtion 1 is probably the easiest as (hopefully) they would not need >> > too much updating. Option 2 requires more work on the drafts (in light >> > of the fact we are obsolete RFC5696 which they both depend on), but >> > would at least hold the door open to future work. Option 3 partially >> > defeats the point of the encoding comparison document. >> > >> > I have a very slight preference for option 1, but what do other people >> think? >> > >> > Toby >> > _______________________________________________ >> > 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 >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From ietfdbh@comcast.net Tue Mar 6 11:57:28 2012 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 2DEE221F8778 for ; Tue, 6 Mar 2012 11:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.554 X-Spam-Level: X-Spam-Status: No, score=-101.554 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuyAHQwGm5U8 for ; Tue, 6 Mar 2012 11:57:27 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8A31621F8764 for ; Tue, 6 Mar 2012 11:57:27 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id iKeU1i0020EZKEL5BKxTn3; Tue, 06 Mar 2012 19:57:27 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta01.westchester.pa.mail.comcast.net with comcast id iKxS1i00Q3Ecudz3MKxTce; Tue, 06 Mar 2012 19:57:27 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Tue, 06 Mar 2012 14:57:24 -0500 From: David Harrington To: "pcn@ietf.org" Message-ID: Thread-Topic: status of cl and sm edge docs? Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413890646_35600813" Subject: [PCN] status of cl and sm edge docs? 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, 06 Mar 2012 19:57:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3413890646_35600813 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi, I notice the status in the document has been changed from Informational to Experimental, but in the datatracker it is still Informational. Can somebody point me to the discussion thread for this change to Experimental? -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 --B_3413890646_35600813 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi,

=
I notice the status in the document has been changed from Informa= tional to Experimental, but in the datatracker it is still Informational.
Can somebody point me to the discussion thread for this change to Ex= perimental?


--
David Harrington
<= div>Director, Transport Area
Internet Eng= ineering Task Force (IETF)
Ietfdbh@comcast.= net
+1-603-828-1401

--B_3413890646_35600813-- From tom.taylor.stds@gmail.com Tue Mar 6 13:41:32 2012 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 202C521E80BF for ; Tue, 6 Mar 2012 13:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gkEh3b8n0fW for ; Tue, 6 Mar 2012 13:41:31 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A87721E8025 for ; Tue, 6 Mar 2012 13:41:31 -0800 (PST) Received: by yenm5 with SMTP id m5so2862286yen.31 for ; Tue, 06 Mar 2012 13:41:31 -0800 (PST) Received-SPF: pass (google.com: domain of tom.taylor.stds@gmail.com designates 10.236.170.134 as permitted sender) client-ip=10.236.170.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tom.taylor.stds@gmail.com designates 10.236.170.134 as permitted sender) smtp.mail=tom.taylor.stds@gmail.com; dkim=pass header.i=tom.taylor.stds@gmail.com Received: from mr.google.com ([10.236.170.134]) by 10.236.170.134 with SMTP id p6mr37374255yhl.81.1331070091123 (num_hops = 1); Tue, 06 Mar 2012 13:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=GWUt5V0GakrjlhOp3cnlo/2HgYVc4RVL5sNVIanXMuM=; b=hXN8R3XycogCGTtWCB1BdLXSn9ZZ/DR6h9q6svW0qmf6U00vJ4mZBD96DDSwBCR0iD pogkBVIOkKODNgCoRLNU3561qhAe8MMDnpD4jpGunC31aGsTNaH97d4qcHCPxBHRyUqt ynCk+j8Dw09EScXs9kIKQlcOh20wWC1rPTHT1fyUOYkDl2YKWmq+anif9H7w9B6lN81I J2LeVF6puAaXtBjnqOAv4FgbbmLv0H+pJ4b4GYnVGJL13SAOQ8EIvRco+8BtRRaRn4VT ac2LrKf2qmDn23DOVpWg59pBMpmSJkOwU+RrOfLDaLRUXHnOPyOmyiju7N/r+Crna8Ay Pt+g== Received: by 10.236.170.134 with SMTP id p6mr29614654yhl.81.1331070090980; Tue, 06 Mar 2012 13:41:30 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-17-221.tor.primus.ca. [173.206.17.221]) by mx.google.com with ESMTPS id v21sm52361028yhk.3.2012.03.06.13.41.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Mar 2012 13:41:29 -0800 (PST) Message-ID: <4F56848A.7040909@gmail.com> Date: Tue, 06 Mar 2012 16:41:30 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120306-0, 06/03/2012), Outbound message X-Antivirus-Status: Clean Cc: "pcn@ietf.org" Subject: Re: [PCN] status of cl and sm edge docs? 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, 06 Mar 2012 21:41:32 -0000 It was Joel Halpern's comment, but I see rev iewing my response that this didn't go to the list. Can I confirm that Experimental is agreeable to the WG? On 06/03/2012 2:57 PM, David Harrington wrote: > Hi, > > I notice the status in the document has been changed from Informational to > Experimental, but in the datatracker it is still Informational. > Can somebody point me to the discussion thread for this change to > Experimental? > > > -- > David Harrington > Director, Transport Area > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Tue Mar 6 13:44:42 2012 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 C172021E80D9 for ; Tue, 6 Mar 2012 13:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.174 X-Spam-Level: X-Spam-Status: No, score=-0.174 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H14EK0+OQ6WO for ; Tue, 6 Mar 2012 13:44:42 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B61E21E80D5 for ; Tue, 6 Mar 2012 13:44:41 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 6 Mar 2012 22:44:47 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.191]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Tue, 6 Mar 2012 22:44:40 +0100 From: To: , Thread-Topic: [PCN] status of cl and sm edge docs? Thread-Index: AQHM+9NeLpYQElgYyk2/kni7qyDgUJZdu10AgAARaj8= Date: Tue, 6 Mar 2012 21:44:39 +0000 Message-ID: References: ,<4F56848A.7040909@gmail.com> In-Reply-To: <4F56848A.7040909@gmail.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] status of cl and sm edge docs? 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, 06 Mar 2012 21:44:42 -0000 Hi Tom, It is agreeable to me! Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Tom Taylor [tom.tay= lor.stds@gmail.com] Verzonden: dinsdag 6 maart 2012 22:41 Aan: David Harrington CC: pcn@ietf.org Onderwerp: Re: [PCN] status of cl and sm edge docs? It was Joel Halpern's comment, but I see rev iewing my response that this didn't go to the list. Can I confirm that Experimental is agreeable to the WG? On 06/03/2012 2:57 PM, David Harrington wrote: > Hi, > > I notice the status in the document has been changed from Informational t= o > Experimental, but in the datatracker it is still Informational. > Can somebody point me to the discussion thread for this change to > Experimental? > > > -- > David Harrington > Director, Transport Area > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > > > _______________________________________________ > 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 sob@sobco.com Tue Mar 6 19:59:13 2012 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 9965221E8019 for ; Tue, 6 Mar 2012 19:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPspPTp-Ndy0 for ; Tue, 6 Mar 2012 19:59:13 -0800 (PST) Received: from sobco.sobco.com (unknown [136.248.127.164]) by ietfa.amsl.com (Postfix) with ESMTP id 2516421E8013 for ; Tue, 6 Mar 2012 19:59:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 265BD274D63D; Tue, 6 Mar 2012 22:59:12 -0500 (EST) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjz5oEytnXrI; Tue, 6 Mar 2012 22:59:08 -0500 (EST) Received: from [136.248.127.172] (unknown [136.248.127.172]) by sobco.sobco.com (Postfix) with ESMTPSA id B3DA8274D629; Tue, 6 Mar 2012 22:59:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Scott O Bradner In-Reply-To: <4F56848A.7040909@gmail.com> Date: Tue, 6 Mar 2012 22:59:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A68E976-B41F-4CE3-9A43-EDBF42A56AC5@sobco.com> References: <4F56848A.7040909@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1257) Cc: "pcn@ietf.org" Subject: Re: [PCN] status of cl and sm edge docs? 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, 07 Mar 2012 03:59:13 -0000 wfm On Mar 6, 2012, at 4:41 PM, Tom Taylor wrote: > It was Joel Halpern's comment, but I see rev iewing my response that = this didn't go to the list. Can I confirm that Experimental is agreeable = to the WG? >=20 > On 06/03/2012 2:57 PM, David Harrington wrote: >> Hi, >>=20 >> I notice the status in the document has been changed from = Informational to >> Experimental, but in the datatracker it is still Informational. >> Can somebody point me to the discussion thread for this change to >> Experimental? >>=20 >>=20 >> -- >> David Harrington >> Director, Transport Area >> Internet Engineering Task Force (IETF) >> Ietfdbh@comcast.net >> +1-603-828-1401 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=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 Ruediger.Geib@telekom.de Tue Mar 6 23:31:42 2012 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 9812D21E806E for ; Tue, 6 Mar 2012 23:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yjTHx+1HLpu for ; Tue, 6 Mar 2012 23:31:42 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7621E804E for ; Tue, 6 Mar 2012 23:31:41 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 07 Mar 2012 08:31:39 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.9]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 7 Mar 2012 08:31:39 +0100 From: To: Date: Wed, 7 Mar 2012 08:31:38 +0100 Thread-Topic: [PCN] status of cl and sm edge docs? Thread-Index: Acz74ehPnaaH1gINS2it8Nj6IL2JWgAUlPpQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A03D609A@HE111648.emea1.cds.t-internal.com> References: <4F56848A.7040909@gmail.com> In-Reply-To: <4F56848A.7040909@gmail.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] status of cl and sm edge docs? 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, 07 Mar 2012 07:31:42 -0000 Hi Tom, agreeable with me too. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: Tuesday, March 06, 2012 10:42 PM To: David Harrington Cc: pcn@ietf.org Subject: Re: [PCN] status of cl and sm edge docs? It was Joel Halpern's comment, but I see rev iewing my response that this didn't go to the list. Can I confirm that Experimental is agreeable to the WG? On 06/03/2012 2:57 PM, David Harrington wrote: > Hi, > > I notice the status in the document has been changed from Informational t= o > Experimental, but in the datatracker it is still Informational. > Can somebody point me to the discussion thread for this change to > Experimental? > > > -- > David Harrington > Director, Transport Area > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > > > _______________________________________________ > 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 slblake@petri-meat.com Wed Mar 7 21:01:17 2012 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 AF1A021F85A5 for ; Wed, 7 Mar 2012 21:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.136 X-Spam-Level: X-Spam-Status: No, score=-101.136 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5mJnncwQ58d for ; Wed, 7 Mar 2012 21:01:17 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id BD11921F85A3 for ; Wed, 7 Mar 2012 21:01:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=BG5zjk8C/cqivNtmkKXUreg5akvE9VUGfRw5bvZAwlm6cA3oyXU0J12vvgleWHJpS/mShFSYqxgIlCNKdD8kywrxXGv1QSlA2iiq+2FfFW7aAEuabXHNsfHhEXJiFJmC; Received: from cpe-071-065-228-004.nc.res.rr.com ([71.65.228.4]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S5VTU-0002YZ-Sg; Thu, 08 Mar 2012 00:01:12 -0500 From: Steven Blake To: David Harrington Date: Thu, 08 Mar 2012 00:01:13 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1331182874.6028.14.camel@tachyon> Mime-Version: 1.0 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] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 08 Mar 2012 05:01:17 -0000 On Tue, 2012-03-06 at 13:23 -0500, David Harrington wrote: > Hi, > > It appears to me the drafts have already expired. > You can refer to expired drafts in an Informational document, using an > approach similar to this: > > The XYZ encoding was proposed in a draft document submitted to the PCN > WG in 2006>. The PCN WG chose to not advance this draft. > > > This way there is no reference to the expired draft, and the intentions to > not carry the drafts forward is easy to see. > > Now, as to whether publishing them as historical is the right way: > How much more detail is in the drafts that will be lost if we just let > them expire? > Is it important to the industry to keep a record of that historical > detail, or just a summary of the ideas in those drafts and why they didn't > work. > I can understand that academically, it might be nice to have these > published as historical records, but I tend to agree that having them > published as RFCs could confuse people who are not really knowledgeable > about IETF practice and the difference in types of RFCs. > If the summary seems adequate, then I recommend letting the drafts > disappear. > You should make sure all your documents do not contain any references to > those drafts. I think this last bit of advice applies even if the WG chooses to publish the expired drafts. Now, are there any volunteers to revise these drafts and get them in shape for WG last call? Regards, // Steve From sob@harvard.edu Thu Mar 8 09:15:06 2012 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 E43E321F84EF for ; Thu, 8 Mar 2012 09:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.786 X-Spam-Level: X-Spam-Status: No, score=-102.786 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X01xIydYh7L for ; Thu, 8 Mar 2012 09:15:05 -0800 (PST) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id B506521F8496 for ; Thu, 8 Mar 2012 09:15:05 -0800 (PST) Received: from exchange.university.harvard.edu (unknown [10.35.2.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 51014E963A; Thu, 8 Mar 2012 12:14:58 -0500 (EST) Received: from ENTWHUBT0000002.university.harvard.edu (192.168.36.23) by ENTWEDGE0000001.university.harvard.edu (10.35.2.152) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 8 Mar 2012 12:14:25 -0500 Received: from ENTWEXMB0000004.university.harvard.edu ([169.254.3.253]) by entwhubt0000002.university.harvard.edu ([192.168.36.46]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 12:14:43 -0500 From: "Bradner, Scott" To: David Harrington Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: AQHM/U7za6FGpsd4iEqlGqMAUTJcnQ== Date: Thu, 8 Mar 2012 17:14:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.248.127.162] Content-Type: text/plain; charset="us-ascii" Content-ID: <4401E9069084054C8F4DFA41EA1F8C7D@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 08 Mar 2012 17:15:07 -0000 Dave -=20 just to be sure - you are not suggesting to not have a reference to an expi= red ID (by document name, not by filename) are you? Scott On Mar 6, 2012, at 1:23 PM, David Harrington wrote: > Hi, >=20 > It appears to me the drafts have already expired. > You can refer to expired drafts in an Informational document, using an > approach similar to this: >=20 > The XYZ encoding was proposed in a draft document submitted to the PCN > WG in 2006>. The PCN WG chose to not advance this draft. >=20 >=20 > This way there is no reference to the expired draft, and the intentions t= o > not carry the drafts forward is easy to see. >=20 > Now, as to whether publishing them as historical is the right way: > How much more detail is in the drafts that will be lost if we just let > them expire? > Is it important to the industry to keep a record of that historical > detail, or just a summary of the ideas in those drafts and why they didn'= t > work. > I can understand that academically, it might be nice to have these > published as historical records, but I tend to agree that having them > published as RFCs could confuse people who are not really knowledgeable > about IETF practice and the difference in types of RFCs. > If the summary seems adequate, then I recommend letting the drafts > disappear. > You should make sure all your documents do not contain any references to > those drafts. >=20 > -- > David Harrington > Director, Transport Area > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 >=20 > On 3/5/12 6:22 AM, "philip.eardley@bt.com" wrote: >=20 >> Yes - I think the encoding comparison draft provides a good historical >> record of the various encodings that we thought of and their pros/cons. >> Publishing the encodings as historical RFCs doesn't seem to me to add >> much value, and creates extra work for WG /iesg /ietf reviewers >>=20 >> phil >>=20 >> -----Original Message----- >> From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >> Sent: 05 March 2012 10:46 >> To: Eardley,PL,Philip,DUB8 R; toby.moncaster@cl.cam.ac.uk; pcn@ietf.org >> Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding >> comparison=20 >>=20 >> Hi Phil, >>=20 >> Do you mean that you are rather against publishing the other encodings >> drafts as historical RFCs. >>=20 >> In a previous email I have mentioned that Option 1 (publish encodings >> drafts as historical RFCs) proposed by Toby is probably the best choice. >>=20 >> However, I will not strongly insist on this option. I am also fine if we >> will not publish these encodings drafts as historical RFCs. The encoding >> comparison draft provides then the historical record of what these other >> encodings are (with the reference to the current I-Ds) like and the >> reasons pro/anti them. >>=20 >> Best regards, >> Georgios >>=20 >>=20 >>> -----Original Message----- >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: vrijdag 2 maart 2012 12:06 >>> To: Karagiannis, G. (Georgios); toby.moncaster@cl.cam.ac.uk; >>> pcn@ietf.org >>> Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding >>> comparison >>>=20 >>> Just a correction, lots of RFCs refer to internet drafts. >>>=20 >>> I don't think Adrian's comment was one about the mechanics of >>> references, >>> but what the status is of these other encodings. >>> So the solution is simple, the comparison doc spells out (more) clearly >>> that >>> they were ones we thought about, recorded here for posterity, but are >>> now >>> no longer being pursued - in favour of 3-in-1 >>>=20 >>> << It appears that there are a number of alternative encoding being >>> proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, >>> draft- >>> ietf-pcn-psdm-encoding, etc., and as discussed in >>> draft-ietf-pcn-encoding- >>> comparison. It isn't clear to me whether these encodings are being >>> proposed >>> to co-exist, to be used by different operators depending on specific >>> environments, or whether they are being floated to see which one gets >>> more market-place support.>> >>>=20 >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>> karagian@cs.utwente.nl >>> Sent: 02 March 2012 10:30 >>> To: toby.moncaster@cl.cam.ac.uk; pcn@ietf.org >>> Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding >>> comparison >>>=20 >>> Hi, >>>=20 >>> I agree with Toby that Option 1 is probably the best one to choose! >>>=20 >>> Best regards, >>> Georgios >>>=20 >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>>> Toby Moncaster >>>> Sent: vrijdag 2 maart 2012 10:45 >>>> To: pcn >>>> Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison >>>>=20 >>>> Adrian Farrel is keen to find out what the WG intentions are regarding >>>> the "other" WG encoding drafts. Just to remind everyone, the original >>>> idea was to have the baseline encoding and a set of 3 experimental >>>> encodings that built on it. Then Bob got RFC6040 published and we >>>> decided to push 3-in-1 encoding as the main standard. This left the >>>> other experimental encodings in limbo. They are: >>>>=20 >>>> draft-ietf-pcn-psdm-encoding-01 >>>> >>> psdm-encoding-01> >>>>=20 >>>> draft-ietf-pcn-3-state-encoding-01 >>>> >>> pcn-3-state-encoding-01> >>>>=20 >>>> These are both cited in the encoding comparison draft which poses some >>>> potential problems. Firstly we are not meant to refer to IDs in RFCs, >>>> secondly these have both long expired so will eventually disappear >>>> from any archives, thirdly I believe Michael may still want to use >>> PSDM >>> experimentally? >>>>=20 >>>> There would seem to be 3 possible courses of action: >>>>=20 >>>> 1) We ask for these to be published as historical RFCs so they can be >>>> referenced from encoding comparison >>>> 2) we ask for these to be published as experimental schemes so they >>>> can be referenced and can be used >>>> 3) we remove all reference from the encoding comparison >>>>=20 >>>> OPtion 1 is probably the easiest as (hopefully) they would not need >>>> too much updating. Option 2 requires more work on the drafts (in light >>>> of the fact we are obsolete RFC5696 which they both depend on), but >>>> would at least hold the door open to future work. Option 3 partially >>>> defeats the point of the encoding comparison document. >>>>=20 >>>> I have a very slight preference for option 1, but what do other people >>> think? >>>>=20 >>>> Toby >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From internet-drafts@ietf.org Thu Mar 8 13:00:03 2012 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 8AE7B21E803E; Thu, 8 Mar 2012 13:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCZhKOXWj2qf; Thu, 8 Mar 2012 13:00:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9516321E8036; Thu, 8 Mar 2012 13:00:02 -0800 (PST) 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: 4.00 Message-ID: <20120308210002.4581.81941.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 13:00:02 -0800 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-09.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, 08 Mar 2012 21:00:03 -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 : Overview of Pre-Congestion Notification Encoding Author(s) : Georgios Karagiannis Kwok Ho Chan Toby Moncaster Michael Menth Philip Eardley Bob Briscoe Filename : draft-ietf-pcn-encoding-comparison-09.txt Pages : 19 Date : 2012-03-08 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. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-09.t= xt 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-encoding-comparison-09.txt From karagian@cs.utwente.nl Thu Mar 8 13:17:07 2012 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 8192C21E8048; Thu, 8 Mar 2012 13:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R68OVjBJl1MJ; Thu, 8 Mar 2012 13:17:06 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id AEC5921E8039; Thu, 8 Mar 2012 13:17:02 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 8 Mar 2012 22:17:04 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.191]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Thu, 8 Mar 2012 22:17:01 +0100 From: To: , , , Thread-Topic: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-09.txt Thread-Index: AQHM/W5+cJcgSEK1DEeMRMOfbzQGEJZg5aSx Date: Thu, 8 Mar 2012 21:17:00 +0000 Message-ID: References: <20120308210002.4581.81941.idtracker@ietfa.amsl.com> In-Reply-To: <20120308210002.4581.81941.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, pcn-chairs@tools.ietf.org, draft-ietf-pcn-encoding-comparison@tools.ietf.org Subject: Re: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-09.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, 08 Mar 2012 21:17:07 -0000 Hi Adrian, Hi Russ, Hi Pete, Hi all, We have submitted a new version of draft-ietf-pcn-encoding-comparison. Please note that we have worked out all the DISCUSSES and comments in the f= ollowing way:=20 =20 DISCUSS and Comment from Adrian Farrel: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 At 15:19 29/02/2012, Adrian Farrel wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Section 3.2.3 >=20 > I cannot reconcile the text in option (1) that says: >=20 > with the conclusion of the section that says: >=20 > Option (1) seems to be the most viable and efficient solution. >=20 > If it is the intention of the PCN working group to be "PCN for IP-only > networks" then I do think this could be s[elled out. OTOH, if MPLS is > in scope, then surely option (1) is impractical. >=20 =20 Georgios: For clarity reasons, I am copying the text related to Option 1 a= nd Option 3, described in Section 3.2.3. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Each Diffserv class using PCN uses a different set of DSCPs. Therefore, if there are M DSCPs using PCN and PCN encoding uses N=20 different DSCPs, N*M DSCPs are needed. This solution may work well in IP networks. However, when PCN is applied to MPLS networks or=20 other layers restricted to 8 QoS classes and codepoints, this=20 solution fails due to the extreme shortage of available DSCPs. =20 3. PCN-traffic is tunneled across the PCN-domain. The pipe tunneling=20 model is applied and so the original DSCP is restored after decapsulation. However, tunneling across a PCN domain adds an=20 additional IP header and reduces the maximum transfer unit (MTU)=20 from the perspective of the user. GRE, MPLS, or Ethernet using=20 Pseudo-Wires are potential solutions that scale well also in backbone networks. Option (1) seems to be the most viable and efficient solution.=20 Regarding your observation that if MPLS is in scope, then surely option (1)= is impractical, you are right.=20 I think that we should emphasize that both Option (1) and Option (3) are vi= able, but both of them have drawbacks.=20 So we would like to change the conclusion from: =20 Change from: "Option (1) seems to be the most viable and efficient solution. " =20 INTO: The most appropriate option depends on the specific circumstances an operat= or faces.=20 * Option 1 is most suitable unless there is a shortage of available DSCPs. * Option 3 is suitable where the reduction of MTU is not liable to cause is= sues. > Note that draft-ietf-pcn-3-in-1-encoding makes a specific statement > about applicability only to IP. Georgios: In our opinion, see also reply of Bob Briscoe to this DISCUSS, th= is is a simple misreading of the text at the end of the Intro to draft-pcn= -3-in-1-encoding (below).=20 This merely says the normative parts of the 3-in-1 doc only concern encodin= g PCN in v4 &=20 v6. It doesn't say PCN as a whole only concerns v4 & v6. Definitely not. =20 " This document only concerns the PCN wire protocol encoding for IP headers, whether IPv4 or IPv6. It makes no changes or recommendations concerning algorithms for congestion marking or congestion response. Other documents will define the PCN wire protocol for other header types. Appendix C discusses a possible mapping between IP and MPLS. " (BTW, PCN marking has been implemented in hardware for IP and MPLS.) =20 So, PCN is also open for use with other header types than IPv4 and IPv6.=20 =20 >=20 > --- >=20 > What does "Primarily" mean in this context? >=20 > I would like you to replace the passive voice in Section 4. > so I can tell who made the decision! Georgios: We agree that the text in Section 4.5 is confusing, we would like= to change the text from: Change from: "Primarily, it has been decided to take forward the baseline encoding,=20 described in Section 4.1 and defined in RFC5696. Subsequently, it has=20 been decided to take forward the 3-in-1 encoding, which is described=20 in Section 4.2 and defined in [I-D.ietf-pcn-3-in-1-encoding]; as an=20 RFC it would obsolete the baseline encoding." INTO: =20 "The baseline encoding described in section 4.1 was published as a draft In= ternet Standard [RFC5696].=20 The intention was to allow for experimental encodings to build upon this ba= seline.=20 However, following the publication of [RFC6040], the WG decided to change a= pproach and instead standardise only=20 one encoding (the 3-in-1 encoding described in 4.2 [draft-pcn-3-in-1]). Rat= her than defining the 3-in-1 encoding as a=20 standards track extension to the existing baseline encoding [RFC5696], it w= as agreed that it was best to define=20 a new standards track document that obsoletes [RFC5696]." >=20 >=20 >=20 > Additionally, I would like to understand why there are other=20 > PCN working group documents for other encodings (draft-ietf-pcn-3-state- > encoding, draft-ietf-pcn-psdm-encoding) if this=20 > section represent a full statement of the WG's decisions. =20 Georgios: This section refers to these documents to show the alternative e= ncodings that have been taken into account by the PCN WG.=20 Currently, there is no consensus in the PCN WG on the issue of whether the = two following encodings drafts should be=20 published as historical RFCs or be abandoned. http://tools.ietf.org/html/draft-ietf-pcn-psdm-encoding-01 http://tools.ietf.org/html/draft-ietf-pcn-3-state-encoding-01 For the time being we reused the references to the expired I-Ds. >=20 > --- > I'm afraid I found the conclusion in Section 5 particularly > impenetrable. >=20 > Could you: > - Break out "what we did in this document" as a separate >=20 > paragraph. > - Make a definitive statement about what the WG has=20 > concluded. > - Place the summary of the reasons for the conclusion as=20 > a third paragraph. =20 Georgios: we would like to replace the text in Section 5, with the followin= g text: =20 "5. Conclusion This document summarises the PCN Working Group's exploration of a number of= approaches for encoding pre-congestion information into the IP header. It = is presented as an informational archive. It provides details of all those = approaches along with an explanation of the constraints that have to be met= .=20 The Working Group has concluded that the "3-in-1" encoding should be publis= hed as a standards-track RFC that obsoletes the encoding specified in [RFC5= 696]. The reasoning is as follows. During the early life of the working group, we= decided on an approach of a standardised "baseline encoding" [RFC5696] plu= s a series of experimental encodings that would all build on the baseline e= ncoding and each of which would be useful in specific circumstances. Howeve= r, after the tunnelling of ECN was standardized in [RFC6040], the PCN WG de= cided on a different approach - to recommend just one encoding, the "3-in-1= encoding". Although in theory "3-in-1" could be specified as a standards-t= rack extension to the "baseline" encoding, the WG decided that it would be = cleaner to obsolete RFC5696 and specify "3-in-1" encoding in a new stand-al= one RFC."=20 > ------------------------------------------------------------->--------> - > COMMENT: > ------------------------------------------------------------->--------> - >=20 > In Section 1 > > This requires at least three different codepoints for not-marked PCN=20 > traffic, PCN traffic re-marked by the threshold-=20 > marker, and PCN traffic re-marked by the excess-traffic-=20 > marker. > > Please insert a colon after "codepoints" in order to fix the=20 > meaning. Georgios: We would like to change from: "This PCN information has to be encoded into the IP header. This requires at least three different codepoints for not-marked PCN traffic, PCN traffic re-marked by the threshold-marker, and PCN traffic re-marked by the excess-traffic-marker." INTO: "This PCN information has to be encoded into the IP header. This requires a= t least three different codepoints: one for PCN traffic that has not been m= arked, one for traffic that has been marked by the threshold meter and one = for traffic that has been marked by the excess-traffic-meter." =20 =20 >=20 > --- >=20 > In Section 1 >=20 > This document summarizes these issues for historical =20 > purposes. >=20 > Do you want to publish this as a Historic RFC? =20 Georgios: No, we will replace this sentence with the following one: "This document summarises these issues as a record of the PCN WG discussio= ns and for the benefit of the wider IETF community." =20 >=20 > --- >=20 > Section 3 >=20 > The Differentiated Services (DS) field is chosen for the =20 > encoding of PCN marks. >=20 > This use of the passive voice is not helpful! >=20 > - Has the choice already been made? If so give a reference. > - Does this document document the choice being made? If so=20 > give a forward pointer or explanation. > - Or is this just commentary? :-) =20 Georgios: Agree that the current text in the introductory part of Section 3 is not cl= ear. We would like to change the text from: =20 "The Differentiated Services (DS) field is chosen for the encoding of PCN marks. This section briefly reviews the DS field and the constraints imposed by its reuse are summarized." =20 INTO: =20 "The PCN WG decided to use the DS field (i.e., combination of the DSCP and= ECN field) for the encoding of the PCN Marks, see [RFC5696].=20 This section describes the criteria that are used to compare the resulting = encoding options described in section 4." >=20 >=20 > --- >=20 > I think Section 3.1 makes [RFC0793], [RFC2474], and=20 > [RFC3168] into normative references. 3.3.1 reinfotces that=20 > for [RFC3168]. > > Section 3.3 and 3.3.2 appear to make [RFC4774] normative. =20 Georgios: Agree, we list: [RFC0793], [RFC2474], [RFC3168], [RFC4774] as nor= mative references. In order to do that we will create a new subsection in S= ection 9 on Normative References. >=20 > --- >=20 > Section 3.3.3.4 uses "CU" before it is explained in Seciton=20 > 4 and defined in Section 4.3 =20 Georgios: Agree, in ordert to solve this we will include the following text= in Section 3.3.3.4: "Certain combinations of inner and outer ECN fields cannot result from any = transition in any current or previous ECN tunneling specification. These currently unused (CU) combinations are indicated in F= igure 6 by '(!!!)' or '(!)', where '(!!!)' means the combination is CU and always potentially dangerous, while '(!)' means it is= CU and possibly dangerous." =20 =20 >=20 >>=20 >> --- >>=20 >> Section 4 >>=20 >> Figure 7 summarizes these PCN encodings. as summarized >> in Figure 7. =20 Georgios: Editorial error: we will remove =93as summarized in Figure 7.=94= =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DISCUSS of Russ Housley and comments from Pete McCann ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- > The Gen-ART Review by Pete McCann on 28-Feb-2012 raised an=20 > inconsistency that needs to be resolved. > Section 3.3.3.4: > With the normal mode, the ECN field of the inner header is copied to > the ECN field of the outer header on encapsulation (like the limited > functionality option in Section 3.3.3.1). > The limited functionality option says to set the outer header to not-ECT. > This seems to contradict the above statement. Georgios: We deleted/ (like the limited functionality option in Section 3.3= .3.1)/ I also suggest the end of 3.3.3. needs to mention RFC6040, rather=20 than waiting until 3.3.3.4, which otherwise looks like an afterthought. OLD 3.3.3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Two different modes are defined in [RFC3168] for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec tunnels. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEW 3.3.3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Two different modes are defined in [RFC3168] for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec tunnels. [RFC6040] updates both these RFCs to rationalise them into one consistent approach. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > The Gen-ART Review by Pete McCann on 28-Feb-2012 included some > editorial suggestions that deserve consideration > Section 3.3.3.3: > full- > functionality option in Section 3.3.2.2. > I think you meant "Section 3.3.3.2". One other place in this > paragraph needs this correction. Georgios: Modified! > Section 4.2: > The problem with 3-in-1 encoding is that the 10-codepoint does not > survive decapsulation with the tunneling options in Section 3.3.2.1 - > 3.3.2.3. > Again, you meant 3.3.3.1 - 3.3.3.3 Georgios: Modified =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens internet-drafts@iet= f.org [internet-drafts@ietf.org] Verzonden: donderdag 8 maart 2012 22:00 Aan: i-d-announce@ietf.org CC: pcn@ietf.org Onderwerp: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-09.txt 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 : Overview of Pre-Congestion Notification Encoding Author(s) : Georgios Karagiannis Kwok Ho Chan Toby Moncaster Michael Menth Philip Eardley Bob Briscoe Filename : draft-ietf-pcn-encoding-comparison-09.txt Pages : 19 Date : 2012-03-08 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. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-09.t= xt 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-encoding-comparison-09.tx= t _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From sebastien.jobert@orange.com Thu Mar 8 16:48:54 2012 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 CDE8F21F84D2 for ; Thu, 8 Mar 2012 16:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92urKxTdKgmK for ; Thu, 8 Mar 2012 16:48:53 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 34E2921F84D1 for ; Thu, 8 Mar 2012 16:48:53 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8F64A16C004 for ; Fri, 9 Mar 2012 01:48:52 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8309316C001 for ; Fri, 9 Mar 2012 01:48:52 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 01:48:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFD8E.65ABFBCF" Date: Fri, 9 Mar 2012 01:48:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft "Pre-congestion notification in mobile networks" Thread-Index: Acz9jmV/jI017tGyRqSrtkBMX0cBTw== From: To: X-OriginalArrivalTime: 09 Mar 2012 00:48:52.0342 (UTC) FILETIME=[65E26160:01CCFD8E] X-Mailman-Approved-At: Thu, 08 Mar 2012 20:50:43 -0800 Cc: isabelle.hamchaoui@orange.com Subject: [PCN] Draft "Pre-congestion notification in mobile networks" 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: Fri, 09 Mar 2012 00:48:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFD8E.65ABFBCF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 We have uploaded an Internet-Draft called "Pre-congestion notification = in mobile networks" - = http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mobile-00.pdf= =20 Abstract =20 Mobile networks may be divided into two main segments: the radio segment, and the wireline segment. This document highlights that the algorithms leading to pre-congestion notification (e.g. ECN marking) are usually significantly different for these two segments, and not defined or documented in general over the radio segment. It also explains that using ECN bits leads to having a unique signal for notifying a pre-congestion related to two separate segments with very different notification algorithms. Some consequences are questioned, as well as the potential benefits of being able to identify where the congestion comes from. This document finally discusses the possibility to take into account the radio conditions of the terminals when counting the volume of congestion over the radio segment. =20 It has been posted in TSVWG, but the chairs indicated some possible = interest from PCN. We are interested by review and comments. =20 Thanks. =20 Best Regards, =20 S=E9bastien JOBERT Orange Expert, network synchronization and QoS in mobile networks Orange Labs, Networks & Carriers - France Telecom Orange sebastien.jobert@orange.com = =20 =20 =20 ------_=_NextPart_001_01CCFD8E.65ABFBCF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We have uploaded an Internet-Draft called = “Pre-congestion notification in mobile networks” - http://www.ietf.org/id/draft-jobert-tsvwg-pre-congest-notif-mob= ile-00.pdf

 

Abstract

 

   Mobile networks may be divided into two main = segments: the radio

   segment, and the wireline segment. This document = highlights that the

   algorithms leading to pre-congestion notification = (e.g. ECN marking)

   are usually significantly different for these two = segments, and not

   defined or documented in general over the radio = segment. It also

   explains that using ECN bits leads to having a unique = signal for

   = notifying a pre-congestion related to two separate segments = with

   very = different notification algorithms. Some consequences = are

   = questioned, as well as the potential benefits of being able = to

   = identify where the congestion comes from. This document = finally

   = discusses the possibility to take into account the radio = conditions

   of the = terminals when counting the volume of congestion over = the

   radio = segment.

 

It has been posted in TSVWG, but the chairs indicated some = possible interest from PCN.

We are interested by review and = comments.

 

Thanks.

 

Best = Regards,

 

S=E9bastien = JOBERT
Orange = Expert, network synchronization and QoS in mobile = networks
Orange Labs, Networks & Carriers - France Telecom = Orange
sebastien.jobert@orange.com

 

 

------_=_NextPart_001_01CCFD8E.65ABFBCF-- From ietfdbh@comcast.net Sat Mar 10 08:16:01 2012 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 9233521F8606 for ; Sat, 10 Mar 2012 08:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcrX51ecV8ZO for ; Sat, 10 Mar 2012 08:16:00 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id B3FBE21F8600 for ; Sat, 10 Mar 2012 08:16:00 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta12.westchester.pa.mail.comcast.net with comcast id jsDk1i0060vyq2s5CsG17f; Sat, 10 Mar 2012 16:16:01 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta05.westchester.pa.mail.comcast.net with comcast id jsFz1i01B3Ecudz3RsFzoK; Sat, 10 Mar 2012 16:16:01 +0000 From: "ietfdbh" To: "'Tom Taylor'" References: <4F56848A.7040909@gmail.com> In-Reply-To: <4F56848A.7040909@gmail.com> Date: Sat, 10 Mar 2012 11:15:57 -0500 Message-ID: <2D3AE0E3B7D4407EBC3B05F2AE4E2433@JV6RVH1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: Acz74eVKRtPAX7WrSCWDa0mfKFVX3wC9HMYw Cc: pcn@ietf.org, pcn-chairs@tools.ietf.org Subject: Re: [PCN] status of cl and sm edge docs? 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, 10 Mar 2012 16:16:01 -0000 Hi, Every IESG is different, and some of the current, continuing members are particular about Experimental status. I fully expect you will be asked to make changes to the document to describe in the Introduction what the experiment is, who should participate in the experiment, how long should the experiment run, what are the evaluation criteria, and what is the expected follow-up to such an experiment? Since we plan to close PCN after these docs get through, we cannot plan on specific follow-up. Here is some suggested text for the last part: "After the experiment, the IETF community might choose to advance these from Experimental to standards-track, by creating a new PCN-related WG, having the work done in another WG such as TSVWG, or advancing the docs as AD-sponsored. That will be a decision that will need to be made by the community after the experiment concludes." Please put together a few paragraphs to introduce the experiment. If you provide the new text to me before the IESG telechat, I can handle this as a note to the RFC Editor. David Harrington Transport Area Director ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] Sent: Tuesday, March 06, 2012 4:42 PM To: David Harrington Cc: pcn@ietf.org Subject: Re: [PCN] status of cl and sm edge docs? It was Joel Halpern's comment, but I see rev iewing my response that this didn't go to the list. Can I confirm that Experimental is agreeable to the WG? On 06/03/2012 2:57 PM, David Harrington wrote: > Hi, > > I notice the status in the document has been changed from Informational to > Experimental, but in the datatracker it is still Informational. > Can somebody point me to the discussion thread for this change to > Experimental? > > > -- > David Harrington > Director, Transport Area > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Sat Mar 10 11:38:16 2012 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 55E1121F8573; Sat, 10 Mar 2012 11:38:16 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YraweG93CqWZ; Sat, 10 Mar 2012 11:38:15 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4D18221F8567; Sat, 10 Mar 2012 11:38:15 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 10 Mar 2012 20:38:18 +0100 Received: from EXMBX08.ad.utwente.nl ([169.254.8.70]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Sat, 10 Mar 2012 20:38:13 +0100 From: To: Thread-Topic: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt Thread-Index: AQHM/vHPyDzMOlz96k6m6JtqOWLXI5Zj5gzL Date: Sat, 10 Mar 2012 19:38:13 +0000 Message-ID: References: <20120310191250.10652.27259.idtracker@ietfa.amsl.com> In-Reply-To: <20120310191250.10652.27259.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.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, 10 Mar 2012 19:38:16 -0000 Hi all, Please note that draft-ietf-tsvwg-rsvp-pcn-01.txt has just been posted. The following modifications have been done, see Section 4 (introductory tex= t) and section 4.1: o) The CLE field has been removed from the PCN object format. o) two new CL based PCN objects have been defined that can be used to carry= the number of flow identifiers for individual flows within an ingress-egre= ss-aggregate that have recently experienced excess-marking, see also draft= -ietf-pcn-signaling-requirements-08: o) Controlled (CL) PCN CL Flow IDs object, IPv4 addresses are used:=20 Class =3D PCN C-Type =3D RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs o) Controlled (CL) PCN CL Flow IDs object, IPv6 addresses are used:= =20 Class =3D PCN C-Type =3D RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs The main open issue, see also section 4 (introductory text) that is relate= d to one of the above listed modifications and needs to be discussed by the= tsvwg WG is the following: There are at least two possible options of carrying the=20 PCN objects of C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or=20 RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs: o) Option 1: The PCN objects of C-Type:=20 RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or=20 RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by the=20 aggregated Resv message together with the other PCN object=20 C-Types. The advantage of this object is that no additional=20 message needs to be supported by this signaling protocol. The=20 drawback of this option is that the PCN objects of C-Type: RSVP- AGGREGATE-IPv4-PCN-CL-FLIDs or RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs=20 can become larger than the maximum transmission unit (MTU) along=20 a path to the Aggregator. o) Option 2: The PCN objects of C-Type: =20 RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or=20 RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by NOTIFY=20 messages, see [RFC3473]. In particular, the NOTIFY=20 field could carry the flow IDs. The=20 advantage of this option is that the total list of the flow IDs=20 that need to be sent to the Aggregator can be divided in smaller=20 sets. Each of these sets can be then carried by one NOTIFY=20 message. The number of flow IDs that are included in such a set=20 MUST be such that the length of any NOTIFY message will not=20 become larger than the maximum transmission unit (MTU) along a=20 path to the Aggregator. The main disadvantage is the signaling=20 protocol needs to use an additional message type. If this option=20 is chosen then the format of the PCN objects of=20 C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or=20 RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs may need modifications. The=20 same holds for the procedures on handling the NOTIFY message by=20 the Interior nodes and by the Aggregator. Best regards, Georgios ________________________________________ Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens internet-drafts= @ietf.org [internet-drafts@ietf.org] Verzonden: zaterdag 10 maart 2012 20:12 Aan: i-d-announce@ietf.org CC: tsvwg@ietf.org Onderwerp: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Generic Aggregation of Resource ReSerVation Proto= col (RSVP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-01.txt Pages : 26 Date : 2012-03-10 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-01.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-tsvwg-rsvp-pcn-01.txt= From tom.taylor.stds@gmail.com Sat Mar 10 13:08:49 2012 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 2F8AD21F84B6; Sat, 10 Mar 2012 13:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90Ds0gCtb0gy; Sat, 10 Mar 2012 13:08:48 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9AD21F849C; Sat, 10 Mar 2012 13:08:48 -0800 (PST) Received: by dakl33 with SMTP id l33so3367174dak.31 for ; Sat, 10 Mar 2012 13:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=QUEOcTdJw1sEGg94Xb19UkVXVokLaLvZ6EgC5kg7z8A=; b=B1G5yLddWhtipXJtDrdcPtI71h+gl2OcBs/i2n3rVPPsOPOf6dPX8PT4VYJVwYDFUO 7AE2N8JFYWf/eekze/uRSAEUz28dU9CwQdwal8R94JrrnZWG04PqKDwQOEQi5usDiGVe Js2LZ/bUoG92qA/OEPazaIKBpEpBNJrEC8bUgaSpQJ0tRCb9qbbEzFBjaZDndNUGd2S1 g6ljLPmJDKa1UkBmeKgZbx94L5Y9tcJOym9PEVUgaOL6YVhXPUhHwfBXWKL4j0RXacEA PoKFiheM1Oma7WoqrPGkjjjO0pW9V1/AxJrZmA+J+KWtfh7HkYxndJnNacskK9SlNXfc MKUA== Received: by 10.68.219.164 with SMTP id pp4mr11362734pbc.2.1331413727978; Sat, 10 Mar 2012 13:08:47 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-65-140.tor.primus.ca. [173.206.65.140]) by mx.google.com with ESMTPS id y3sm6843371pbr.46.2012.03.10.13.08.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Mar 2012 13:08:47 -0800 (PST) Message-ID: <4F5BC2E0.407@gmail.com> Date: Sat, 10 Mar 2012 16:08:48 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: karagian@cs.utwente.nl References: <20120310191250.10652.27259.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120310-1, 10/03/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org, tsvwg@ietf.org Subject: Re: [PCN] I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.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, 10 Mar 2012 21:08:49 -0000 The CL edge behaviour draft allows implementations to keep the number of flow identifiers down to a reasonable size. I would therefore suggest no new message is needed to carry them. On 10/03/2012 2:38 PM, karagian@cs.utwente.nl wrote: > Hi all, > > Please note that draft-ietf-tsvwg-rsvp-pcn-01.txt has just been posted. > The following modifications have been done, see Section 4 (introductory text) and section 4.1: > > o) The CLE field has been removed from the PCN object format. > > o) two new CL based PCN objects have been defined that can be used to carry the number of flow identifiers for individual flows within an ingress-egress-aggregate that have recently experienced excess-marking, see also draft-ietf-pcn-signaling-requirements-08: > > o) Controlled (CL) PCN CL Flow IDs object, IPv4 addresses are used: > Class = PCN > C-Type = RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs > > o) Controlled (CL) PCN CL Flow IDs object, IPv6 addresses are used: > Class = PCN > C-Type = RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs > > The main open issue, see also section 4 (introductory text) that is related to one of the above listed modifications and needs to be discussed by the tsvwg WG is the following: > > There are at least two possible options of carrying the > PCN objects of C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or > RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs: > o) Option 1: The PCN objects of C-Type: > RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or > RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by the > aggregated Resv message together with the other PCN object > C-Types. The advantage of this object is that no additional > message needs to be supported by this signaling protocol. The > drawback of this option is that the PCN objects of C-Type: RSVP- > AGGREGATE-IPv4-PCN-CL-FLIDs or RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs > can become larger than the maximum transmission unit (MTU) along > a path to the Aggregator. > > o) Option 2: The PCN objects of C-Type: > RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or > RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs MUST be carried by NOTIFY > messages, see [RFC3473]. In particular, the NOTIFY > field could carry the flow IDs. The > advantage of this option is that the total list of the flow IDs > that need to be sent to the Aggregator can be divided in smaller > sets. Each of these sets can be then carried by one NOTIFY > message. The number of flow IDs that are included in such a set > MUST be such that the length of any NOTIFY message will not > become larger than the maximum transmission unit (MTU) along a > path to the Aggregator. The main disadvantage is the signaling > protocol needs to use an additional message type. If this option > is chosen then the format of the PCN objects of > C-Type: RSVP-AGGREGATE-IPv4-PCN-CL-FLIDs or > RSVP-AGGREGATE-IPv6-PCN-CL-FLIDs may need modifications. The > same holds for the procedures on handling the NOTIFY message by > the Interior nodes and by the Aggregator. > > Best regards, > Georgios > > > ________________________________________ > Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens internet-drafts@ietf.org [internet-drafts@ietf.org] > Verzonden: zaterdag 10 maart 2012 20:12 > Aan: i-d-announce@ietf.org > CC: tsvwg@ietf.org > Onderwerp: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > Title : Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains > Author(s) : Georgios Karagiannis > Anurag Bhargava > Filename : draft-ietf-tsvwg-rsvp-pcn-01.txt > Pages : 26 > Date : 2012-03-10 > > 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. > > > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-01.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-tsvwg-rsvp-pcn-01.txt From bob.briscoe@bt.com Sun Mar 11 09:00:03 2012 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 C505D21F8603 for ; Sun, 11 Mar 2012 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNLyj5ZdeAJ5 for ; Sun, 11 Mar 2012 09:00:03 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id CB0AE21F85C6 for ; Sun, 11 Mar 2012 09:00:02 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 11 Mar 2012 16:00:00 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 11 Mar 2012 16:00:00 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.1.323.0; Sun, 11 Mar 2012 15:59:54 +0000 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 133148159447; Sun, 11 Mar 2012 15:59:54 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.152.75]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2BFxq94000854; Sun, 11 Mar 2012 15:59:52 GMT Message-ID: <201203111559.q2BFxq94000854@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 11 Mar 2012 14:39:28 +0000 To: Steven Blake From: Bob Briscoe In-Reply-To: <1331182874.6028.14.camel@tachyon> References: <1331182874.6028.14.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 Cc: pcn@ietf.org Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 11 Mar 2012 16:00:03 -0000 Steve, I got the impression most people (including you) were converging on not publishing psdm & 3-state as historical RFCs (unnec hassle for authors, IESG, GEN-ART etc). But then your latest message below seems to imply it is decided that we will. We can publish as historical if people want (personally I've already said I don't see the need). However, it would be useful to have a decision whether to go ahead by early tomorrow to give us a fighting chance. Bob At 05:01 08/03/2012, Steven Blake wrote: >On Tue, 2012-03-06 at 13:23 -0500, David Harrington wrote: > > > Hi, > > > > It appears to me the drafts have already expired. > > You can refer to expired drafts in an Informational document, using an > > approach similar to this: > > > > The XYZ encoding was proposed in a draft document submitted to the PCN > > WG in > 2006>. The PCN WG chose to not advance this draft. > > > > > > This way there is no reference to the expired draft, and the intentions to > > not carry the drafts forward is easy to see. > > > > Now, as to whether publishing them as historical is the right way: > > How much more detail is in the drafts that will be lost if we just let > > them expire? > > Is it important to the industry to keep a record of that historical > > detail, or just a summary of the ideas in those drafts and why they didn't > > work. > > I can understand that academically, it might be nice to have these > > published as historical records, but I tend to agree that having them > > published as RFCs could confuse people who are not really knowledgeable > > about IETF practice and the difference in types of RFCs. > > If the summary seems adequate, then I recommend letting the drafts > > disappear. > > You should make sure all your documents do not contain any references to > > those drafts. > >I think this last bit of advice applies even if the WG chooses to >publish the expired drafts. > >Now, are there any volunteers to revise these drafts and get them in >shape for WG last call? > > >Regards, > >// Steve > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From tm444@hermes.cam.ac.uk Sun Mar 11 10:09:03 2012 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 779E021F85A2 for ; Sun, 11 Mar 2012 10:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuwwQsHBrRm8 for ; Sun, 11 Mar 2012 10:09:02 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9E04321F8630 for ; Sun, 11 Mar 2012 10:09:02 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:47597) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:tm444) id 1S6mGS-0002Xo-XA (Exim 4.72) (return-path ); Sun, 11 Mar 2012 17:09:00 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:tm444) id 1S6mGS-0002bW-7n (Exim 4.67) (return-path ); Sun, 11 Mar 2012 17:09:00 +0000 Received: from [128.232.235.161] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 11 Mar 2012 17:09:00 +0000 Date: 11 Mar 2012 17:09:00 +0000 From: Toby Moncaster To: Bob Briscoe Message-ID: In-Reply-To: <201203111559.q2BFxq94000854@bagheera.jungle.bt.co.uk> References: <1331182874.6028.14.camel@tachyon> <201203111559.q2BFxq94000854@bagheera.jungle.bt.co.uk> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: "T. Moncaster" Cc: pcn@ietf.org Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: toby.moncaster@cl.cam.ac.uk List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:09:03 -0000 Although it did seem like the balance was towards non-publication I think this should be explicitly decided by the WG. I have a marginal preference for publication because I think it wouldn't take all that much work. I did wonder at one stage whether the two could be combined into a single historical RFC, but that didn't seem workable. I also wondered if there could be more about them in the encoding comparison, but that would make it a less balanced document. However we do seem to be getting fundamentally contradictory guidance regarding how to reference these drafts (and not to reference them would be wrong/dishonest in my opinion). Toby On Mar 11 2012, Bob Briscoe wrote: >Steve, > >I got the impression most people (including you) were converging on >not publishing psdm & 3-state as historical RFCs (unnec hassle for >authors, IESG, GEN-ART etc). But then your latest message below seems >to imply it is decided that we will. > > We can publish as historical if people want (personally I've already said > I don't see the need). However, it would be useful to have a decision > whether to go ahead by early tomorrow to give us a fighting chance. > > > >Bob > >At 05:01 08/03/2012, Steven Blake wrote: >>On Tue, 2012-03-06 at 13:23 -0500, David Harrington wrote: >> >> > Hi, >> > >> > It appears to me the drafts have already expired. >> > You can refer to expired drafts in an Informational document, using an >> > approach similar to this: >> > >> > The XYZ encoding was proposed in a draft document submitted to the >> > PCN WG in > > 2006>. The PCN WG chose to not advance this draft. >> > >> > >> > This way there is no reference to the expired draft, and the >> > intentions to not carry the drafts forward is easy to see. >> > >> > Now, as to whether publishing them as historical is the right way: >> > How much more detail is in the drafts that will be lost if we just let >> > them expire? Is it important to the industry to keep a record of that >> > historical detail, or just a summary of the ideas in those drafts and >> > why they didn't work. I can understand that academically, it might be >> > nice to have these published as historical records, but I tend to >> > agree that having them published as RFCs could confuse people who are >> > not really knowledgeable about IETF practice and the difference in >> > types of RFCs. If the summary seems adequate, then I recommend letting >> > the drafts disappear. You should make sure all your documents do not >> > contain any references to those drafts. >> >>I think this last bit of advice applies even if the WG chooses to >>publish the expired drafts. >> >>Now, are there any volunteers to revise these drafts and get them in >>shape for WG last call? >> >> >>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 > From slblake@petri-meat.com Sun Mar 11 12:01:21 2012 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 08C6E21F8688 for ; Sun, 11 Mar 2012 12:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.967 X-Spam-Level: X-Spam-Status: No, score=-101.967 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgFiOG9TT07V for ; Sun, 11 Mar 2012 12:01:20 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 224EF21F868A for ; Sun, 11 Mar 2012 12:01:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=bHdbcviLQTtDCX62rVdtd1pcf6Iyn7tDBlKpPGwBqTmNBwLtexhLIDwNFB0392Mpof73zbCdQsIR/HvRUW/v+gRhU8KbsHLXUVcNMRv+xBtEEQJwowwcJaWFZo3t6Mzu; Received: from cpe-071-065-228-004.nc.res.rr.com ([71.65.228.4]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S6o11-00032m-Vf; Sun, 11 Mar 2012 15:01:13 -0400 From: Steven Blake To: Bob Briscoe Date: Sun, 11 Mar 2012 15:01:14 -0400 In-Reply-To: <201203111559.q2BFxq94000854@bagheera.jungle.bt.co.uk> References: <1331182874.6028.14.camel@tachyon> <201203111559.q2BFxq94000854@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1331492476.15880.14.camel@tachyon> Mime-Version: 1.0 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] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 11 Mar 2012 19:01:21 -0000 On Sun, 2012-03-11 at 14:39 +0000, Bob Briscoe wrote: > Steve, > > I got the impression most people (including you) were converging on > not publishing psdm & 3-state as historical RFCs (unnec hassle for > authors, IESG, GEN-ART etc). But then your latest message below seems > to imply it is decided that we will. > > We can publish as historical if people want (personally I've already > said I don't see the need). However, it would be useful to have a > decision whether to go ahead by early tomorrow to give us a fighting chance. It's a WG decision, not the chairs, but it is pointless to discuss it if no-one will volunteer to do the work. Given the looming deadline, I suggest that if anyone wants to see them published and is willing to do the work, they go ahead and refresh the drafts. The WG can finalize the decision this week. I have to say that, by my reading of the list, there is no rough consensus in either direction. Regards, // Steve From internet-drafts@ietf.org Sun Mar 11 17:52:24 2012 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 EA84921F8735; Sun, 11 Mar 2012 17:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUAxC2L2CX8D; Sun, 11 Mar 2012 17:52:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E14821F859A; Sun, 11 Mar 2012 17:52:23 -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: 4.00 Message-ID: <20120312005223.12513.63218.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 17:52:23 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-3-in-1-encoding-09.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, 12 Mar 2012 00:52:24 -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-09.txt Pages : 26 Date : 2012-03-11 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. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational Appendix. The encoding for IP 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-09.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-09.txt From bob.briscoe@bt.com Sun Mar 11 20:30:25 2012 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 773AB21F854B for ; Sun, 11 Mar 2012 20:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCli-OQZjOXQ for ; Sun, 11 Mar 2012 20:30:24 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 22E1621F854A for ; Sun, 11 Mar 2012 20:30:23 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Mar 2012 03:30:20 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Mar 2012 03:30:20 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.1.323.0; Mon, 12 Mar 2012 03:30:15 +0000 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 1331523014947; Mon, 12 Mar 2012 03:30:14 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.80.16]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2C3UDqV002357 for ; Mon, 12 Mar 2012 03:30:14 GMT Message-ID: <201203120330.q2C3UDqV002357@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Mar 2012 03:30:11 +0000 To: PCN IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_751614774==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [PCN] New Version: draft-ietf-pcn-3-in-1-encoding-09.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, 12 Mar 2012 03:30:25 -0000 --=====================_751614774==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed PCN folks, Following IESG review (particularly Adrian Farrel's being the most comprehensive and useful), we've posted a new version of the PCN 3-in-1 encoding. As well as a number of editorial changes, some technical changes were needed in order to satisfy Adrian's request to specify exactly what an implementer has to do at the ingress to allow ECN to co-exist with PCN, and what defaults should be set to. In particular, for a non-PCN packet (i.e. doesn't match any flow-state) that clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 is: * re-mark the DSCP to a DSCP that is not PCN-compatible; [...] In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. Actually, the whole of the ingress behaviour section (5.1) has been re-written, incorporating material that was previously repeated in both edge-behaviours (agreed with IESG and with edge-behaviour authors, of course). Altho it largely does the same thing technically, it is written to cover the complete range of possible scenarios, and it now gives defaults and recommended choices. I don't think it's controversial, but shout if it is. Bob PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: * Added note about fail-safe to protect other traffic in the event of tunnel misconfiguration. * Changed section heading to be about applicability of environments to the encoding, rather than the encoding to the environments. * Completely re-wrote PCN-ingress Node Behaviour section. * Changed PCN interior node to PCN-node where the term was intended to include all PCN-nodes. * Clarified status of ECN/PCN co-existence appendix. Removed inconsistent assertion in this appendix that an admission- control DSCP alone can indicate that arriving traffic is PCN- traffic. * A few clarifying editorial amendments and updated refs. >From: >To: , > , > , > , >Date: Sun, 11 Mar 2012 17:52:23 -0700 >Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt > >New version (-09) has been submitted for >draft-ietf-pcn-3-in-1-encoding-09.txt. >http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt > > >Diff from previous version: >http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09 > >IETF Secretariat. ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_751614774==.ALT Content-Type: text/html; charset="us-ascii" PCN folks,

Following IESG review (particularly Adrian Farrel's being the most comprehensive and useful), we've posted a new version of the PCN 3-in-1 encoding.

As well as a number of editorial changes, some technical changes were needed in order to satisfy Adrian's request to specify exactly what an implementer has to do at the ingress to allow ECN to co-exist with PCN, and what defaults should be set to.

In particular, for a non-PCN packet (i.e. doesn't match any flow-state) that clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 is:

      *  re-mark the DSCP to a DSCP that is not PCN-compatible;

      
[...]                                                             
In the
      absence of any operator-specific
configuration for this case, by
      default an implementation SHOULD re-mark
the DSCP to zero.
Actually, the whole of the ingress behaviour section (5.1) has been re-written, incorporating material that was previously repeated in both edge-behaviours (agreed with IESG and with edge-behaviour authors, of course). Altho it largely does the same thing technically, it is written to cover the complete range of possible scenarios, and it now gives defaults and recommended choices. I don't think it's controversial, but shout if it is.
< http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 >



Bob

PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:

      *  Added note about fail-safe to protect other traffic in the
         event of tunnel misconfiguration.

      *  Changed section heading to be about applicability of
         environments to the encoding, rather than the encoding to the
         environments.

      *  Completely re-wrote PCN-ingress Node Behaviour section.

      *  Changed PCN interior node to PCN-node where the term was
         intended to include all PCN-nodes.

      *  Clarified status of ECN/PCN co-existence appendix.  Removed
         inconsistent assertion in this appendix that an admission-
         control DSCP alone can indicate that arriving traffic is PCN-
         traffic.

      *  A few clarifying editorial amendments and updated refs.



From: <internet-drafts@ietf.org>
To: <pcn-chairs@tools.ietf.org>,
        <draft-ietf-pcn-3-in-1-encoding@tools.ietf.org>, <ietfdbh@comcast.net>,
        <adrian@olddog.co.uk>, <rjsparks@nostrum.com>
Date: Sun, 11 Mar 2012 17:52:23 -0700
Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt

New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.txt.
http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt


Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09

IETF Secretariat.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design --=====================_751614774==.ALT-- From karagian@cs.utwente.nl Sun Mar 11 23:53:46 2012 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 4759921F850C for ; Sun, 11 Mar 2012 23:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q8I+sV4hkgL for ; Sun, 11 Mar 2012 23:53:45 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9513E21F84BD for ; Sun, 11 Mar 2012 23:53:45 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 12 Mar 2012 07:53:44 +0100 Received: from EXMBX08.ad.utwente.nl ([169.254.8.70]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Mon, 12 Mar 2012 07:53:44 +0100 From: To: Thread-Topic: do we need to update anything more on encoding comparison before posting deadline of today? Thread-Index: AQHNABzd+mRTWSeX/U+Iz/mRTx8VRw== Date: Mon, 12 Mar 2012 06:53:43 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: [PCN] do we need to update anything more on encoding comparison before posting deadline of today? 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, 12 Mar 2012 06:53:46 -0000 Hi David, Do we need to update anything else on encoding comparison draft before post= ing deadline of today? In our opinion we worked out all DISCUSSes and comments, except the format = of some cross-references. Best regards, Georgios= From internet-drafts@ietf.org Mon Mar 12 15:00:21 2012 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 A0BC221E8104; Mon, 12 Mar 2012 15:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrzjKPyfKVb2; Mon, 12 Mar 2012 15:00:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA5721E80F5; Mon, 12 Mar 2012 15:00:18 -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: 4.00 Message-ID: <20120312220018.1522.51061.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:00:18 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-psdm-encoding-02.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, 12 Mar 2012 22:00:21 -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 : PCN Encoding for Packet-Specific Dual Marking (PSDM Enco= ding) Author(s) : Michael Menth Jozef Babiarz Toby Moncaster Bob Briscoe Filename : draft-ietf-pcn-psdm-encoding-02.txt Pages : 11 Date : 2012-03-12 Pre-congestion notification (PCN) is a link-specific and load- dependent packet re-marking mechanism and provides in Differentiated Services networks feedback to egress nodes about load conditions within the domain. It is used to support admission control and flow termination decision in a simple way. This document proposes how PCN marks can be encoded into the IP header for packet-specific dual marking (PSDM). PSDM encoding provides three different codepoints: not-ETM, not-ThM, and PM. Excess-traffic-marking may re-mark not- ETM-packets to PM and threshold-marking may re-mark not-ThM-packets to PM. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-psdm-encoding-02.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-psdm-encoding-02.txt From internet-drafts@ietf.org Mon Mar 12 15:10:23 2012 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 AE5DB21E8130; Mon, 12 Mar 2012 15:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzaoxIDNOdGa; Mon, 12 Mar 2012 15:10:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0FF21F8A9A; Mon, 12 Mar 2012 15:10:23 -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: 4.00 Message-ID: <20120312221023.7516.799.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:10:23 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-3-state-encoding-02.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, 12 Mar 2012 22:10:23 -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 : A PCN encoding using 2 DSCPs to provide 3 or more states Author(s) : Toby Moncaster Bob Briscoe Michael Menth Filename : draft-ietf-pcn-3-state-encoding-02.txt Pages : 15 Date : 2012-03-12 Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows within a controlled domain. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This experimental encoding scheme specifies how three encoding states can be carried in the IP header using a combination of two DSCPs and the ECN bits. The Basic scheme only allows for three encoding states. The Full scheme provides 6 states, enough for limited end- to-end support for ECN as well. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-state-encoding-02.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-state-encoding-02.txt From toby@moncaster.com Mon Mar 12 15:13:47 2012 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 2C2BD21F889D for ; Mon, 12 Mar 2012 15:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUVwff06eAp7 for ; Mon, 12 Mar 2012 15:13:46 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA521F8851 for ; Mon, 12 Mar 2012 15:13:46 -0700 (PDT) Received: from [10.91.187.206] ([82.132.211.152]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LaacB-1SlkSF2vip-00lc25; Mon, 12 Mar 2012 23:13:45 +0100 References: <20120312221023.7516.799.idtracker@ietfa.amsl.com> From: Toby Moncaster Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9A405) In-Reply-To: <20120312221023.7516.799.idtracker@ietfa.amsl.com> Message-Id: Date: Mon, 12 Mar 2012 22:13:36 +0000 To: "pcn@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Provags-ID: V02:K0:+AuX8gNahceSR7jR6CoyrbeLvTXTJ3YaqSNhuBfPaQL sUrDZjBH15TGc6fmEG5jplGCip7ajxbIcL370L28wDbgm9ye5M FHpmG8twYKyLiI5RQ7I63XHd9iMFrzd0QNDcUnSYhVNY6eCjWf V4HollO/WrX1dd8t0BSu021nzQsUh8dbX3iWsb4UqM88L98wZ0 pS5vZRQxDSoTuO4jpNEOtcuTB074qZCsHmSW/YXM7pZ3HbmJNg Dl4rveCvEkzzE33KwruxPazC4ah+4vujmdb1zrnEC7C3z2jUhA gWSbkh6uDxlQHf4ywfYFZlzuhiGZuvL0CL8g2cqTtzy27HwLt5 qoLdie/vlN8kbYeGFUlTPGMaM0dkMYoUzp8hSfE6VgPtQFI9ql V7kA9EjQq+dlw== Subject: Re: [PCN] I-D Action: draft-ietf-pcn-3-state-encoding-02.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, 12 Mar 2012 22:13:47 -0000 As you can all see I have posted updates for this draft and PSDM. The WG can= decide whether to go ahead with publishing these as historical or not. Toby Ps sorry for terse email - we've got some major Internet problems here in Ca= mbridge so I'm doing everything on 3G and my iPhone On 12 Mar 2012, at 22:10, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. >=20 > Title : A PCN encoding using 2 DSCPs to provide 3 or more sta= tes > Author(s) : Toby Moncaster > Bob Briscoe > Michael Menth > Filename : draft-ietf-pcn-3-state-encoding-02.txt > Pages : 15 > Date : 2012-03-12 >=20 > Pre-congestion notification (PCN) is a mechanism designed to protect > the Quality of Service of inelastic flows within a controlled domain. > It does this by marking packets when traffic load on a link is > approaching or has exceeded a threshold below the physical link rate. > This experimental encoding scheme specifies how three encoding states > can be carried in the IP header using a combination of two DSCPs and > the ECN bits. The Basic scheme only allows for three encoding > states. The Full scheme provides 6 states, enough for limited end- > to-end support for ECN as well. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-state-encoding-02.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-3-state-encoding-02.txt >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From ietfdbh@comcast.net Mon Mar 12 17:10:43 2012 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 C2F9A21F8BBA for ; Mon, 12 Mar 2012 17:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu8fX9tu3Ixz for ; Mon, 12 Mar 2012 17:10:43 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id C941021F8BB9 for ; Mon, 12 Mar 2012 17:10:42 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id ko9E1i0061swQuc51oAjT5; Tue, 13 Mar 2012 00:10:43 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta15.westchester.pa.mail.comcast.net with comcast id koAi1i0073Ecudz3boAi9b; Tue, 13 Mar 2012 00:10:43 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Mon, 12 Mar 2012 20:10:39 -0400 From: David Harrington To: "Bradner, Scott" Message-ID: Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "" Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 13 Mar 2012 00:10:44 -0000 Hi, I hope I parsed your double negatives appropriately. I was suggesting that having a normative reference to an expired draft could be problematic. I see that one of the drafts was revised as Historic . Is the WG decision to publish these as Historic or let them disappear? The IESG needs to know. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/8/12 12:14 PM, "Bradner, Scott" wrote: >Dave - > >just to be sure - you are not suggesting to not have a reference to an >expired ID (by document name, not by filename) are you? > >Scott > >On Mar 6, 2012, at 1:23 PM, David Harrington wrote: > >> Hi, >> >> It appears to me the drafts have already expired. >> You can refer to expired drafts in an Informational document, using an >> approach similar to this: >> >> The XYZ encoding was proposed in a draft document submitted to the PCN >> WG in > 2006>. The PCN WG chose to not advance this draft. >> >> >> This way there is no reference to the expired draft, and the intentions >>to >> not carry the drafts forward is easy to see. >> >> Now, as to whether publishing them as historical is the right way: >> How much more detail is in the drafts that will be lost if we just let >> them expire? >> Is it important to the industry to keep a record of that historical >> detail, or just a summary of the ideas in those drafts and why they >>didn't >> work. >> I can understand that academically, it might be nice to have these >> published as historical records, but I tend to agree that having them >> published as RFCs could confuse people who are not really knowledgeable >> about IETF practice and the difference in types of RFCs. >> If the summary seems adequate, then I recommend letting the drafts >> disappear. >> You should make sure all your documents do not contain any references to >> those drafts. >> >> -- >> David Harrington >> Director, Transport Area >> Internet Engineering Task Force (IETF) >> Ietfdbh@comcast.net >> +1-603-828-1401 >> >> >> >> >> >> On 3/5/12 6:22 AM, "philip.eardley@bt.com" >>wrote: >> >>> Yes - I think the encoding comparison draft provides a good historical >>> record of the various encodings that we thought of and their pros/cons. >>> Publishing the encodings as historical RFCs doesn't seem to me to add >>> much value, and creates extra work for WG /iesg /ietf reviewers >>> >>> phil >>> >>> -----Original Message----- >>> From: karagian@cs.utwente.nl [mailto:karagian@cs.utwente.nl] >>> Sent: 05 March 2012 10:46 >>> To: Eardley,PL,Philip,DUB8 R; toby.moncaster@cl.cam.ac.uk; pcn@ietf.org >>> Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding >>> comparison >>> >>> Hi Phil, >>> >>> Do you mean that you are rather against publishing the other encodings >>> drafts as historical RFCs. >>> >>> In a previous email I have mentioned that Option 1 (publish encodings >>> drafts as historical RFCs) proposed by Toby is probably the best >>>choice. >>> >>> However, I will not strongly insist on this option. I am also fine if >>>we >>> will not publish these encodings drafts as historical RFCs. The >>>encoding >>> comparison draft provides then the historical record of what these >>>other >>> encodings are (with the reference to the current I-Ds) like and the >>> reasons pro/anti them. >>> >>> Best regards, >>> Georgios >>> >>> >>>> -----Original Message----- >>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>> Sent: vrijdag 2 maart 2012 12:06 >>>> To: Karagiannis, G. (Georgios); toby.moncaster@cl.cam.ac.uk; >>>> pcn@ietf.org >>>> Subject: RE: [PCN] IESG feedback from 3-in-1 encoding/ encoding >>>> comparison >>>> >>>> Just a correction, lots of RFCs refer to internet drafts. >>>> >>>> I don't think Adrian's comment was one about the mechanics of >>>> references, >>>> but what the status is of these other encodings. >>>> So the solution is simple, the comparison doc spells out (more) >>>>clearly >>>> that >>>> they were ones we thought about, recorded here for posterity, but are >>>> now >>>> no longer being pursued - in favour of 3-in-1 >>>> >>>> << It appears that there are a number of alternative encoding being >>>> proposed as documented in this I-D, draft-ietf-pcn-3-state-encoding, >>>> draft- >>>> ietf-pcn-psdm-encoding, etc., and as discussed in >>>> draft-ietf-pcn-encoding- >>>> comparison. It isn't clear to me whether these encodings are being >>>> proposed >>>> to co-exist, to be used by different operators depending on specific >>>> environments, or whether they are being floated to see which one gets >>>> more market-place support.>> >>>> >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>>> karagian@cs.utwente.nl >>>> Sent: 02 March 2012 10:30 >>>> To: toby.moncaster@cl.cam.ac.uk; pcn@ietf.org >>>> Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding >>>> comparison >>>> >>>> Hi, >>>> >>>> I agree with Toby that Option 1 is probably the best one to choose! >>>> >>>> Best regards, >>>> Georgios >>>> >>>>> -----Original Message----- >>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>>>> Toby Moncaster >>>>> Sent: vrijdag 2 maart 2012 10:45 >>>>> To: pcn >>>>> Subject: [PCN] IESG feedback from 3-in-1 encoding/ encoding >>>>>comparison >>>>> >>>>> Adrian Farrel is keen to find out what the WG intentions are >>>>>regarding >>>>> the "other" WG encoding drafts. Just to remind everyone, the original >>>>> idea was to have the baseline encoding and a set of 3 experimental >>>>> encodings that built on it. Then Bob got RFC6040 published and we >>>>> decided to push 3-in-1 encoding as the main standard. This left the >>>>> other experimental encodings in limbo. They are: >>>>> >>>>> draft-ietf-pcn-psdm-encoding-01 >>>>> >>>> psdm-encoding-01> >>>>> >>>>> draft-ietf-pcn-3-state-encoding-01 >>>>> >>>> pcn-3-state-encoding-01> >>>>> >>>>> These are both cited in the encoding comparison draft which poses >>>>>some >>>>> potential problems. Firstly we are not meant to refer to IDs in RFCs, >>>>> secondly these have both long expired so will eventually disappear >>>>> from any archives, thirdly I believe Michael may still want to use >>>> PSDM >>>> experimentally? >>>>> >>>>> There would seem to be 3 possible courses of action: >>>>> >>>>> 1) We ask for these to be published as historical RFCs so they can be >>>>> referenced from encoding comparison >>>>> 2) we ask for these to be published as experimental schemes so they >>>>> can be referenced and can be used >>>>> 3) we remove all reference from the encoding comparison >>>>> >>>>> OPtion 1 is probably the easiest as (hopefully) they would not need >>>>> too much updating. Option 2 requires more work on the drafts (in >>>>>light >>>>> of the fact we are obsolete RFC5696 which they both depend on), but >>>>> would at least hold the door open to future work. Option 3 partially >>>>> defeats the point of the encoding comparison document. >>>>> >>>>> I have a very slight preference for option 1, but what do other >>>>>people >>>> think? >>>>> >>>>> Toby >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 slblake@petri-meat.com Mon Mar 12 21:38:30 2012 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 0549911E8083 for ; Mon, 12 Mar 2012 21:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.093 X-Spam-Level: X-Spam-Status: No, score=-102.093 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXoSSY4bwlSV for ; Mon, 12 Mar 2012 21:38:29 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id CB0EF11E8072 for ; Mon, 12 Mar 2012 21:38:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=MYIjBas873GUhfY7srMBEy0CNVjPIojqU4EKl2OBs2PpLJrvpZuj4sVm3Or65GkAm4Y8iGfK6yeigLcQSC6iEgRvsREppwXmTWruQBTS/cwijzaIXPNggbYIUVtC35o7; Received: from cpe-071-065-228-004.nc.res.rr.com ([71.65.228.4]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S7JVC-0003u1-C5; Tue, 13 Mar 2012 00:38:26 -0400 From: Steven Blake To: David Harrington Date: Tue, 13 Mar 2012 00:38:26 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1331613507.23822.6.camel@tachyon> Mime-Version: 1.0 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: "" , "" Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 13 Mar 2012 04:38:30 -0000 On Mon, 2012-03-12 at 20:10 -0400, David Harrington wrote: > Hi, > > I hope I parsed your double negatives appropriately. > I was suggesting that having a normative reference to an expired draft > could be problematic. > > I see that one of the drafts was revised as Historic . > Is the WG decision to publish these as Historic or let them disappear? > The IESG needs to know. I thought RFCs were re-categorized as Historic? I didn't realize that an RFC could be published as Historic right off the bat. I'm initiating a 3-day WGLC to determine whether to publish draft-ietf-pcn-psdm-encoding-02.txt and draft-ietf-pcn-3-state-encoding-02.txt as Informational/Historic RFCs (terminating EOB Thursday 3/15). Please send comments to the list ASAP. Regards, // Steve From slblake@petri-meat.com Mon Mar 12 21:43:10 2012 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 B4C1D21F88ED for ; Mon, 12 Mar 2012 21:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.177 X-Spam-Level: X-Spam-Status: No, score=-102.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPGnDrTmKj9T for ; Mon, 12 Mar 2012 21:43:02 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id E94CC21F88E7 for ; Mon, 12 Mar 2012 21:43:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Date:In-Reply-To:References:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=dZNgDkGxe25Lrg5u7Z7b/dvf0Z8ofU24wupQL5ciBP3TLlVcXqsVOxgFOA8kD6tgkiVcr1Qte/1zjTTC0fzjVO2x+MkM1A3L2GHsz6mLrvBN9l8e/VUgm6ZRUGbIO5nh; Received: from cpe-071-065-228-004.nc.res.rr.com ([71.65.228.4]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S7JZc-0006YL-PI for pcn@ietf.org; Tue, 13 Mar 2012 00:43:00 -0400 From: Steven Blake To: pcn Date: Tue, 13 Mar 2012 00:43:01 -0400 In-Reply-To: <1326953921.5194.17.camel@tachyon> References: <1326953921.5194.17.camel@tachyon> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1331613781.23822.9.camel@tachyon> Mime-Version: 1.0 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: Re: [PCN] PCN meeting in Paris? 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, 13 Mar 2012 04:43:10 -0000 On Thu, 2012-01-19 at 01:18 -0500, Steven Blake wrote: > Hi, > > Is there any interest in a PCN WG meeting in Paris? If so, please > indicate if you will attend and suggest agenda items. > > All of the chartered drafts are (finally!) at the IESG or moved to > another working group, so IMO there is not much to discuss except > potential future work. Before the IESG would agree to recharter the PCN > working group, I'm sure that they would want to know whether there are > any PCN implementations under way or deployed, and the extent of > operator interest in deploying PCN. So I suggest that the working group > discuss these questions on the list before proposing another WG session. I received a few suggestions the first time I posted this. I believe that all of the necessary drafts have been revised to resolve IESG comments, so we can suppose that they will move forward, but we should set aside some discussion time in case there are still unresolved comments. The WG needs to decide how to proceed with draft-ietf-pcn-psdm-encoding-02.txt and draft-ietf-pcn-3-state-encoding-02.txt, but that needs to happen prior to the meeting. Please send additional suggestions for the meeting agenda ASAP. I will publish a draft agenda on Wednesday. Regards, // Steve From Ruediger.Geib@telekom.de Tue Mar 13 00:33:02 2012 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 C9B5E21F886E for ; Tue, 13 Mar 2012 00:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvTmWmMZjMZ0 for ; Tue, 13 Mar 2012 00:33:02 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id E3C2C21F886B for ; Tue, 13 Mar 2012 00:33:01 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 13 Mar 2012 08:32:55 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.9]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 13 Mar 2012 08:32:53 +0100 From: To: , Date: Tue, 13 Mar 2012 08:32:51 +0100 Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: Ac0A0yzJQ84/s3Z5TUm+7dZTs7inGQAF9yhQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A06B4A1E@HE111648.emea1.cds.t-internal.com> References: <1331613507.23822.6.camel@tachyon> In-Reply-To: <1331613507.23822.6.camel@tachyon> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, toby.moncaster@cl.cam.ac.uk Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 13 Mar 2012 07:33:02 -0000 While I clearly prefer egress node based pcn policy decisions, not requiring any signaled feedback to policy decision points, I don't object to have both drafts as historic RFCs. But I don't want to work on them. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steve= n Blake Sent: Tuesday, March 13, 2012 5:38 AM To: David Harrington Cc: ; Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison On Mon, 2012-03-12 at 20:10 -0400, David Harrington wrote: > Hi, > > I hope I parsed your double negatives appropriately. > I was suggesting that having a normative reference to an expired draft > could be problematic. > > I see that one of the drafts was revised as Historic . > Is the WG decision to publish these as Historic or let them disappear? > The IESG needs to know. I thought RFCs were re-categorized as Historic? I didn't realize that an RFC could be published as Historic right off the bat. I'm initiating a 3-day WGLC to determine whether to publish draft-ietf-pcn-psdm-encoding-02.txt and draft-ietf-pcn-3-state-encoding-02.txt as Informational/Historic RFCs (terminating EOB Thursday 3/15). Please send comments to the list ASAP. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From tm444@hermes.cam.ac.uk Tue Mar 13 03:23:51 2012 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 0ADEA21F8661 for ; Tue, 13 Mar 2012 03:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AR0nlZMszaN for ; Tue, 13 Mar 2012 03:23:50 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 352C121F86AD for ; Tue, 13 Mar 2012 03:23:49 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:53655) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1S7OtO-0000BZ-sf (Exim 4.72) (return-path ); Tue, 13 Mar 2012 10:23:46 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Toby Moncaster In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A06B4A1E@HE111648.emea1.cds.t-internal.com> Date: Tue, 13 Mar 2012 10:23:46 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <086ECCBC-B2FF-4E48-827C-DE5B9BF89772@cl.cam.ac.uk> References: <1331613507.23822.6.camel@tachyon> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A06B4A1E@HE111648.emea1.cds.t-internal.com> To: X-Mailer: Apple Mail (2.1257) Sender: "T. Moncaster" Cc: pcn@ietf.org Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 13 Mar 2012 10:23:51 -0000 I guess I have to stop equivocating on this=85 I am actually in favour of publishing these as historical (with the = caveat that they are only worth expending a few man-hours effort on). Like Steve I hadn't realised that could be done, but as it seems fairly = normal procedure it seems like the right option for these drafts. I am = also prepared to put a small amount of effort into the process. My hope = would be that historical documents need a good deal less scrutiny and = hence these can be published more or less as they are in the new -02 = versions I posted last night. Toby On 13 Mar 2012, at 07:32, wrote: > While I clearly prefer egress node based pcn policy decisions, not > requiring any signaled feedback to policy decision points, I don't > object to have both drafts as historic RFCs. But I don't want to > work on them. >=20 > Regards, >=20 > Ruediger >=20 >=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Steven Blake > Sent: Tuesday, March 13, 2012 5:38 AM > To: David Harrington > Cc: ; > Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding = comparison >=20 > On Mon, 2012-03-12 at 20:10 -0400, David Harrington wrote: >=20 >> Hi, >>=20 >> I hope I parsed your double negatives appropriately. >> I was suggesting that having a normative reference to an expired = draft >> could be problematic. >>=20 >> I see that one of the drafts was revised as Historic . >> Is the WG decision to publish these as Historic or let them = disappear? >> The IESG needs to know. >=20 > I thought RFCs were re-categorized as Historic? I didn't realize that > an RFC could be published as Historic right off the bat. >=20 > I'm initiating a 3-day WGLC to determine whether to publish > draft-ietf-pcn-psdm-encoding-02.txt and > draft-ietf-pcn-3-state-encoding-02.txt > as Informational/Historic RFCs (terminating EOB Thursday 3/15). >=20 > Please send comments to the list ASAP. >=20 >=20 > Regards, >=20 > // Steve >=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 bob.briscoe@bt.com Tue Mar 13 14:07:59 2012 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 3247521F8687 for ; Tue, 13 Mar 2012 14:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InMQ3nWGsQIz for ; Tue, 13 Mar 2012 14:07:58 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 368C521F8672 for ; Tue, 13 Mar 2012 14:07:55 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 13 Mar 2012 21:07:42 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 13 Mar 2012 21:07:41 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.1.323.0; Tue, 13 Mar 2012 21:07:37 +0000 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 1331672856138; Tue, 13 Mar 2012 21:07:36 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.64.97]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2DL7XLH008899; Tue, 13 Mar 2012 21:07:34 GMT Message-ID: <201203132107.q2DL7XLH008899@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Mar 2012 21:07:35 +0000 To: Steven Blake From: Bob Briscoe In-Reply-To: <1331613781.23822.9.camel@tachyon> References: <1326953921.5194.17.camel@tachyon> <1331613781.23822.9.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 Cc: pcn Subject: Re: [PCN] PCN meeting in Paris? 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, 13 Mar 2012 21:07:59 -0000 Steven, Can I have 10mins on pcn-3-in-1-encoding ? The -09 rev of pcn-3-in-1-encoding included a significant amount of stuff about handling e2e ECN (both for PCN and non-PCN packets), in response to the IESG's (Adrian Farrel's) very valid point that we had only described the spec wrt operator config, not implementation. We've also defined defaults at his request. I'd like to present the new rules just to check the WG is happy with the outcome. I think the IESG process is continuing whether or not the WG is happy, but if someone points out a flaw I'm sure we can make further changes. I've gone thru all the combinations of requirements I can think of, and I'm v happy now that we have a nice workable solution for ECN + PCN. But I know ECN has been a controversial area in the past, so it's worth getting the perspective of others. Bob At 04:43 13/03/2012, Steven Blake wrote: >On Thu, 2012-01-19 at 01:18 -0500, Steven Blake wrote: > > > Hi, > > > > Is there any interest in a PCN WG meeting in Paris? If so, please > > indicate if you will attend and suggest agenda items. > > > > All of the chartered drafts are (finally!) at the IESG or moved to > > another working group, so IMO there is not much to discuss except > > potential future work. Before the IESG would agree to recharter the PCN > > working group, I'm sure that they would want to know whether there are > > any PCN implementations under way or deployed, and the extent of > > operator interest in deploying PCN. So I suggest that the working group > > discuss these questions on the list before proposing another WG session. > >I received a few suggestions the first time I posted this. I believe >that all of the necessary drafts have been revised to resolve IESG >comments, so we can suppose that they will move forward, but we should >set aside some discussion time in case there are still unresolved >comments. The WG needs to decide how to proceed with >draft-ietf-pcn-psdm-encoding-02.txt and >draft-ietf-pcn-3-state-encoding-02.txt, but that needs to happen prior >to the meeting. > >Please send additional suggestions for the meeting agenda ASAP. I will >publish a draft agenda on Wednesday. > > >Regards, > >// Steve > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Wed Mar 14 05:41:14 2012 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 DB79421F87A5 for ; Wed, 14 Mar 2012 05:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXapkWEAXG7O for ; Wed, 14 Mar 2012 05:41:14 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 1178F21F87A4 for ; Wed, 14 Mar 2012 05:41:13 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 14 Mar 2012 12:41:13 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Wed, 14 Mar 2012 12:41:12 +0000 From: To: , Date: Wed, 14 Mar 2012 12:41:11 +0000 Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: Ac0A0yZUSlx4tpGyQou4N8zkXioskgBCGpDQ Message-ID: <9510D26531EF184D9017DF24659BB87F331D315333@EMV65-UKRD.domain1.systemhost.net> References: <1331613507.23822.6.camel@tachyon> In-Reply-To: <1331613507.23822.6.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, toby.moncaster@cl.cam.ac.uk Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 14 Mar 2012 12:41:15 -0000 I think that the encoding-comparison draft is sufficient and that they don'= t need to be published as historical rfcs. Mainly because of the extra effo= rt involved with no benefit in my view.=20 If it is decided there is consensus and effort to progress these 2 docs as = historical, I suggest: - waiting for 3-in-1 to get to RFC status or at least into rfc editor, in c= ase issues emerge during that approval which need to be reflected back into= these two docs. (For instance, Bob recently sent an email - not sure if th= at would imply changes to these two docs as well.)=20 - please make sure key parts (abstract, intro, conclusion) make it clear th= at this is a document for archive purposes and the actual encoding to use i= s in rfcxxxx potential confusion Re: > I was suggesting that having a normative reference to an expired draft > could be problematic. I think this can be skirted round. In the encoding comparison, say somethin= g like "PSDN encoding was proposed in [ref]" Then it can be an Informational reference - since it's informing the reader= where it was proposed, whereas the actual definition is in the encoding co= mparison doc. -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steve= n Blake Sent: 13 March 2012 04:38 To: David Harrington Cc: ; Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison On Mon, 2012-03-12 at 20:10 -0400, David Harrington wrote: > Hi, >=20 > I hope I parsed your double negatives appropriately. > I was suggesting that having a normative reference to an expired draft > could be problematic. >=20 > I see that one of the drafts was revised as Historic . > Is the WG decision to publish these as Historic or let them disappear? > The IESG needs to know. I thought RFCs were re-categorized as Historic? I didn't realize that an RFC could be published as Historic right off the bat. I'm initiating a 3-day WGLC to determine whether to publish draft-ietf-pcn-psdm-encoding-02.txt and draft-ietf-pcn-3-state-encoding-02.txt as Informational/Historic RFCs (terminating EOB Thursday 3/15). =20 Please send comments to the list ASAP. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From ietfdbh@comcast.net Wed Mar 14 08:50:48 2012 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 D70E721F87BD for ; Wed, 14 Mar 2012 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrvx8h92CMSZ for ; Wed, 14 Mar 2012 08:50:48 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id E41FD21F8798 for ; Wed, 14 Mar 2012 08:50:47 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id lTqL1i0040cZkys57TqoE9; Wed, 14 Mar 2012 15:50:48 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta10.westchester.pa.mail.comcast.net with comcast id lTql1i01u3Ecudz3WTqnUP; Wed, 14 Mar 2012 15:50:48 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 14 Mar 2012 11:50:44 -0400 From: David Harrington To: Steven Blake Message-ID: Thread-Topic: alternate encodings future. In-Reply-To: <1331613507.23822.6.camel@tachyon> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "" Subject: [PCN] alternate encodings future. 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, 14 Mar 2012 15:50:49 -0000 Hi, We've had a number of things go Historic since I've been on IESG. IIRC, and I may not, we decided docs could be published directly to Historic. But I am not a process geek; I hate discussions of whether a doc must go to Informational and then be declared historic, or simply gets published as historic right off the bat. If you say it is historic, then the IESG process geeks can decide whether it must be published as informational first. The thing is, the IESG can make that change - without another IETF LC - and then declare it historic, so it doesn't matter much in my eyes. However, putting historic into the document header seriously addresses Adrian's concern that the future of these alternate docs is unclear. As a contributor, I'm good with a WG decision to go Historic. Chairs, is that the WG consensus? We need an answer to this so we can clear Adrian's discuss and get encoding-comparison into the RFC Editor's Q. Having an answer before ietf83 is definitely desirable, and earlier is preferable. Thanks, -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/13/12 12:38 AM, "Steven Blake" wrote: >On Mon, 2012-03-12 at 20:10 -0400, David Harrington wrote: > >> Hi, >> >> I hope I parsed your double negatives appropriately. >> I was suggesting that having a normative reference to an expired draft >> could be problematic. >> >> I see that one of the drafts was revised as Historic . >> Is the WG decision to publish these as Historic or let them disappear? >> The IESG needs to know. > >I thought RFCs were re-categorized as Historic? I didn't realize that >an RFC could be published as Historic right off the bat. > >I'm initiating a 3-day WGLC to determine whether to publish >draft-ietf-pcn-psdm-encoding-02.txt and >draft-ietf-pcn-3-state-encoding-02.txt >as Informational/Historic RFCs (terminating EOB Thursday 3/15). > >Please send comments to the list ASAP. > > >Regards, > >// Steve > From slblake@petri-meat.com Wed Mar 14 14:43:43 2012 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 7838421F8607 for ; Wed, 14 Mar 2012 14:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRsIt3Qzpcb7 for ; Wed, 14 Mar 2012 14:43:42 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id AF9CE21F86D0 for ; Wed, 14 Mar 2012 14:43:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To:Subject:Message-ID:X-Sender:User-Agent; b=Yq4vQaNptNVyDR1PexCKqpN76WHeYpC2SLKVN6quZo6YWQhHfV7iNj1EfvLnjhcxF71h/QP4GvLL/DP9E4pXhsXC+uEbn5gi2JmR/cKoIKnETDfzAEk+RqlQZzKiFLbm; Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S7vyk-0001Ek-4F; Wed, 14 Mar 2012 17:43:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2012 17:43:30 -0400 From: Steven Blake To: Message-ID: <4786a7da399ebc765e88e0d07f850f08@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: Roundcube Webmail/0.6 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 83 ***DRAFT*** 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: Wed, 14 Mar 2012 21:43:43 -0000 Hi, I just uploaded a draft agenda for the PCN meeting in Paris. http://www.ietf.org/proceedings/83/agenda/agenda-83-pcn.txt Comments welcome. Regards, // Steve From karagian@cs.utwente.nl Wed Mar 14 21:51:18 2012 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 0F28821F85F0 for ; Wed, 14 Mar 2012 21:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBHWxX4JLaFL for ; Wed, 14 Mar 2012 21:51:17 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 611D121F851D for ; Wed, 14 Mar 2012 21:51:12 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 15 Mar 2012 05:51:20 +0100 Received: from EXMBX08.ad.utwente.nl ([169.254.8.70]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Thu, 15 Mar 2012 05:51:10 +0100 From: To: , Thread-Topic: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison Thread-Index: AQHM+8ZDHSi5IIMo7E65Blin/16+7JZglZWAgAa9jICAAErRAIADOJl+ Date: Thu, 15 Mar 2012 04:51:09 +0000 Message-ID: References: , <1331613507.23822.6.camel@tachyon> In-Reply-To: <1331613507.23822.6.camel@tachyon> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, toby.moncaster@cl.cam.ac.uk Subject: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding comparison 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, 15 Mar 2012 04:51:18 -0000 Hi Steve, I do not object to have both drafts as historic RFCs! Best regards, Georgios=20 ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Steven Blake [slbla= ke@petri-meat.com] Verzonden: dinsdag 13 maart 2012 5:38 Aan: David Harrington CC: ; Onderwerp: Re: [PCN] IESG feedback from 3-in-1 encoding/ encoding compariso= n On Mon, 2012-03-12 at 20:10 -0400, David Harrington wrote: > Hi, > > I hope I parsed your double negatives appropriately. > I was suggesting that having a normative reference to an expired draft > could be problematic. > > I see that one of the drafts was revised as Historic . > Is the WG decision to publish these as Historic or let them disappear? > The IESG needs to know. I thought RFCs were re-categorized as Historic? I didn't realize that an RFC could be published as Historic right off the bat. I'm initiating a 3-day WGLC to determine whether to publish draft-ietf-pcn-psdm-encoding-02.txt and draft-ietf-pcn-3-state-encoding-02.txt as Informational/Historic RFCs (terminating EOB Thursday 3/15). Please send comments to the list ASAP. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From karagian@cs.utwente.nl Wed Mar 14 21:58:53 2012 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 4D05021F8673 for ; Wed, 14 Mar 2012 21:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.054 X-Spam-Level: X-Spam-Status: No, score=0.054 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcKwxBf9WUMB for ; Wed, 14 Mar 2012 21:58:52 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 82B0121F866C for ; Wed, 14 Mar 2012 21:58:52 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 15 Mar 2012 05:58:55 +0100 Received: from EXMBX08.ad.utwente.nl ([169.254.8.70]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Thu, 15 Mar 2012 05:58:50 +0100 From: To: , Thread-Topic: [PCN] IETF 83 ***DRAFT*** agenda Thread-Index: AQHNAiuK8SmOwDFs40ilCN5cjhpxcJZqyrNe Date: Thu, 15 Mar 2012 04:58:49 +0000 Message-ID: References: <4786a7da399ebc765e88e0d07f850f08@petri-meat.com> In-Reply-To: <4786a7da399ebc765e88e0d07f850f08@petri-meat.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] IETF 83 ***DRAFT*** 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: Thu, 15 Mar 2012 04:58:53 -0000 Hi Steve, The draft-tsvwg-rsvp-pcn-01 is now a tsvwg working group draft that will be= presented/discussed during the tsvwg meeting. I assume that all pcn partic= ipants will attend the tsvwg meeting.=20 Therefore, I do not see the need on having a time slot in the pcn meeting.= =20 Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Steven Blake [slbla= ke@petri-meat.com] Verzonden: woensdag 14 maart 2012 22:43 Aan: pcn@ietf.org Onderwerp: [PCN] IETF 83 ***DRAFT*** agenda Hi, I just uploaded a draft agenda for the PCN meeting in Paris. http://www.ietf.org/proceedings/83/agenda/agenda-83-pcn.txt Comments welcome. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From ietfdbh@comcast.net Thu Mar 15 10:14:18 2012 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 E750C21F869E for ; Thu, 15 Mar 2012 10:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HkPa6IvLtUy for ; Thu, 15 Mar 2012 10:14:18 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id BD20A21F869A for ; Thu, 15 Mar 2012 10:14:17 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta06.westchester.pa.mail.comcast.net with comcast id lt791i0020bG4ec56tEJ6M; Thu, 15 Mar 2012 17:14:18 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta03.westchester.pa.mail.comcast.net with comcast id ltEH1i00k3Ecudz3PtEHel; Thu, 15 Mar 2012 17:14:18 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 15 Mar 2012 13:14:15 -0400 From: David Harrington To: "" Message-ID: Thread-Topic: 3-in-1 document Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [PCN] 3-in-1 document 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, 15 Mar 2012 17:14:19 -0000 Hi, The IESG has a few questions. 1) Since the edge behaviors have now been moved to Experimental, and 3-in-1 deals with the edge behaviors, should 3-in-1 also be Experimental? 2) (for additional information to help IESG understand) Has 3-in-1 been implemented? Has it been used in real-world environments? Should this be published as Experimental until it is clear it works? 3) if RFC5696 has become not recommended, should it be declared historic, possibly independent of the status of the 3-in-1 draft? -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 From philip.eardley@bt.com Thu Mar 15 10:35:24 2012 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 E47DB21F8724 for ; Thu, 15 Mar 2012 10:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.422 X-Spam-Level: X-Spam-Status: No, score=-103.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KIDxfVgJDUk for ; Thu, 15 Mar 2012 10:35:24 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35321F8718 for ; Thu, 15 Mar 2012 10:35:20 -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.213.0; Thu, 15 Mar 2012 17:35:19 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Thu, 15 Mar 2012 17:35:19 +0000 From: To: , Date: Thu, 15 Mar 2012 17:35:18 +0000 Thread-Topic: 3-in-1 document Thread-Index: Ac0CzxEfKiK+e13xTG60F+NSuYnGLQAAJj1Q Message-ID: <9510D26531EF184D9017DF24659BB87F331D315FE2@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: 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 document 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, 15 Mar 2012 17:35:25 -0000 Couple of quick comments: On 1) I seem to remember that when RFC5696 was published, there was discussion ab= out the status of this & it was agreed it should be standards track. Since = 3-in-1 replaces 5696, it too should be standards track. http://tools.ietf.org/html/draft-ietf-pcn-encoding-comparison-09#section-5 = explains how we got to 3-in-1 replacing 5696.=20 Incidentally, the edge behaviours moved from Informational to Experimental = (not from standards track to experimental), so I don't see why this should = prompt any change in status of 3-in-1. On 3) 3-in-1 obsoletes rfc5696. If the normal practice is to declare obsoleted rf= cs historic, then suggest we do that; if not, then don't. If the 3-in-1 draft is not approved then rfc5696 is not obsolete. If the 3-in-1 draft is experimental then rfc5696 is not obsolete - i think = the 3-in-1 draft needs to be re-written as an extension of the baseline (an= d incidentally this is very probably non-trivial to write & non-trivial for= the reader to understand) Best wishes phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of David= Harrington Sent: 15 March 2012 17:14 To: Subject: [PCN] 3-in-1 document Hi, The IESG has a few questions. 1) Since the edge behaviors have now been moved to Experimental, and 3-in-1 deals with the edge behaviors, should 3-in-1 also be Experimental? 2) (for additional information to help IESG understand) Has 3-in-1 been implemented? Has it been used in real-world environments? Should this be published as Experimental until it is clear it works? 3) if RFC5696 has become not recommended, should it be declared historic, possibly independent of the status of the 3-in-1 draft? -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From tm444@hermes.cam.ac.uk Thu Mar 15 10:39:41 2012 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 2BAD521F85DA for ; Thu, 15 Mar 2012 10:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0agOZjYcitD for ; Thu, 15 Mar 2012 10:39:40 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA9221F85AF for ; Thu, 15 Mar 2012 10:39:19 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:59237) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1S8Edx-0001aC-sZ (Exim 4.72) (return-path ); Thu, 15 Mar 2012 17:39:17 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Toby Moncaster In-Reply-To: Date: Thu, 15 Mar 2012 17:39:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <75A8E937-3CA8-47AD-9D16-CAEF55AD3296@cl.cam.ac.uk> References: To: David Harrington X-Mailer: Apple Mail (2.1257) Sender: "T. Moncaster" Cc: "" Subject: Re: [PCN] 3-in-1 document 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, 15 Mar 2012 17:39:41 -0000 On 15 Mar 2012, at 17:14, David Harrington wrote: > Hi, >=20 > The IESG has a few questions. >=20 > 1) Since the edge behaviors have now been moved to Experimental, and > 3-in-1 deals with the edge behaviors, should 3-in-1 also be = Experimental? Before I say anything else can I challenge your sentence: 3-in-1 does = not deal with the edge behaviours, it's the other way round. 3-in-1 = deals with how PCN marks are conveyed between the pcn-nodes and the = pcn-egress-nodes. The edge behaviours are about what the PCN system does = with those marks.=20 With that in mind I STRONGLY feel 3-in-1 should remain as standards = track. The aim of having the 2 edge behaviours as experimental (I = believe) is to establish which is best (and as Phil says, they were = intended to be informational). a) we will have to make it standards track when/if one of the edge = behaviours succeeds b) To make 3-in-1 experimental will require extensive re-writing. It has = already been through the pain of us deciding that to make it workable it = has to obsolete RFC5696. If we have it as experimental, then it is an = experiment that is incompatible with the current standard (RFC5696) and = so we have to require anyone running any form of PCN to NOT follow a = current standard, and instead implement another experiment - messy at = best, and definitely confusing. c) Architecturally, the encoding is a fundamental building block, as are = the marking and metering (RFC5670). The edge behaviours are applications = of the fundamental blocks=85=20 >=20 > 2) (for additional information to help IESG understand) Has 3-in-1 = been > implemented? Has it been used in real-world environments? Should this = be > published as Experimental until it is clear it works? In what way could it NOT work? This isn't all that difficult=85 The only = issues are what happens when an implementor fails to correctly implement = the standard. Frankly, that is out of the remit of the IETF - we have = designed this to be safe in every possible misconfiguration, so I can't = see that an experiment can show anything... >=20 >=20 > 3) if RFC5696 has become not recommended, should it be declared = historic, > possibly independent of the status of the 3-in-1 draft? Its status HAS to depend on that of the 3-in-1. If it is to become = historic (as opposed to obsolete) then, in the absence of 3-in-1 being a = standard we end up with PCN having NO encoding (given experimental = carries no weight).=20 I applaud the IESG trying to control the number of RFCs in the standards = track, but the main point of control has to be in the chartering of the = working groups. Toby >=20 >=20 > -- > David Harrington > Director, Transport Area > Internet Engineering Task Force (IETF) > Ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From presnick@qualcomm.com Thu Mar 15 13:14:45 2012 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 5E32D21E8017 for ; Thu, 15 Mar 2012 13:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7f5xe7S70lB for ; Thu, 15 Mar 2012 13:14:44 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 43D1B21E8014 for ; Thu, 15 Mar 2012 13:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331842459; x=1363378459; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F624D96.7070802@qualcomm.com>|Date:=20Th u,=2015=20Mar=202012=2015:14:14=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Toby=20Moncaster=20|CC:=20David=20Harrington=20,=20|Subject:=20Re:=20[PCN]=203-i n-1=20document|References:=20=20<75A8E937-3CA8-47AD-9D16-CAEF55AD3296@cl.cam.a c.uk>|In-Reply-To:=20<75A8E937-3CA8-47AD-9D16-CAEF55AD329 6@cl.cam.ac.uk>|Content-Type:=20text/plain=3B=20charset =3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=SnsffFFLFT7IzF6vT8S6UOsggmlrVFNTka4BmkomR0I=; b=qvy9fvsEwEl+shTIjf4IgbvtU84/gNGbUvuMcLUFEbChK7iQeEJ8jJ+R UTYosaUKdLa3MZYAVDF313yn6G7Ryu7FmJQJhcmDI0xuW1dSjAcJNe8hp S4/oUrNFnQBGmg1JhRIsa9Dme9Ap+/Zpl04ykJD5xM4Kwkjuozrc88mrv o=; X-IronPort-AV: E=McAfee;i="5400,1158,6650"; a="170570878" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 15 Mar 2012 13:14:18 -0700 X-IronPort-AV: E=Sophos;i="4.73,591,1325491200"; d="scan'208";a="119731530" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 15 Mar 2012 13:14:18 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 15 Mar 2012 13:14:17 -0700 Message-ID: <4F624D96.7070802@qualcomm.com> Date: Thu, 15 Mar 2012 15:14:14 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Toby Moncaster References: <75A8E937-3CA8-47AD-9D16-CAEF55AD3296@cl.cam.ac.uk> In-Reply-To: <75A8E937-3CA8-47AD-9D16-CAEF55AD3296@cl.cam.ac.uk> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Thu, 15 Mar 2012 13:20:24 -0700 Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1 document 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, 15 Mar 2012 20:14:45 -0000 Hi Toby, Being one of the IESG folks that asked the question, I have a couple of followup questions/comments. Other IESG members may^h^h^h almost certainly do have different thoughts than I :-) , but this discussion helps my thinking a lot. On 3/15/12 12:39 PM, Toby Moncaster wrote: > ...I STRONGLY feel 3-in-1 should remain as standards track. The aim of having the 2 edge behaviours as experimental (I believe) is to establish which is best (and as Phil says, they were intended to be informational). > OK, this was an important point that I didn't understand, and I do think it needs a mention in the two experimental documents: You are saying that the experiment is about picking which of the two should be used. That's not clear in those two documents now, and a little text would help greatly. That cleanly separates the issue of the status of the 3-in-1 document from the other two. > a) we will have to make it standards track when/if one of the edge behaviours succeeds > Interesting. And on this point: The WG believes ("proposed") that the approach in 3-in-1 is the correct approach ("standard"), and will be, whichever of the two experimental documents turns out to be used, correct? That would make me very comfortable with Proposed Standard. > b) To make 3-in-1 experimental will require extensive re-writing. It has already been through the pain of us deciding that to make it workable it has to obsolete RFC5696. If we have it as experimental, then it is an experiment that is incompatible with the current standard (RFC5696) and so we have to require anyone running any form of PCN to NOT follow a current standard, and instead implement another experiment - messy at best, and definitely confusing. > So, let me skip down to question 3, because on this point I think there is some confusion: > 3) if RFC5696 has become not recommended, should it be declared historic, > possibly independent of the status of the 3-in-1 draft? > > Its status HAS to depend on that of the 3-in-1. If it is to become historic (as opposed to obsolete) then, in the absence of 3-in-1 being a standard we end up with PCN having NO encoding (given experimental carries no weight). So, the question was slightly different from my perspective: Let's make believe that the 3-in-1 effort has not yet started. Is the current use of PCN in 5696 a bad idea? Should people not be doing it at all and should just wait for a new way to do it? If so, then making 5696 Historic (independent of what is to be done with 3-in-1) is the right thing to do. If the answer is, no, people are quite reasonable to continue to use 5696 until 3-in-1 gets out the door, at which point we think 3-in-1 is the better thing to do, then I think I agree with your assessment. > I applaud the IESG trying to control the number of RFCs in the standards track, but the main point of control has to be in the chartering of the working groups. So here's the funny thing: I am someone who thinks that we make too many things Experimental (or worse, BCP) and that *more* of our work belongs on the Standards Track (and progressed!). The only confusion for me (and I suspect others) was why the -sm and -cl documents were experiments, and that led to my questions about the 3-in-1 document. If what you say is correct (that the experiment is to decide between -sm and -cl), I think that clarifies the other question quite well. I'm a big proponent of having the WG (and the IETF writ large) decide how these things should go, but it's the IESG's responsibility to make sure that we all understand the basis on which the decision is made and that there's consensus on that. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From tm444@hermes.cam.ac.uk Thu Mar 15 13:48:35 2012 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 4948621E8025 for ; Thu, 15 Mar 2012 13:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+gAIRygXP+7 for ; Thu, 15 Mar 2012 13:48:34 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 174A421E8014 for ; Thu, 15 Mar 2012 13:48:34 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49889) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:tm444) id 1S8Hb3-0001hn-ZL (Exim 4.72) (return-path ); Thu, 15 Mar 2012 20:48:30 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:tm444) id 1S8Hb3-0001fB-TM (Exim 4.67) (return-path ); Thu, 15 Mar 2012 20:48:29 +0000 Received: from [128.232.235.161] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 15 Mar 2012 20:48:29 +0000 Date: 15 Mar 2012 20:48:29 +0000 From: Toby Moncaster To: Pete Resnick Message-ID: In-Reply-To: <4F624D96.7070802@qualcomm.com> References: <75A8E937-3CA8-47AD-9D16-CAEF55AD3296@cl.cam.ac.uk> <4F624D96.7070802@qualcomm.com> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: "T. Moncaster" Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1 document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: toby.moncaster@cl.cam.ac.uk List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:48:35 -0000 On Mar 15 2012, Pete Resnick wrote: >Hi Toby, > >Being one of the IESG folks that asked the question, I have a couple of >followup questions/comments. Other IESG members may^h^h^h almost >certainly do have different thoughts than I :-) , but this discussion >helps my thinking a lot. > >On 3/15/12 12:39 PM, Toby Moncaster wrote: > >> ...I STRONGLY feel 3-in-1 should remain as standards track. The aim of >> having the 2 edge behaviours as experimental (I believe) is to establish >> which is best (and as Phil says, they were intended to be >> informational). >> > >OK, this was an important point that I didn't understand, and I do think >it needs a mention in the two experimental documents: You are saying >that the experiment is about picking which of the two should be used. >That's not clear in those two documents now, and a little text would >help greatly. That cleanly separates the issue of the status of the >3-in-1 document from the other two. I have always believed that PCN is designed in a modular fashion. We have a set of core concepts (metering, marking, encoding), an architecture and then 2 possible approaches for edge behaviours. So on that basis, yes, the status of this encoding is a separate issue to the status of the edge behaviours > >> a) we will have to make it standards track when/if one of the edge >> behaviours succeeds >> > >Interesting. And on this point: The WG believes ("proposed") that the >approach in 3-in-1 is the correct approach ("standard"), and will be, >whichever of the two experimental documents turns out to be used, >correct? That would make me very comfortable with Proposed Standard. That is my understanding of why it was decided to move the two edge behaviours to experimental - however I would have to defer to Tom to confirm or deny that > >> b) To make 3-in-1 experimental will require extensive re-writing. It >> has already been through the pain of us deciding that to make it >> workable it has to obsolete RFC5696. If we have it as experimental, then >> it is an experiment that is incompatible with the current standard >> (RFC5696) and so we have to require anyone running any form of PCN to >> NOT follow a current standard, and instead implement another experiment >> - messy at best, and definitely confusing. >> > >So, let me skip down to question 3, because on this point I think there >is some confusion: > >> 3) if RFC5696 has become not recommended, should it be declared historic, >> possibly independent of the status of the 3-in-1 draft? >> >> Its status HAS to depend on that of the 3-in-1. If it is to become >> historic (as opposed to obsolete) then, in the absence of 3-in-1 being a >> standard we end up with PCN having NO encoding (given experimental >> carries no weight). > >So, the question was slightly different from my perspective: Let's make >believe that the 3-in-1 effort has not yet started. Is the current use >of PCN in 5696 a bad idea? Should people not be doing it at all and >should just wait for a new way to do it? If so, then making 5696 >Historic (independent of what is to be done with 3-in-1) is the right >thing to do. RFC5696 is the only reasonable approach in the world that existed before RFC6040 became a draft standard. It was designed to work (and so still does work), but it has the major issue of preventing the CL edge behaviour from becoming a standard. Now that RFC6040 has been published we believe that the new encoding is a better option. It is a complete superset of RFC5696, it takes advantage of the new tunneling rules, it is "safe" and it allows CL to be a viable edge behaviour. We believe (based on simulations) that SM performs significantly less well than CL. However SM has a lower implementation barrier for vendors... > >If the answer is, no, people are quite reasonable to continue to use >5696 until 3-in-1 gets out the door, at which point we think 3-in-1 is >the better thing to do, then I think I agree with your assessment. I would certainly be happy for RFC5696 to continue until 3-in-1 is published - the original intent was to have them co-existing, but during the process of refining 3-in-1 we actually realised that they can't co-exist after all. > >> I applaud the IESG trying to control the number of RFCs in the >> standards track, but the main point of control has to be in the >> chartering of the working groups. > >So here's the funny thing: I am someone who thinks that we make too many >things Experimental (or worse, BCP) and that *more* of our work belongs >on the Standards Track (and progressed!). The only confusion for me (and >I suspect others) was why the -sm and -cl documents were experiments, >and that led to my questions about the 3-in-1 document. If what you say >is correct (that the experiment is to decide between -sm and -cl), I >think that clarifies the other question quite well. I'm a big proponent >of having the WG (and the IETF writ large) decide how these things >should go, but it's the IESG's responsibility to make sure that we all >understand the basis on which the decision is made and that there's >consensus on that. That sounds a very sensible view. I am certainly not a fan of the idea that you make something experimental as a sort of back-door to getting it to RFC. Toby > >pr > > From tom.taylor.stds@gmail.com Thu Mar 15 17:08:44 2012 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 3916821E8051 for ; Thu, 15 Mar 2012 17:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyOLZbG4RNtG for ; Thu, 15 Mar 2012 17:08:43 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0F4221E804C for ; Thu, 15 Mar 2012 17:08:43 -0700 (PDT) Received: by dakl33 with SMTP id l33so6125645dak.31 for ; Thu, 15 Mar 2012 17:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=1R8n3NPw1bm1GTD2iyD5ppTW2rvn0cW2co3ytJs9c2s=; b=Z36atJXkIrglyfSEfk/wGQpe8ewiL7XbncIKuQQ2UI5t0NkbLj18XcwloukW0uGvWY ZTAThLAKqr5zkIe4DSHVhtVHT6cvD+y99qmDCinf1AjlP2rkW4iOvfWtzJk2ih7vD7/6 10iYAzJUDSEhZe7zz3cMQ40Hk0I55jmUp0Gsn9z9RNozOpc76Bg3qKQeYfJKGz3kyG6o srGnOhJFO/HYzjGYKxtFxdqv929i3Yi8itP1K+ZZnjzSc7MRBPp0Ir6ySrBKtu4JSQUt shFCqd4ELLbodZA6We+6tseZ90BhR6g0hMFiJQ8G4KfuHxjSmWzCkHe0KIXTSdia6Hqd 3j8Q== Received: by 10.68.135.38 with SMTP id pp6mr8884490pbb.82.1331856523496; Thu, 15 Mar 2012 17:08:43 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id l4sm2918468pbl.27.2012.03.15.17.08.42 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 17:08:42 -0700 (PDT) Message-ID: <4F628489.8010605@gmail.com> Date: Thu, 15 Mar 2012 20:08:41 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: toby.moncaster@cl.cam.ac.uk References: <75A8E937-3CA8-47AD-9D16-CAEF55AD3296@cl.cam.ac.uk> <4F624D96.7070802@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120315-1, 15/03/2012), Outbound message X-Antivirus-Status: Clean Cc: Pete Resnick , pcn@ietf.org Subject: Re: [PCN] 3-in-1 document 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: Fri, 16 Mar 2012 00:08:44 -0000 I think the experiment is to choose between the two behaviours. I never previously thought of it that way because the set of potential edge behaviours was supposed to be open-ended, but these two are what we have ended up with for the moment at least. On 15/03/2012 4:48 PM, Toby Moncaster wrote: > On Mar 15 2012, Pete Resnick wrote: > >> Hi Toby, >> >> Being one of the IESG folks that asked the question, I have a couple >> of followup questions/comments. Other IESG members may^h^h^h almost >> certainly do have different thoughts than I :-) , but this discussion >> helps my thinking a lot. >> >> On 3/15/12 12:39 PM, Toby Moncaster wrote: >> >>> ...I STRONGLY feel 3-in-1 should remain as standards track. The aim >>> of having the 2 edge behaviours as experimental (I believe) is to >>> establish which is best (and as Phil says, they were intended to be >>> informational). >> >> OK, this was an important point that I didn't understand, and I do >> think it needs a mention in the two experimental documents: You are >> saying that the experiment is about picking which of the two should be >> used. That's not clear in those two documents now, and a little text >> would help greatly. That cleanly separates the issue of the status of >> the 3-in-1 document from the other two. > > I have always believed that PCN is designed in a modular fashion. We > have a set of core concepts (metering, marking, encoding), an > architecture and then 2 possible approaches for edge behaviours. So on > that basis, yes, the status of this encoding is a separate issue to the > status of the edge behaviours > >> >>> a) we will have to make it standards track when/if one of the edge >>> behaviours succeeds >> >> Interesting. And on this point: The WG believes ("proposed") that the >> approach in 3-in-1 is the correct approach ("standard"), and will be, >> whichever of the two experimental documents turns out to be used, >> correct? That would make me very comfortable with Proposed Standard. > > That is my understanding of why it was decided to move the two edge > behaviours to experimental - however I would have to defer to Tom to > confirm or deny that > >> ... From ietfdbh@comcast.net Thu Mar 15 20:01:55 2012 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 BEEC921E803C for ; Thu, 15 Mar 2012 20:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.28 X-Spam-Level: X-Spam-Status: No, score=-102.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biTI7heM+Und for ; Thu, 15 Mar 2012 20:01:55 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id E6C9E21E8043 for ; Thu, 15 Mar 2012 20:01:54 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta04.westchester.pa.mail.comcast.net with comcast id m2zq1i0060QuhwU5431v6i; Fri, 16 Mar 2012 03:01:55 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta02.westchester.pa.mail.comcast.net with comcast id m31n1i00G3Ecudz3N31u2l; Fri, 16 Mar 2012 03:01:55 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 15 Mar 2012 23:01:45 -0400 From: David Harrington To: Tom Taylor , Message-ID: Thread-Topic: [PCN] 3-in-1 document In-Reply-To: <4F628489.8010605@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1 document 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: Fri, 16 Mar 2012 03:01:55 -0000 Hi, Is the goal to choose between the two and only standardize one? I was of the impression both might be standardized and the choice was a deployment decision based on environmental considerations. Was I wrong on that point? -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/15/12 8:08 PM, "Tom Taylor" wrote: >I think the experiment is to choose between the two behaviours. I never >previously thought of it that way because the set of potential edge >behaviours was supposed to be open-ended, but these two are what we have >ended up with for the moment at least. > >On 15/03/2012 4:48 PM, Toby Moncaster wrote: >> On Mar 15 2012, Pete Resnick wrote: >> >>> Hi Toby, >>> >>> Being one of the IESG folks that asked the question, I have a couple >>> of followup questions/comments. Other IESG members may^h^h^h almost >>> certainly do have different thoughts than I :-) , but this discussion >>> helps my thinking a lot. >>> >>> On 3/15/12 12:39 PM, Toby Moncaster wrote: >>> >>>> ...I STRONGLY feel 3-in-1 should remain as standards track. The aim >>>> of having the 2 edge behaviours as experimental (I believe) is to >>>> establish which is best (and as Phil says, they were intended to be >>>> informational). >>> >>> OK, this was an important point that I didn't understand, and I do >>> think it needs a mention in the two experimental documents: You are >>> saying that the experiment is about picking which of the two should be >>> used. That's not clear in those two documents now, and a little text >>> would help greatly. That cleanly separates the issue of the status of >>> the 3-in-1 document from the other two. >> >> I have always believed that PCN is designed in a modular fashion. We >> have a set of core concepts (metering, marking, encoding), an >> architecture and then 2 possible approaches for edge behaviours. So on >> that basis, yes, the status of this encoding is a separate issue to the >> status of the edge behaviours >> >>> >>>> a) we will have to make it standards track when/if one of the edge >>>> behaviours succeeds >>> >>> Interesting. And on this point: The WG believes ("proposed") that the >>> approach in 3-in-1 is the correct approach ("standard"), and will be, >>> whichever of the two experimental documents turns out to be used, >>> correct? That would make me very comfortable with Proposed Standard. >> >> That is my understanding of why it was decided to move the two edge >> behaviours to experimental - however I would have to defer to Tom to >> confirm or deny that >> >>> >... >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Fri Mar 16 00:39:41 2012 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 6650B21F8638 for ; Fri, 16 Mar 2012 00:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC7uROGAzEsu for ; Fri, 16 Mar 2012 00:39:40 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id F0B9921F85B8 for ; Fri, 16 Mar 2012 00:39:39 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 16 Mar 2012 08:39:37 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.76]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 16 Mar 2012 08:39:34 +0100 From: To: Date: Fri, 16 Mar 2012 08:39:33 +0100 Thread-Topic: [PCN] 3-in-1 document Thread-Index: Ac0DISfxfbi44NSnTq2ptrm7Kt6TAwAJQeZQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A42F1E7E@HE111648.emea1.cds.t-internal.com> References: <4F628489.8010605@gmail.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1 document 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: Fri, 16 Mar 2012 07:39:41 -0000 Hi Dave, you are correct. Am MPLS domain probably is not able to spend more than one= codepoint for ECN/PCN functions. That's why SM behaviours remain to be useful. In pur= e IP domains, CL may be used. My understanding of all that is that the edge behaviours are experimental, = as they involve signaling, policy decisions and so on. Complexity, if you want. The marking behaviour specified by 3-in-1 is simpler and I agree with other= s, this can be implemented and it should be implemented the way specified. To me, 3= -in-1 is a building block which can be used even if the edge behaviours see no imple= mentation at all. That of course would require different standardised edge or end sys= tem behaviours (the paket markings need to be interpreted correctly). The edge behaviours contain useful and important information besides signal= ing and policy decisions. So I think parts of what's specified there is useful, eve= n if they are never deployed. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of David= Harrington Sent: Friday, March 16, 2012 4:02 AM To: Tom Taylor; toby.moncaster@cl.cam.ac.uk Cc: pcn@ietf.org Subject: Re: [PCN] 3-in-1 document Hi, Is the goal to choose between the two and only standardize one? I was of the impression both might be standardized and the choice was a deployment decision based on environmental considerations. Was I wrong on that point? -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/15/12 8:08 PM, "Tom Taylor" wrote: >I think the experiment is to choose between the two behaviours. I never >previously thought of it that way because the set of potential edge >behaviours was supposed to be open-ended, but these two are what we have >ended up with for the moment at least. > >On 15/03/2012 4:48 PM, Toby Moncaster wrote: >> On Mar 15 2012, Pete Resnick wrote: >> >>> Hi Toby, >>> >>> Being one of the IESG folks that asked the question, I have a couple >>> of followup questions/comments. Other IESG members may^h^h^h almost >>> certainly do have different thoughts than I :-) , but this discussion >>> helps my thinking a lot. >>> >>> On 3/15/12 12:39 PM, Toby Moncaster wrote: >>> >>>> ...I STRONGLY feel 3-in-1 should remain as standards track. The aim >>>> of having the 2 edge behaviours as experimental (I believe) is to >>>> establish which is best (and as Phil says, they were intended to be >>>> informational). >>> >>> OK, this was an important point that I didn't understand, and I do >>> think it needs a mention in the two experimental documents: You are >>> saying that the experiment is about picking which of the two should be >>> used. That's not clear in those two documents now, and a little text >>> would help greatly. That cleanly separates the issue of the status of >>> the 3-in-1 document from the other two. >> >> I have always believed that PCN is designed in a modular fashion. We >> have a set of core concepts (metering, marking, encoding), an >> architecture and then 2 possible approaches for edge behaviours. So on >> that basis, yes, the status of this encoding is a separate issue to the >> status of the edge behaviours >> >>> >>>> a) we will have to make it standards track when/if one of the edge >>>> behaviours succeeds >>> >>> Interesting. And on this point: The WG believes ("proposed") that the >>> approach in 3-in-1 is the correct approach ("standard"), and will be, >>> whichever of the two experimental documents turns out to be used, >>> correct? That would make me very comfortable with Proposed Standard. >> >> That is my understanding of why it was decided to move the two edge >> behaviours to experimental - however I would have to defer to Tom to >> confirm or deny that >> >>> >... >_______________________________________________ >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 bob.briscoe@bt.com Sun Mar 18 17:01:55 2012 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 00C0D21F8551 for ; Sun, 18 Mar 2012 17:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=-0.858, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nk1YgGbCieSx for ; Sun, 18 Mar 2012 17:01:54 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id F1BC721F8546 for ; Sun, 18 Mar 2012 17:01:53 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Mar 2012 00:01:52 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Mar 2012 00:01:51 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.1.323.0; Mon, 19 Mar 2012 00:01:49 +0000 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 1332115310261; Mon, 19 Mar 2012 00:01:50 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.144.16]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2J01laA014397 for ; Mon, 19 Mar 2012 00:01:48 GMT Message-ID: <201203190001.q2J01laA014397@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Mar 2012 00:01:46 +0000 To: PCN IETF list From: Bob Briscoe MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [PCN] How to implement a virtual queue with current hardware 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, 19 Mar 2012 00:01:55 -0000 PCN list, Implementers might be interested in this tech report we've just published. It describes how to implement a virtual queue using existing hardware. How to Build a Virtual Queue from Two Leaky Buckets (and why one is not enough) Abstract: A virtual queue can be used to predict when a real queue is about to grow. This memo explains why using a leaky bucket to implement a virtual queue is not useful, despite a superficial similarity. However, it is possible to implement a useful virtual queue using two leaky buckets. It requires a simple trick that can typically be implemented with existing hardware. Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From slblake@petri-meat.com Sun Mar 18 20:11:13 2012 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 1CC7C21F858E for ; Sun, 18 Mar 2012 20:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.983 X-Spam-Level: X-Spam-Status: No, score=-100.983 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7KIZzl4H8R1 for ; Sun, 18 Mar 2012 20:11:12 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 46AC621F858A for ; Sun, 18 Mar 2012 20:11:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=IuoOftqmnPxAo/th3hIQP5DUWx4cFe2nktyWpXi+q9THjTKEgX+2uxXDga9NGjJqMpvSGXxByDrSEdUNFf3Kqv4aMBew7krdXaz3csnGciWwpwveDMEpdxasuJCBnTZ1; Received: from cpe-071-065-228-004.nc.res.rr.com ([71.65.228.4]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S9T03-0005wi-1R; Sun, 18 Mar 2012 23:11:11 -0400 From: Steven Blake To: David Harrington Date: Sun, 18 Mar 2012 23:11:09 -0400 In-Reply-To: <1331613507.23822.6.camel@tachyon> References: <1331613507.23822.6.camel@tachyon> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1332126671.19389.13.camel@tachyon> Mime-Version: 1.0 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: "" Subject: [PCN] WGLC concluded (publishing PSDM and 3-state encoding drafts) 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, 19 Mar 2012 03:11:13 -0000 Greetings, I've tallyed up the comments on the WGLC to publish draft-ietf-pcn-psdm-encoding-02.txt and draft-ietf-pcn-3-state-encoding-02.txt as Historical RFCs. By my count (excluding the chairs): - one comment for publishing - one comment against publishing - three comments that are essentially "no objection". That is not enough input to determine WG consensus either way. Given the non-zero effort required of the IESG and RFC Editor to get these published, and the lack of consensus to publish, my determination is that pcn *will not* request that these drafts be published. Regards, // Steve From iesg-secretary@ietf.org Mon Mar 19 15:39:06 2012 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 611F721F8852; Mon, 19 Mar 2012 15:39:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je5JCtA6c3-3; Mon, 19 Mar 2012 15:39:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F62E21E8048; Mon, 19 Mar 2012 15:39:05 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120319223905.16799.40025.idtracker@ietfa.amsl.com> Date: Mon, 19 Mar 2012 15:39:05 -0700 Cc: pcn mailing list , pcn chair , RFC Editor Subject: [PCN] Document Action: 'Overview of Pre-Congestion Notification Encoding' to Informational RFC (draft-ietf-pcn-encoding-comparison-09.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, 19 Mar 2012 22:39:06 -0000 The IESG has approved the following document: - 'Overview of Pre-Congestion Notification Encoding' (draft-ietf-pcn-encoding-comparison-09.txt) as an Informational RFC This document is the product of the Congestion and Pre-Congestion Notification Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcn-encoding-comparison/ Technical Summary The PCN mechanism in routers in the interior of a PCN domain marks packets when certain configured rates are exceeded. The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document describes the various approaches that were examined and discusses the constraints that had to be satisfied by a viable encoding mechanism. Working Group Summary The document was subject to thorough review by the PCN working group, and strong consensus for publication was reached. Document Quality The document was subject to thorough review by the PCN working group, and strong consensus for publication was reached. There are a number of companion documents that detail the specific approaches. Personnel Document Shepherd: Steven Blake Responsible Area Director: David Harrington RFC Editor Note 4.5 says RFC5696 was published as a draft Internet Standard. This is confusing, given the existence of the "Draft Internet Standard" status. RFC5696 is a Proposed Standard. Please reword to: "The baseline encoding described in section 4.1 is defined in [RFC5696]." From sob@harvard.edu Tue Mar 20 09:37:11 2012 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 9B6F621F8702 for ; Tue, 20 Mar 2012 09:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.191 X-Spam-Level: X-Spam-Status: No, score=-102.191 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECQMsFWLuk1Z for ; Tue, 20 Mar 2012 09:37:11 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id D66D221F8701 for ; Tue, 20 Mar 2012 09:37:10 -0700 (PDT) Received: from exchange.university.harvard.edu (unknown [10.35.2.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 901EDE8FFD for ; Tue, 20 Mar 2012 12:37:10 -0400 (EDT) Received: from ENTWHUBT0000002.university.harvard.edu (192.168.36.23) by ENTWEDGE0000000.university.harvard.edu (10.35.2.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 12:36:42 -0400 Received: from ENTWEXMB0000004.university.harvard.edu ([169.254.3.128]) by entwhubt0000002.university.harvard.edu ([192.168.36.46]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 12:37:02 -0400 From: "Bradner, Scott" To: "pcn@ietf.org" Thread-Topic: lets try again - a chair asking this time Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+w== Date: Tue, 20 Mar 2012 16:37:01 +0000 Message-ID: <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [140.247.60.212] Content-Type: text/html; charset="us-ascii" Content-ID: <0F550AD3277E5D4FA682F948966D5D94@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:37:11 -0000 please let the list know what you think


Scott

Scott O Bradner
Senior Technology Consultant


Begin forwarded message:


Date: Mon, 1= 2 Mar 2012 03:30:11 +0000
To: "PCN IETF list" <pcn@ietf.= org>
From: Bob Briscoe <bob.briscoe@bt.= com>
Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt

PCN folks,

Following IESG review (particularly Adrian Farrel's being the most comprehe= nsive and useful), we've posted a new version of the PCN 3-in-1 encoding.
As well as a number of editorial changes, some technical changes were neede= d in order to satisfy Adrian's request to specify exactly what an implement= er has to do at the ingress to allow ECN to co-exist with PCN, and what def= aults should be set to.

In particular, for a non-PCN packet (i.e. doesn't match any flow-state) tha= t clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 i= s:

      *  re-mark the DSCP to a DSCP that is n= ot PCN-compatible;


      
[...]           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           
In the
      absence of any operator-specific
configuration for this case, by
      default an implementation SHOULD re-mark
the DSCP to zero.

Actually, the whole of the ingress behaviour section (5.1) has been re-writ= ten, incorporating material that was previously repeated in both edge-behav= iours (agreed with IESG and with edge-behaviour authors, of course). Altho = it largely does the same thing technically, it is written to cover the complete range of possible scenarios, and it no= w gives defaults and recommended choices. I don't think it's controversial,= but shout if it is.
< http://tools.ietf.org/html/draft-ietf-pcn= -3-in-1-encoding-09#section-5.1 >



Bob

PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:

      *  Added note about fail-safe to protec= t other traffic in the
         event of tunnel misconfigu= ration.

      *  Changed section heading to be about = applicability of
         environments to the encodi= ng, rather than the encoding to the
         environments.

      *  Completely re-wrote PCN-ingress Node= Behaviour section.

      *  Changed PCN interior node to PCN-nod= e where the term was
         intended to include all PC= N-nodes.

      *  Clarified status of ECN/PCN co-exist= ence appendix.  Removed
         inconsistent assertion in = this appendix that an admission-
         control DSCP alone can ind= icate that arriving traffic is PCN-
         traffic.

      *  A few clarifying editorial amendment= s and updated refs.



From: <internet-drafts@ietf.org><= br> To: <pcn-chairs@tools.ietf.= org>,
        <draft-ietf-pcn-3-in-1-encoding@tools.i= etf.org>, <ietfdbh@comcast= .net>,
        <adrian@olddog.co.uk>, <rjsparks@nostrum.com>
Date: Sun, 11 Mar 2012 17:52:23 -0700
Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt
New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.= txt.
http://www.ietf.org/internet-drafts/draft-iet= f-pcn-3-in-1-encoding-09.txt


Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-= pcn-3-in-1-encoding-09

IETF Secretariat.

________________________________________________________________
Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= /blockquote>

________________________________________________________________
Bob Briscoe,          &nb= sp;            =          BT Innovate & Design


From philip.eardley@bt.com Tue Mar 20 09:46:22 2012 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 56A6321F85D5 for ; Tue, 20 Mar 2012 09:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ2mW1b8soZE for ; Tue, 20 Mar 2012 09:46:21 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E950C21F85F0 for ; Tue, 20 Mar 2012 09:46:20 -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.213.0; Tue, 20 Mar 2012 16:46:20 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 20 Mar 2012 16:46:19 +0000 From: To: , Date: Tue, 20 Mar 2012 16:46:19 +0000 Thread-Topic: lets try again - a chair asking this time Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+5ZzZAvg Message-ID: <9510D26531EF184D9017DF24659BB87F331D442A7C@EMV65-UKRD.domain1.systemhost.net> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> In-Reply-To: <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> 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_9510D26531EF184D9017DF24659BB87F331D442A7CEMV65UKRDdoma_" MIME-Version: 1.0 Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:46:22 -0000 --_000_9510D26531EF184D9017DF24659BB87F331D442A7CEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems good to me. I like the inclusion of material previously in both the e= dge behaviour docs From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Bradn= er, Scott Sent: 20 March 2012 16:37 To: pcn@ietf.org Subject: [PCN] lets try again - a chair asking this time please let the list know what you think Scott Scott O Bradner Senior Technology Consultant Begin forwarded message: Date: Mon, 12 Mar 2012 03:30:11 +0000 To: "PCN IETF list" > From: Bob Briscoe > Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt PCN folks, Following IESG review (particularly Adrian Farrel's being the most comprehe= nsive and useful), we've posted a new version of the PCN 3-in-1 encoding. As well as a number of editorial changes, some technical changes were neede= d in order to satisfy Adrian's request to specify exactly what an implement= er has to do at the ingress to allow ECN to co-exist with PCN, and what def= aults should be set to. In particular, for a non-PCN packet (i.e. doesn't match any flow-state) tha= t clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 i= s: * re-mark the DSCP to a DSCP that is not PCN-compatible; [...] In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. Actually, the whole of the ingress behaviour section (5.1) has been re-writ= ten, incorporating material that was previously repeated in both edge-behav= iours (agreed with IESG and with edge-behaviour authors, of course). Altho = it largely does the same thing technically, it is written to cover the comp= lete range of possible scenarios, and it now gives defaults and recommended= choices. I don't think it's controversial, but shout if it is. < http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 = > Bob PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: * Added note about fail-safe to protect other traffic in the event of tunnel misconfiguration. * Changed section heading to be about applicability of environments to the encoding, rather than the encoding to the environments. * Completely re-wrote PCN-ingress Node Behaviour section. * Changed PCN interior node to PCN-node where the term was intended to include all PCN-nodes. * Clarified status of ECN/PCN co-existence appendix. Removed inconsistent assertion in this appendix that an admission- control DSCP alone can indicate that arriving traffic is PCN- traffic. * A few clarifying editorial amendments and updated refs. From: > To: >, >, >, >, > Date: Sun, 11 Mar 2012 17:52:23 -0700 Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.= txt. http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09 IETF Secretariat. ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_9510D26531EF184D9017DF24659BB87F331D442A7CEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems good to me. I like the inclusion of material previously in both the= edge behaviour docs

 

= From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf= .org] On Behalf Of Bradner, Scott
Sent: 20 March 2012 16:3= 7
To: pcn@ietf.org
Subject: [PCN] lets try again - a ch= air asking this time

=  

please let the list know what you= think

 

=

Scott

 

Scott O Bradn= er

Senior Technology Consultant

<= /div>

 

Begin forwarded message:

=

 

Date: Mon, 12 Mar 2012 03:30:11= +0000
To: "PCN IETF list" <pcn@ietf.org>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: New Version: draft-ietf-pc= n-3-in-1-encoding-09.txt

PCN folks,

Following IESG review (pa= rticularly Adrian Farrel's being the most comprehensive and useful), we've = posted a new version of the PCN 3-in-1 encoding.

As well as a number= of editorial changes, some technical changes were needed in order to satis= fy Adrian's request to specify exactly what an implementer has to do at the= ingress to allow ECN to co-exist with PCN, and what defaults should be set= to.

In particular, for a non-PCN packet (i.e. doesn't match any flo= w-state) that clashes with a PCN DSCP and is ECN-capable, the recommended c= hoice of 3 is:

      *  re-mark the DS= CP to a DSCP that is not PCN-compatible;

 &=
nbsp;    
[...]   &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;       
In the=

      absence of any operato=
r-specific
configuration for this case, by<=
/pre>
      default an implementation SHOULD r=
e-mark
the DSCP to zero.
&nb=
sp;

Actually, the whole of the ingress =
behaviour section (5.1) has been re-written, incorporating material that wa=
s previously repeated in both edge-behaviours (agreed with IESG and with ed=
ge-behaviour authors, of course). Altho it largely does the same thing tech=
nically, it is written to cover the complete range of possible scenarios, a=
nd it now gives defaults and recommended choices. I don't think it's contro=
versial, but shout if it is.
< http://tools.ietf.org/html/d=
raft-ietf-pcn-3-in-1-encoding-09#section-5.1 >



Bob
PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:

&nbs=
p;     *  Added note about fail-safe to protect ot=
her traffic in the
         even=
t of tunnel misconfiguration.

      * =
 Changed section heading to be about applicability of
   =
      environments to the encoding, rather than th=
e encoding to the
         envir=
onments.

      *  Completely re-wrote =
PCN-ingress Node Behaviour section.

      *=
  Changed PCN interior node to PCN-node where the term was
 &n=
bsp;       intended to include all PCN-nodes.=


      *  Clarified status of ECN/PCN =
co-existence appendix.  Removed
      =
;   inconsistent assertion in this appendix that an admission-         control DSCP alone can in=
dicate that arriving traffic is PCN-
      =
;   traffic.

      *  A few =
clarifying editorial amendments and updated refs.




<=
/o:p>
From: <internet-drafts@ietf.org>
To: <pcn-chairs@tools.ietf.org>,
  &n=
bsp;     <draft-ietf-pcn-3-in-1-encoding@tools.ietf.org>=
;, <ietfdbh@comcast.net>,<=
br>        <adrian@olddog.co.uk>, <rjsparks@nostrum.com>
Date: Sun, 11 Mar 2012 17:52:23=
 -0700
Subject: New Version Notification - draft-ietf-pcn-3-in-1-encodin=
g-09.txt

New version (-09) has been submitted for draft-ietf-pcn-3-i=
n-1-encoding-09.txt.
http://www.ietf.org/internet-drafts/draf=
t-ietf-pcn-3-in-1-encoding-09.txt 


Diff from previous versio=
n:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-en=
coding-09 

IETF Secretariat.
=

________________________________________________________________
Bob=
 Briscoe,           =
            &nb=
sp;        BT Innovate & Design

________________________________________________= ________________
Bob Briscoe,       &= nbsp;           &nbs= p;            BT Inn= ovate & Design

&nbs= p;

= --_000_9510D26531EF184D9017DF24659BB87F331D442A7CEMV65UKRDdoma_-- From toby@moncaster.com Tue Mar 20 09:47:04 2012 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 8225821F86EB for ; Tue, 20 Mar 2012 09:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.853 X-Spam-Level: X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuF+Fcxuo6tx for ; Tue, 20 Mar 2012 09:47:03 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 69D1D21F86E4 for ; Tue, 20 Mar 2012 09:47:03 -0700 (PDT) Received: from [10.102.53.162] ([82.132.236.168]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MI6Yw-1S9UVx37T4-003y2L; Tue, 20 Mar 2012 17:47:00 +0100 References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> In-Reply-To: <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-DE14FC36-7EB6-45D0-AC94-2AD003D7CB59 Message-Id: <604B7B86-A2E8-4CA7-98D6-B59F995766FA@moncaster.com> X-Mailer: iPhone Mail (9A405) From: Toby Moncaster Date: Tue, 20 Mar 2012 16:46:50 +0000 To: "Bradner, Scott" X-Provags-ID: V02:K0:sbkdzBG5+mn806G0QFcVnHtUt5/ZqA/FjLhpfIXFwll ArSuOjQma4DiJe/UTUWTZrgR2HwTqSKZ3/mEdPJ54vHP6BW165 31lu9LWiFuxN9E2ks6N4mFp08g7/OvT4EHc7dFS4p+mvEVoV1m fo9KeCS7/MaftIwQ/QfjwCcQK3DeI/89FjzuOquiYDBtmk49RF g5FdiZgUVOEIfCxFfPoIvPj+MaTsJEDD8mXygHEQmdEYUU2Fwi LLOs0ifsgm0jeK69UJMfDSRuKH990u9PPvXR9Ky6QnBEU+HNJH /76ytlgHSIEiLvY8YBPxKmfAVdj+XLeek4cs7Y2Q454A0UvFCT Dmw3UxiNZVsJE0gXbKpCaN5e1UnGdn5sNTkisDvtUHty+XYcxa u6owYXnTteoZw== Cc: "pcn@ietf.org" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:47:04 -0000 --Apple-Mail-DE14FC36-7EB6-45D0-AC94-2AD003D7CB59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I certainly think this is now in good shape to progress (but as I'm an autho= r my opinion may be biased). Toby On 20 Mar 2012, at 16:37, "Bradner, Scott" wrote: > please let the list know what you think >=20 > Scott >=20 > Scott O Bradner > Senior Technology Consultant >=20 >=20 > Begin forwarded message: >=20 >>=20 >>> Date: Mon, 12 Mar 2012 03:30:11 +0000 >>> To: "PCN IETF list" >>> From: Bob Briscoe >>> Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt >>>=20 >>> PCN folks, >>>=20 >>> Following IESG review (particularly Adrian Farrel's being the most compr= ehensive and useful), we've posted a new version of the PCN 3-in-1 encoding.= >>>=20 >>> As well as a number of editorial changes, some technical changes were ne= eded in order to satisfy Adrian's request to specify exactly what an impleme= nter has to do at the ingress to allow ECN to co-exist with PCN, and what de= faults should be set to. >>>=20 >>> In particular, for a non-PCN packet (i.e. doesn't match any flow-state) t= hat clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 i= s: >>>=20 >>> * re-mark the DSCP to a DSCP that is not PCN-compatible; >>>=20 >>>=20 >>> =20 >>> [...] =20 >>> In the >>> absence of any operator-specific >>> configuration for this case, by >>> default an implementation SHOULD re-mark >>> the DSCP to zero. >>>=20 >>>=20 >>> Actually, the whole of the ingress behaviour section (5.1) has been re-w= ritten, incorporating material that was previously repeated in both edge-beh= aviours (agreed with IESG and with edge-behaviour authors, of course). Altho= it largely does the same thing technically, it is written to cover the comp= lete range of possible scenarios, and it now gives defaults and recommended c= hoices. I don't think it's controversial, but shout if it is. >>> < http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5= .1 > >>>=20 >>>=20 >>>=20 >>> Bob >>>=20 >>> PS. Changes =46rom draft-ietf-pcn-3-in-1-encoding-08 to -09: >>>=20 >>> * Added note about fail-safe to protect other traffic in the >>> event of tunnel misconfiguration. >>>=20 >>> * Changed section heading to be about applicability of >>> environments to the encoding, rather than the encoding to the >>> environments. >>>=20 >>> * Completely re-wrote PCN-ingress Node Behaviour section. >>>=20 >>> * Changed PCN interior node to PCN-node where the term was >>> intended to include all PCN-nodes. >>>=20 >>> * Clarified status of ECN/PCN co-existence appendix. Removed >>> inconsistent assertion in this appendix that an admission- >>> control DSCP alone can indicate that arriving traffic is PCN- >>> traffic. >>>=20 >>> * A few clarifying editorial amendments and updated refs. >>>=20 >>>=20 >>>=20 >>>> From: >>>> To: , >>>> , , >>>> , >>>> Date: Sun, 11 Mar 2012 17:52:23 -0700 >>>> Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.t= xt >>>>=20 >>>> New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding= -09.txt. >>>> http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.t= xt=20 >>>>=20 >>>>=20 >>>> Diff from previous version: >>>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09=20= >>>>=20 >>>> IETF Secretariat. >>>=20 >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design >>=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn --Apple-Mail-DE14FC36-7EB6-45D0-AC94-2AD003D7CB59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I certainly think this is n= ow in good shape to progress (but as I'm an author my opinion may be biased)= .

Toby



On 20 Mar 2012, at= 16:37, "Bradner, Scott" <sob@harvard.= edu> wrote:

= please let the list know what you think

Scott

Scott O Bradner
Senior Technology Consultant


Begin forwarded message:


Date: Mon, 12= Mar 2012 03:30:11 +0000
To: "PCN IETF list" <pcn@ietf.org>=
From: Bob Briscoe <bob.briscoe@bt.c= om>
Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt

PCN folks,

Following IESG review (particularly Adrian Farrel's being the most comprehen= sive and useful), we've posted a new version of the PCN 3-in-1 encoding.
=
As well as a number of editorial changes, some technical changes were needed= in order to satisfy Adrian's request to specify exactly what an implementer= has to do at the ingress to allow ECN to co-exist with PCN, and what defaul= ts should be set to.

In particular, for a non-PCN packet (i.e. doesn't match any flow-state) that= clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 is:=

      *  re-mark the DSCP to a DSCP that is no= t PCN-compatible;


      
[...]            =
;            &nb=
sp;            &=
nbsp;            =
;           
In the
      absence of any operator-specific
configuration for this case, by
      default an implementation SHOULD re-mark
the DSCP to zero.

Actually, the whole of the ingress behaviour section (5.1) has been re-writt= en, incorporating material that was previously repeated in both edge-behavio= urs (agreed with IESG and with edge-behaviour authors, of course). Altho it l= argely does the same thing technically, it is written to cover the complete range of possible scenarios, and it now= gives defaults and recommended choices. I don't think it's controversial, b= ut shout if it is.
< http://tools.ietf.org/html/draft-ietf-pcn-3= -in-1-encoding-09#section-5.1 >



Bob

PS. Changes =46rom draft-ietf-pcn-3-in-1-encoding-08 to -09:

      *  Added note about fail-safe to protect= other traffic in the
         event of tunnel misconfigur= ation.

      *  Changed section heading to be about a= pplicability of
         environments to the encodin= g, rather than the encoding to the
         environments.

      *  Completely re-wrote PCN-ingress Node B= ehaviour section.

      *  Changed PCN interior node to PCN-node= where the term was
         intended to include all PCN= -nodes.

      *  Clarified status of ECN/PCN co-existe= nce appendix.  Removed
         inconsistent assertion in t= his appendix that an admission-
         control DSCP alone can indi= cate that arriving traffic is PCN-
         traffic.

      *  A few clarifying editorial amendments= and updated refs.



From: <internet-drafts@ietf.org>
= To: <pcn-chairs@tools.ietf.o= rg>,
        <draft-ietf-pcn-3-in-1-encoding@tools.iet= f.org>, <ietfdbh@comcast.ne= t>,
        <adrian@olddog.co.uk>, <rjsparks@nostrum.com>
Date: Sun, 11 Mar 2012 17:52:23 -0700
Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt
New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.t= xt.
http://www.ietf.org/internet-drafts/draft-ietf-= pcn-3-in-1-encoding-09.txt


Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pc= n-3-in-1-encoding-09

IETF Secretariat.

________________________________________________________________
Bob Briscoe,          &nbs= p;            &n= bsp;        BT Innovate & Design

________________________________________________________________
Bob Briscoe,          &nbs= p;            &n= bsp;        BT Innovate & Design


____________________= ___________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/lis= tinfo/pcn
= --Apple-Mail-DE14FC36-7EB6-45D0-AC94-2AD003D7CB59-- From karagian@cs.utwente.nl Tue Mar 20 12:25:19 2012 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 028B921F85C7 for ; Tue, 20 Mar 2012 12:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvC6OD4h+l8h for ; Tue, 20 Mar 2012 12:25:18 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8591521F85B6 for ; Tue, 20 Mar 2012 12:25:16 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 20 Mar 2012 20:25:15 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.140]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Tue, 20 Mar 2012 20:25:14 +0100 From: To: , , Thread-Topic: lets try again - a chair asking this time Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+5ZzZAvggAAsj5c= Date: Tue, 20 Mar 2012 19:25:14 +0000 Message-ID: References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu>, <9510D26531EF184D9017DF24659BB87F331D442A7C@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331D442A7C@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_" MIME-Version: 1.0 Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 19:25:19 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I think that the changes satisfy nicely the comments of Adrian! Best regards, Georgios ________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens philip.eardley@bt.c= om [philip.eardley@bt.com] Verzonden: dinsdag 20 maart 2012 17:46 Aan: sob@harvard.edu; pcn@ietf.org Onderwerp: Re: [PCN] lets try again - a chair asking this time Seems good to me. I like the inclusion of material previously in both the e= dge behaviour docs From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Bradn= er, Scott Sent: 20 March 2012 16:37 To: pcn@ietf.org Subject: [PCN] lets try again - a chair asking this time please let the list know what you think Scott Scott O Bradner Senior Technology Consultant Begin forwarded message: Date: Mon, 12 Mar 2012 03:30:11 +0000 To: "PCN IETF list" > From: Bob Briscoe > Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt PCN folks, Following IESG review (particularly Adrian Farrel's being the most comprehe= nsive and useful), we've posted a new version of the PCN 3-in-1 encoding. As well as a number of editorial changes, some technical changes were neede= d in order to satisfy Adrian's request to specify exactly what an implement= er has to do at the ingress to allow ECN to co-exist with PCN, and what def= aults should be set to. In particular, for a non-PCN packet (i.e. doesn't match any flow-state) tha= t clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 i= s: * re-mark the DSCP to a DSCP that is not PCN-compatible; [...] In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. Actually, the whole of the ingress behaviour section (5.1) has been re-writ= ten, incorporating material that was previously repeated in both edge-behav= iours (agreed with IESG and with edge-behaviour authors, of course). Altho = it largely does the same thing technically, it is written to cover the comp= lete range of possible scenarios, and it now gives defaults and recommended= choices. I don't think it's controversial, but shout if it is. < http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 = > Bob PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: * Added note about fail-safe to protect other traffic in the event of tunnel misconfiguration. * Changed section heading to be about applicability of environments to the encoding, rather than the encoding to the environments. * Completely re-wrote PCN-ingress Node Behaviour section. * Changed PCN interior node to PCN-node where the term was intended to include all PCN-nodes. * Clarified status of ECN/PCN co-existence appendix. Removed inconsistent assertion in this appendix that an admission- control DSCP alone can indicate that arriving traffic is PCN- traffic. * A few clarifying editorial amendments and updated refs. From: > To: >, >, >, >, > Date: Sun, 11 Mar 2012 17:52:23 -0700 Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.= txt. http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09 IETF Secretariat. ________________________________________________________________ Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I think that the changes satisfy nicely the comments of Adrian!

 

Best regards,

Georgios

 

 

Van: pcn-bounces@ietf.org [pcn-bounces@iet= f.org] namens philip.eardley@bt.com [philip.eardley@bt.com]
Verzonden: dinsdag 20 maart 2012 17:46
Aan: sob@harvard.edu; pcn@ietf.org
Onderwerp: Re: [PCN] lets try again - a chair asking this time

Seems good to me. I like the inclusion of = material previously in both the edge behaviour docs

 

From: pcn-bounces@ietf= .org [mailto:pcn-bounces@ietf.org] On Behalf Of Bradner, Scott
Sent: 20 March 2012 16:37
To: pcn@ietf.org
Subject: [PCN] lets try again - a chair asking this time

 

please let the list know what you think

 

Scott

 

Scott O Bradner

Senior T= echnology Consultant

 

Begin forwarded message:



 

Date: Mon, 12 Mar 2012= 03:30:11 +0000
To: "PCN IETF list" <pcn@ietf.org>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt

PCN folks,

Following IESG review (particularly Adrian Farrel's being the most comprehe= nsive and useful), we've posted a new version of the PCN 3-in-1 encoding.
As well as a number of editorial changes, some technical changes were neede= d in order to satisfy Adrian's request to specify exactly what an implement= er has to do at the ingress to allow ECN to co-exist with PCN, and what def= aults should be set to.

In particular, for a non-PCN packet (i.e. doesn't match any flow-state) tha= t clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 i= s:

      *  re-mark the DSCP to a DSCP that is n= ot PCN-compatible;

      
[...]           =
;            &n=
bsp;            =
;            &n=
bsp;            =
;
In the
      absence of any operator-specific
configuration for this case, by
      default an implementation SHOULD re-mar=
k
the DSCP to zero.
 


Actually, the whole of the ingress behaviour section (5.1) has been re-writ= ten, incorporating material that was previously repeated in both edge-behav= iours (agreed with IESG and with edge-behaviour authors, of course). Altho = it largely does the same thing technically, it is written to cover the complete range of possible scenarios, and it no= w gives defaults and recommended choices. I don't think it's controversial,= but shout if it is.
< http://tools.ietf.org/html/draft-ietf-pcn-= 3-in-1-encoding-09#section-5.1 >



Bob

PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:

      *  Added note about fail-safe to protec= t other traffic in the
         event of tunnel misconfigu= ration.

      *  Changed section heading to be about = applicability of
         environments to the encodi= ng, rather than the encoding to the
         environments.

      *  Completely re-wrote PCN-ingress Node= Behaviour section.

      *  Changed PCN interior node to PCN-nod= e where the term was
         intended to include all PC= N-nodes.

      *  Clarified status of ECN/PCN co-exist= ence appendix.  Removed
         inconsistent assertion in = this appendix that an admission-
         control DSCP alone can ind= icate that arriving traffic is PCN-
         traffic.

      *  A few clarifying editorial amendment= s and updated refs.




From: <internet-drafts@ietf.org>
To: <pcn-= chairs@tools.ietf.org>,
        <draft-ietf-pcn-3-in-= 1-encoding@tools.ietf.org>, <ietfdbh@comcast.net>,
        <adrian@olddog.co.uk>, <rjsparks@nostrum.com> Date: Sun, 11 Mar 2012 17:52:23 -0700
Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt
New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.= txt.
http://www.ietf.org/internet-drafts/draft-ietf= -pcn-3-in-1-encoding-09.txt


Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-p= cn-3-in-1-encoding-09

IETF Secretariat.


________________________________________________________________
Bob Briscoe,          &nb= sp;            =          BT Innovate & Design <= /p>

________________________________________________________________
Bob Briscoe,          &nb= sp;            =          BT Innovate & Design

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_-- From tom.taylor.stds@gmail.com Tue Mar 20 13:18:58 2012 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 1CC1321F84EC for ; Tue, 20 Mar 2012 13:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AV3b8P0L3HnZ for ; Tue, 20 Mar 2012 13:18:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58121F846E for ; Tue, 20 Mar 2012 13:18:57 -0700 (PDT) Received: by ghbg16 with SMTP id g16so518935ghb.31 for ; Tue, 20 Mar 2012 13:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=4otYHTiF8BH06NKgsFMq1uouDSPKvSzgskT0HwhBg6U=; b=tjZHpx8z2JaQGAt1SX9D1bc267sAya74h+hwf9pHEQJKxM1YPDbVQqZJ9qDIP+8aUq GZGqEuYTvTFFcoGfEefHJyYX3yAFS0VmS3yevosg3d3s3BfMQqcp/RvvR46bPYMEza5H 2pO4f7cqa3OSCl2BguttTvZCaEQcn7mcGt/g0KdeIe/rid2CyeeBDnpXSXRu9WuCmbkr 1XBNngNI2entjN8Ul/y78D3fntGudWNWfYER7frBX4rf/8Jwth7orjdeb/nkiMQfbphG 1Ngq6SC6AVbUxiucn4djgGPx1w+6ubjcl6+1TqMG3MgfHK1x0verSuYU6vORMaCwD4LW sZ7g== Received: by 10.236.157.9 with SMTP id n9mr1255227yhk.96.1332274737082; Tue, 20 Mar 2012 13:18:57 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id b4sm3188142anb.22.2012.03.20.13.18.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 13:18:56 -0700 (PDT) Message-ID: <4F68E62E.9080502@gmail.com> Date: Tue, 20 Mar 2012 16:18:54 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120320-0, 20/03/2012), Outbound message X-Antivirus-Status: Clean Cc: Pete Resnick Subject: [PCN] PCN edge behaviour experiment 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, 20 Mar 2012 20:18:58 -0000 I am making what I trust will be the final revisions to the edge behaviour documents in response to IESG comments. Amongst other things, this is the text I propose to add in the introduction to justify the Experimental status of the documents. The text will be the same for CL and for SM, following on Ruediger's observation that both behaviours are valid in different contexts. Comments are welcomed. --- This document describes an experimental edge node behaviour to implement PCN in a network. The experiment may be run in a network in which a substantial proportion of the traffic carried is in the form of inelastic flows and where admission control of micro-flows is applied at the edge. For the effects of PCN to be observable, at least some links of the network should be running near or at capacity. The amount of effort required to prepare the network for the experiment (see Section 5.1) may constrain the size of network to which it is applied. The purposes of the experiment are: - to validate the specification of the CL [SM] edge behaviour; - to evaluate the effectiveness of the CL [SM] edge behaviour in preserving quality of service for admitted flows; and - to evaluate PCN's potential for reducing the amount of capital and operational costs in comparison to alternative methods of assuring quality of service. For the first two objectives, the experiment should run long enough for the network to experience sharp peaks of traffic in at least some directions. It would also be desirable to observe PCN performance in the face of failures in the network. A period in the order of a month or two in busy season may be enough. The third objective is more difficult, and could require observation over a period long enough for traffic demand to grow to the point where additional capacity must be provisioned at some points in the network. From menth@informatik.uni-tuebingen.de Tue Mar 20 13:52:24 2012 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 E554321F866D for ; Tue, 20 Mar 2012 13:52: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYkOu-ZMy0lO for ; Tue, 20 Mar 2012 13:52:23 -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 27FCB21F8658 for ; Tue, 20 Mar 2012 13:52:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3B10A5316; Tue, 20 Mar 2012 21:52:09 +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 ZXWBaCbq1iiP; Tue, 20 Mar 2012 21:52:03 +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 2577752AC; Tue, 20 Mar 2012 21:52:03 +0100 (MET) Received: from [192.168.1.101] (HSI-KBW-046-005-044-175.hsi8.kabel-badenwuerttemberg.de [46.5.44.175]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id D1BAA402B79B; Tue, 20 Mar 2012 21:52:01 +0100 (CET) Message-ID: <4F68EDF1.8070004@informatik.uni-tuebingen.de> Date: Tue, 20 Mar 2012 21:52:01 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Tom Taylor References: <4F68E62E.9080502@gmail.com> In-Reply-To: <4F68E62E.9080502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behaviour experiment 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, 20 Mar 2012 20:52:24 -0000 Hi Tom, Am 20.03.2012 21:18, schrieb Tom Taylor: > I am making what I trust will be the final revisions to the edge > behaviour documents in response to IESG comments. Amongst other > things, this is the text I propose to add in the introduction to > justify the Experimental status of the documents. The text will be the > same for CL and for SM, following on Ruediger's observation that both > behaviours are valid in different contexts. Comments are welcomed. > > --- > > This document describes an experimental edge node behaviour to > implement PCN in a network. The experiment may be run in a network in > which a substantial proportion of the traffic carried is in the form > of inelastic flows and where admission control of micro-flows is > applied at the edge. For the effects of PCN to be observable, at least > some links of the network should be running near or at capacity. Better: "the aggregate rate of admitted flows on some links should come close to the bandwidths of these links." > The amount of effort required to prepare the network for the > experiment (see Section 5.1) may constrain the size of network to > which it is applied. The purposes of the experiment are: > > - to validate the specification of the CL [SM] edge behaviour; > > - to evaluate the effectiveness of the CL [SM] edge behaviour in > preserving quality of service for admitted flows; and > > - to evaluate PCN's potential for reducing the amount of capital and > operational costs in comparison to alternative methods of assuring > quality of service. > > For the first two objectives, the experiment should run long enough > for the network to experience sharp peaks of traffic in at least some > directions. These peaks could be intentionally caused for the sake of the experiment so that the effect of admission control is visible. > It would also be desirable to observe PCN performance in the face of > failures in the network. A period in the order of a month or two in > busy season may be enough. The third objective is more difficult, and > could require observation over a period long enough for traffic demand > to grow to the point where additional capacity must be provisioned at > some points in the network. Also failures could be intentionally caused for the sake of the experiment. Capacity shortage on backup paths could also be planned for so that the effect of flow termination is visible. Best wishes, Michael > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- 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://kn.inf.uni-tuebingen.de From tom.taylor.stds@gmail.com Tue Mar 20 14:11:24 2012 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 44B7E21F8674 for ; Tue, 20 Mar 2012 14:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.504 X-Spam-Level: X-Spam-Status: No, score=-3.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyWW0cGz621n for ; Tue, 20 Mar 2012 14:11:23 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4321F866E for ; Tue, 20 Mar 2012 14:11:23 -0700 (PDT) Received: by yhkk25 with SMTP id k25so558676yhk.31 for ; Tue, 20 Mar 2012 14:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=Vsy2JdoLmUm30cknZatwsJXcDj++mGg/GbqI5I0kFCw=; b=olufaTQU/tDeZBMuwHyTmJcBicBXfQz99Y5ZI1qWh73h9OOMLBxMDB9+/sK7JR9LI/ Y122Duv0tsUwEiL2lRBTOJxPRimkD6Bzc6mfVq3+sjDbuOs8pm3dBIY3xD9yUP+oNEnW mE4KWd1zyGWLRtpHPAI33NABNtkkTNj8r3Ud2ddjidZf5oaG7Y+Kwm1H2cizU8iZoPLt f2P4ElnntCpWIwIbVkv0pph6BzMuQkH//6VFdSUKTsIAbQL5CRMUCJdYFJnF5d/I2kJL SDwRW50Z+I7zdJjqr9Q6o6Se7svTyXCyl+boNEJWCnOd9/ZHL9KJo6CZZ14+zrPvMYas ZdxQ== Received: by 10.236.197.103 with SMTP id s67mr1646559yhn.5.1332277882702; Tue, 20 Mar 2012 14:11:22 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id p15sm3385736ani.15.2012.03.20.14.11.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 14:11:21 -0700 (PDT) Message-ID: <4F68F278.50108@gmail.com> Date: Tue, 20 Mar 2012 17:11:20 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Michael Menth References: <4F68E62E.9080502@gmail.com> <4F68EDF1.8070004@informatik.uni-tuebingen.de> In-Reply-To: <4F68EDF1.8070004@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120320-0, 20/03/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behaviour experiment 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, 20 Mar 2012 21:11:24 -0000 Good points. That means the experiment doesn't have to run very long to meet the first two objectives. I do have one concern that if you introduce artificial traffic then maybe you don't get the same outcome that real traffic gives you. I figure it's inevitable that the benefits of PCN with real traffic in a real network will be less than our simulations show, if only because real networks tend to be over-provided with capacity. On 20/03/2012 4:52 PM, Michael Menth wrote: > Hi Tom, > > > Am 20.03.2012 21:18, schrieb Tom Taylor: >> I am making what I trust will be the final revisions to the edge >> behaviour documents in response to IESG comments. Amongst other >> things, this is the text I propose to add in the introduction to >> justify the Experimental status of the documents. The text will be the >> same for CL and for SM, following on Ruediger's observation that both >> behaviours are valid in different contexts. Comments are welcomed. >> >> --- >> >> This document describes an experimental edge node behaviour to >> implement PCN in a network. The experiment may be run in a network in >> which a substantial proportion of the traffic carried is in the form >> of inelastic flows and where admission control of micro-flows is >> applied at the edge. For the effects of PCN to be observable, at least >> some links of the network should be running near or at capacity. > Better: "the aggregate rate of admitted flows on some links should come > close to the bandwidths of these links." > >> The amount of effort required to prepare the network for the >> experiment (see Section 5.1) may constrain the size of network to >> which it is applied. The purposes of the experiment are: >> >> - to validate the specification of the CL [SM] edge behaviour; >> >> - to evaluate the effectiveness of the CL [SM] edge behaviour in >> preserving quality of service for admitted flows; and >> >> - to evaluate PCN's potential for reducing the amount of capital and >> operational costs in comparison to alternative methods of assuring >> quality of service. >> >> For the first two objectives, the experiment should run long enough >> for the network to experience sharp peaks of traffic in at least some >> directions. > These peaks could be intentionally caused for the sake of the experiment > so that the effect of admission control is visible. > >> It would also be desirable to observe PCN performance in the face of >> failures in the network. A period in the order of a month or two in >> busy season may be enough. The third objective is more difficult, and >> could require observation over a period long enough for traffic demand >> to grow to the point where additional capacity must be provisioned at >> some points in the network. > Also failures could be intentionally caused for the sake of the > experiment. Capacity shortage on backup paths could also be planned for > so that the effect of flow termination is visible. > > Best wishes, > > Michael > >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > From menth@informatik.uni-tuebingen.de Tue Mar 20 14:14:14 2012 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 C14F221F865A for ; Tue, 20 Mar 2012 14:14:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7p4wvzKhVqy for ; Tue, 20 Mar 2012 14:14:14 -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 86F9821F8637 for ; Tue, 20 Mar 2012 14:14:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4CA0152D7; Tue, 20 Mar 2012 22:14:11 +0100 (MET) 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 Xmctjnr3eOZI; Tue, 20 Mar 2012 22:14:03 +0100 (MET) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id EA6F35255; Tue, 20 Mar 2012 22:14:02 +0100 (MET) Received: from [192.168.1.101] (HSI-KBW-046-005-044-175.hsi8.kabel-badenwuerttemberg.de [46.5.44.175]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 1E045185112D; Tue, 20 Mar 2012 22:14:01 +0100 (CET) Message-ID: <4F68F318.1000107@informatik.uni-tuebingen.de> Date: Tue, 20 Mar 2012 22:14:00 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Tom Taylor References: <4F68E62E.9080502@gmail.com> <4F68EDF1.8070004@informatik.uni-tuebingen.de> <4F68F278.50108@gmail.com> In-Reply-To: <4F68F278.50108@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behaviour experiment 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, 20 Mar 2012 21:14:14 -0000 I don't suggest artifical traffic to cause admitted traffic exceeding the PCN threshold but real traffic. A planned experiment does not imply artifical traffic. Am 20.03.2012 22:11, schrieb Tom Taylor: > Good points. That means the experiment doesn't have to run very long > to meet the first two objectives. I do have one concern that if you > introduce artificial traffic then maybe you don't get the same outcome > that real traffic gives you. I figure it's inevitable that the > benefits of PCN with real traffic in a real network will be less than > our simulations show, if only because real networks tend to be > over-provided with capacity. > > On 20/03/2012 4:52 PM, Michael Menth wrote: >> Hi Tom, >> >> >> Am 20.03.2012 21:18, schrieb Tom Taylor: >>> I am making what I trust will be the final revisions to the edge >>> behaviour documents in response to IESG comments. Amongst other >>> things, this is the text I propose to add in the introduction to >>> justify the Experimental status of the documents. The text will be the >>> same for CL and for SM, following on Ruediger's observation that both >>> behaviours are valid in different contexts. Comments are welcomed. >>> >>> --- >>> >>> This document describes an experimental edge node behaviour to >>> implement PCN in a network. The experiment may be run in a network in >>> which a substantial proportion of the traffic carried is in the form >>> of inelastic flows and where admission control of micro-flows is >>> applied at the edge. For the effects of PCN to be observable, at least >>> some links of the network should be running near or at capacity. >> Better: "the aggregate rate of admitted flows on some links should come >> close to the bandwidths of these links." >> >>> The amount of effort required to prepare the network for the >>> experiment (see Section 5.1) may constrain the size of network to >>> which it is applied. The purposes of the experiment are: >>> >>> - to validate the specification of the CL [SM] edge behaviour; >>> >>> - to evaluate the effectiveness of the CL [SM] edge behaviour in >>> preserving quality of service for admitted flows; and >>> >>> - to evaluate PCN's potential for reducing the amount of capital and >>> operational costs in comparison to alternative methods of assuring >>> quality of service. >>> >>> For the first two objectives, the experiment should run long enough >>> for the network to experience sharp peaks of traffic in at least some >>> directions. >> These peaks could be intentionally caused for the sake of the experiment >> so that the effect of admission control is visible. >> >>> It would also be desirable to observe PCN performance in the face of >>> failures in the network. A period in the order of a month or two in >>> busy season may be enough. The third objective is more difficult, and >>> could require observation over a period long enough for traffic demand >>> to grow to the point where additional capacity must be provisioned at >>> some points in the network. >> Also failures could be intentionally caused for the sake of the >> experiment. Capacity shortage on backup paths could also be planned for >> so that the effect of flow termination is visible. >> >> Best wishes, >> >> Michael >> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >> -- 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://kn.inf.uni-tuebingen.de From jmpolk@cisco.com Tue Mar 20 14:40:07 2012 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 6EBC121E8017 for ; Tue, 20 Mar 2012 14:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.885 X-Spam-Level: X-Spam-Status: No, score=-109.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7NAnH+OrTi5 for ; Tue, 20 Mar 2012 14:40:06 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9F99521E8015 for ; Tue, 20 Mar 2012 14:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5473; q=dns/txt; s=iport; t=1332279606; x=1333489206; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=NVVamapT9PXnMHuPGJq9pvN7qsh2bzaq7DdnDdp4/K0=; b=ZDcLH+rG8egdQYZvFkXYYy2PGLxv9q1fXVQ3zVNyKDmsGoM9dLSelXRs WPfRw6MWQRh1G4OjLInlhzYjtpJIQYqN5etRPJ3TSKlwfKH4rS6FVi3LR TpTnlMjxxZzbkZE6JNx6uO5t8syLnK4VS28ThtZ+/brRAGWi1vk1MVgcX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALT3aE+rRDoH/2dsb2JhbABEDrZWgQeCCQEBAQQBAQEPASUCNBsHBBEDAQEBAR4JBxkOHwkIBgESCRmHZwyXY58xkQEEiFabSIFogjBV X-IronPort-AV: E=Sophos;i="4.73,620,1325462400"; d="scan'208";a="36866686" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 20 Mar 2012 21:40:06 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2KLe5ud007565; Tue, 20 Mar 2012 21:40:05 GMT Message-Id: <201203202140.q2KLe5ud007565@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Mar 2012 16:40:04 -0500 To: , , , From: "James M. Polk" In-Reply-To: References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <9510D26531EF184D9017DF24659BB87F331D442A7C@EMV65-UKRD.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:40:07 -0000 I know this is a nit, but shouldn't the text actually read Option #1 "... re-mark the DSCP to 000000." or even Option #2 "... re-mark the DSCP to 0." or even Option #3 "... re-mark the DSCP to zero (000000)." or even Option #4 "... re-mark the DSCP to zero (0)." instead of just "... re-mark the DSCP to zero." ? I prefer Option #1, but am happy with Option #3 over the others. IMO this should not remain as it is. James At 02:25 PM 3/20/2012, karagian@cs.utwente.nl wrote: >Content-Language: nl-NL >Content-Type: multipart/alternative; > >boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_" > >Hi all, > > > >I think that the changes satisfy nicely the comments of Adrian! > > > >Best regards, > >Georgios > > > > > >---------- >Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens >philip.eardley@bt.com [philip.eardley@bt.com] >Verzonden: dinsdag 20 maart 2012 17:46 >Aan: sob@harvard.edu; pcn@ietf.org >Onderwerp: Re: [PCN] lets try again - a chair asking this time > >Seems good to me. I like the inclusion of material previously in >both the edge behaviour docs > > > >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >Of Bradner, Scott >Sent: 20 March 2012 16:37 >To: pcn@ietf.org >Subject: [PCN] lets try again - a chair asking this time > > > >please let the list know what you think > > > >Scott > > > >Scott O Bradner > >Senior Technology Consultant > > > >Begin forwarded message: > > > > > >Date: Mon, 12 Mar 2012 03:30:11 +0000 >To: "PCN IETF list" <pcn@ietf.org> >From: Bob Briscoe <bob.briscoe@bt.com> >Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt > >PCN folks, > >Following IESG review (particularly Adrian Farrel's being the most >comprehensive and useful), we've posted a new version of the PCN >3-in-1 encoding. > >As well as a number of editorial changes, some technical changes >were needed in order to satisfy Adrian's request to specify exactly >what an implementer has to do at the ingress to allow ECN to >co-exist with PCN, and what defaults should be set to. > >In particular, for a non-PCN packet (i.e. doesn't match any >flow-state) that clashes with a PCN DSCP and is ECN-capable, the >recommended choice of 3 is: > > * re-mark the DSCP to a DSCP that is not PCN-compatible; > > > > >[...] > >In the > > absence of any operator-specific > >configuration for this case, by > > default an implementation SHOULD re-mark > >the DSCP to zero. > > > > >Actually, the whole of the ingress behaviour section (5.1) has been >re-written, incorporating material that was previously repeated in >both edge-behaviours (agreed with IESG and with edge-behaviour >authors, of course). Altho it largely does the same thing >technically, it is written to cover the complete range of possible >scenarios, and it now gives defaults and recommended choices. I >don't think it's controversial, but shout if it is. >< http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 > > > > >Bob > >PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: > > * Added note about fail-safe to protect other traffic in the > event of tunnel misconfiguration. > > * Changed section heading to be about applicability of > environments to the encoding, rather than the encoding to the > environments. > > * Completely re-wrote PCN-ingress Node Behaviour section. > > * Changed PCN interior node to PCN-node where the term was > intended to include all PCN-nodes. > > * Clarified status of ECN/PCN co-existence appendix. Removed > inconsistent assertion in this appendix that an admission- > control DSCP alone can indicate that arriving traffic is PCN- > traffic. > > * A few clarifying editorial amendments and updated refs. > > > > >From: <internet-drafts@ietf.org> >To: <pcn-chairs@tools.ietf.org>, > ><draft-ietf-pcn-3-in-1-encoding@tools.ietf.org>, ><ietfdbh@comcast.net>, > <adrian@olddog.co.uk>, > <rjsparks@nostrum.com> >Date: Sun, 11 Mar 2012 17:52:23 -0700 >Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt > >New version (-09) has been submitted for >draft-ietf-pcn-3-in-1-encoding-09.txt. >http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt > > > >Diff from previous version: >http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09 > > >IETF Secretariat. > > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-tuebingen.de Tue Mar 20 14:48:37 2012 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 6403721E801F for ; Tue, 20 Mar 2012 14:48:37 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xvHFVp+zSMV for ; Tue, 20 Mar 2012 14:48:36 -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 BCFFB21E8015 for ; Tue, 20 Mar 2012 14:48:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 692CD5316; Tue, 20 Mar 2012 22:48:32 +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 cVAeqib3nCsQ; Tue, 20 Mar 2012 22:48:29 +0100 (MET) 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 289BC52AC; Tue, 20 Mar 2012 22:48:29 +0100 (MET) Received: from [192.168.1.101] (HSI-KBW-046-005-044-175.hsi8.kabel-badenwuerttemberg.de [46.5.44.175]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5DB341851317; Tue, 20 Mar 2012 22:48:29 +0100 (CET) Message-ID: <4F68FB2C.1040304@informatik.uni-tuebingen.de> Date: Tue, 20 Mar 2012 22:48:28 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "pcn@ietf.org" References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <604B7B86-A2E8-4CA7-98D6-B59F995766FA@moncaster.com> In-Reply-To: <604B7B86-A2E8-4CA7-98D6-B59F995766FA@moncaster.com> Content-Type: multipart/alternative; boundary="------------000203040102090107060705" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:48:37 -0000 This is a multi-part message in MIME format. --------------000203040102090107060705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Same holds for me. Michael Am 20.03.2012 17:46, schrieb Toby Moncaster: > I certainly think this is now in good shape to progress (but as I'm an > author my opinion may be biased). > > Toby > > > > On 20 Mar 2012, at 16:37, "Bradner, Scott" > wrote: > >> please let the list know what you think >> >> Scott >> >> Scott O Bradner >> Senior Technology Consultant >> >> >> Begin forwarded message: >> >>> * >>> * >>>> Date: Mon, 12 Mar 2012 03:30:11 +0000 >>>> To: "PCN IETF list" > >>>> From: Bob Briscoe > >>>> Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt >>>> >>>> PCN folks, >>>> >>>> Following IESG review (particularly Adrian Farrel's being the most >>>> comprehensive and useful), we've posted a new version of the PCN >>>> 3-in-1 encoding. >>>> >>>> As well as a number of editorial changes, some technical changes >>>> were needed in order to satisfy Adrian's request to specify exactly >>>> what an implementer has to do at the ingress to allow ECN to >>>> co-exist with PCN, and what defaults should be set to. >>>> >>>> In particular, for a non-PCN packet (i.e. doesn't match any >>>> flow-state) that clashes with a PCN DSCP and is ECN-capable, the >>>> recommended choice of 3 is: >>>> >>>> * re-mark the DSCP to a DSCP that is not PCN-compatible; >>>> >>>> >>>> >>>> [...] >>>> In the >>>> absence of any operator-specific >>>> configuration for this case, by >>>> default an implementation SHOULD re-mark >>>> the DSCP to zero. >>>> >>>> >>>> Actually, the whole of the ingress behaviour section (5.1) has been >>>> re-written, incorporating material that was previously repeated in >>>> both edge-behaviours (agreed with IESG and with edge-behaviour >>>> authors, of course). Altho it largely does the same thing >>>> technically, it is written to cover the complete range of possible >>>> scenarios, and it now gives defaults and recommended choices. I >>>> don't think it's controversial, but shout if it is. >>>> >>> > >>>> >>>> >>>> >>>> Bob >>>> >>>> PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: >>>> >>>> * Added note about fail-safe to protect other traffic in the >>>> event of tunnel misconfiguration. >>>> >>>> * Changed section heading to be about applicability of >>>> environments to the encoding, rather than the encoding to the >>>> environments. >>>> >>>> * Completely re-wrote PCN-ingress Node Behaviour section. >>>> >>>> * Changed PCN interior node to PCN-node where the term was >>>> intended to include all PCN-nodes. >>>> >>>> * Clarified status of ECN/PCN co-existence appendix. Removed >>>> inconsistent assertion in this appendix that an admission- >>>> control DSCP alone can indicate that arriving traffic is PCN- >>>> traffic. >>>> >>>> * A few clarifying editorial amendments and updated refs. >>>> >>>> >>>> >>>>> From: > >>>>> To: >, >>>>> >>>> >, >>>>> >, >>>>> >, >>>>> > >>>>> Date: Sun, 11 Mar 2012 17:52:23 -0700 >>>>> Subject: New Version Notification - >>>>> draft-ietf-pcn-3-in-1-encoding-09.txt >>>>> >>>>> New version (-09) has been submitted for >>>>> draft-ietf-pcn-3-in-1-encoding-09.txt. >>>>> http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt >>>>> >>>>> >>>>> >>>>> Diff from previous version: >>>>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09 >>>>> >>>>> IETF Secretariat. >>>> >>>> ________________________________________________________________ >>>> Bob Briscoe, BT Innovate & Design >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >>> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- 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://kn.inf.uni-tuebingen.de --------------000203040102090107060705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Same holds for me.

Michael

Am 20.03.2012 17:46, schrieb Toby Moncaster:
I certainly think this is now in good shape to progress (but as I'm an author my opinion may be biased).

Toby



On 20 Mar 2012, at 16:37, "Bradner, Scott" <sob@harvard.edu> wrote:

please let the list know what you think

Scott

Scott O Bradner
Senior Technology Consultant


Begin forwarded message:


Date: Mon, 12 Mar 2012 03:30:11 +0000
To: "PCN IETF list" <pcn@ietf.org>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt

PCN folks,

Following IESG review (particularly Adrian Farrel's being the most comprehensive and useful), we've posted a new version of the PCN 3-in-1 encoding.

As well as a number of editorial changes, some technical changes were needed in order to satisfy Adrian's request to specify exactly what an implementer has to do at the ingress to allow ECN to co-exist with PCN, and what defaults should be set to.

In particular, for a non-PCN packet (i.e. doesn't match any flow-state) that clashes with a PCN DSCP and is ECN-capable, the recommended choice of 3 is:

      *  re-mark the DSCP to a DSCP that is not PCN-compatible;


      
[...]                                                             
In the
      absence of any operator-specific
configuration for this case, by
      default an implementation SHOULD re-mark
the DSCP to zero.

Actually, the whole of the ingress behaviour section (5.1) has been re-written, incorporating material that was previously repeated in both edge-behaviours (agreed with IESG and with edge-behaviour authors, of course). Altho it largely does the same thing technically, it is written to cover the complete range of possible scenarios, and it now gives defaults and recommended choices. I don't think it's controversial, but shout if it is.
< http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 >



Bob

PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09:

      *  Added note about fail-safe to protect other traffic in the
         event of tunnel misconfiguration.

      *  Changed section heading to be about applicability of
         environments to the encoding, rather than the encoding to the
         environments.

      *  Completely re-wrote PCN-ingress Node Behaviour section.

      *  Changed PCN interior node to PCN-node where the term was
         intended to include all PCN-nodes.

      *  Clarified status of ECN/PCN co-existence appendix.  Removed
         inconsistent assertion in this appendix that an admission-
         control DSCP alone can indicate that arriving traffic is PCN-
         traffic.

      *  A few clarifying editorial amendments and updated refs.



From: <internet-drafts@ietf.org>
To: <pcn-chairs@tools.ietf.org>,
        <draft-ietf-pcn-3-in-1-encoding@tools.ietf.org>, <ietfdbh@comcast.net>,
        <adrian@olddog.co.uk>, <rjsparks@nostrum.com>
Date: Sun, 11 Mar 2012 17:52:23 -0700
Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt

New version (-09) has been submitted for draft-ietf-pcn-3-in-1-encoding-09.txt.
http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt


Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09

IETF Secretariat.

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn


-- 
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://kn.inf.uni-tuebingen.de
--------------000203040102090107060705-- From Ruediger.Geib@telekom.de Wed Mar 21 00:26:00 2012 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 1ED8221F84E4 for ; Wed, 21 Mar 2012 00:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J6aUMhHiJWE for ; Wed, 21 Mar 2012 00:25:59 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED921F84D4 for ; Wed, 21 Mar 2012 00:25:58 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 21 Mar 2012 08:25:57 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.76]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 21 Mar 2012 08:25:57 +0100 From: To: , Date: Wed, 21 Mar 2012 08:25:56 +0100 Thread-Topic: [PCN] PCN edge behaviour experiment Thread-Index: Ac0G2138dE1q5vmYThOoR+tUmXco9gAVz8JQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A6FC9@HE111648.emea1.cds.t-internal.com> References: <4F68E62E.9080502@gmail.com> <4F68EDF1.8070004@informatik.uni-tuebingen.de> In-Reply-To: <4F68EDF1.8070004@informatik.uni-tuebingen.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behaviour experiment 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, 21 Mar 2012 07:26:00 -0000 Hi Tom, hi Michael "network running near capacity" is correct if complete links transmit PCN traffic only. Otherwise, "PCN network capacities running near congestion (on at least one interface)" is better. That may also simplify experiments, dedicated tunnels in a live network with proper marking may suffice. Regards, Ruediger Tom: > This document describes an experimental edge node behaviour to > implement PCN in a network. The experiment may be run in a network in > which a substantial proportion of the traffic carried is in the form > of inelastic flows and where admission control of micro-flows is > applied at the edge. For the effects of PCN to be observable, at least > some links of the network should be running near or at capacity. Michael: Better: "the aggregate rate of admitted flows on some links should come close to the bandwidths of these links." > The amount of effort required to prepare the network for the > experiment (see Section 5.1) may constrain the size of network to > which it is applied. The purposes of the experiment are: > > - to validate the specification of the CL [SM] edge behaviour; > > - to evaluate the effectiveness of the CL [SM] edge behaviour in > preserving quality of service for admitted flows; and > > - to evaluate PCN's potential for reducing the amount of capital and > operational costs in comparison to alternative methods of assuring > quality of service. > > For the first two objectives, the experiment should run long enough > for the network to experience sharp peaks of traffic in at least some > directions. Michael These peaks could be intentionally caused for the sake of the experiment so that the effect of admission control is visible. From Ruediger.Geib@telekom.de Wed Mar 21 01:07:58 2012 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 2FF2021F8522 for ; Wed, 21 Mar 2012 01:07:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HF8olsurtOtg for ; Wed, 21 Mar 2012 01:07:57 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7E41E21F850B for ; Wed, 21 Mar 2012 01:07:54 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 21 Mar 2012 09:07:52 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.76]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 21 Mar 2012 09:07:51 +0100 From: To: Date: Wed, 21 Mar 2012 09:07:51 +0100 Thread-Topic: lets try again - a chair asking this time Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+5Z0XZ2Q Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> In-Reply-To: <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 08:07:58 -0000 Hi Scott, the passage you quote should result from a misconfiguration or an attack. Treatment of non-PCN-packets confused with a PCN-packet due to DSCP/ECN codepoinzt setting: ... In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. ... Clearing the ECN field is not an appropriate policing action, because a network node ought not to interfere with an e2e signal. Even if such packets seem like an attack, drop would be overkill, because such an attack can be neutralised by just re-marking the DSCP. And DSCP re-marking in the network is legitimate, because the DSCP is not considered an e2e signal. What's done here is remarking of a flow with a DSCP that has been agreed between two parties. On a consumer UNI, this may be an attack, on an NNI, this could indicate a misconfiguration. In the latter case, a management alert seems reasonable. Text to that may be added. I further quote the PCN architecture, which is informational, on the Ingress Node behaviour: Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Similarly, police packets that are part of a previously admitted flow, to check that the flow keeps to the agreed rate or flowspec (eg, see [RFC1633] for a microflow and its NSIS equivalent). This isn't in line with the proposed 3-in-1 (standards track) behaviour. Does this require an "Errata" atatement for RFC5559 (I'm not an expert on editing RFCs and may be wrong here)? Regards, Ruediger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Bradn= er, Scott Sent: Tuesday, March 20, 2012 5:37 PM To: pcn@ietf.org Subject: [PCN] lets try again - a chair asking this time please let the list know what you think Scott Scott O Bradner Senior Technology Consultant Begin forwarded message: Date: Mon, 12 Mar 2012 03:30:11 +0000 To: "PCN IETF list" From: Bob Briscoe Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt PCN folks, Following IESG review (particularly Adrian Farrel's being t= he most comprehensive and useful), we've posted a new version of the PCN 3-= in-1 encoding. As well as a number of editorial changes, some technical ch= anges were needed in order to satisfy Adrian's request to specify exactly w= hat an implementer has to do at the ingress to allow ECN to co-exist with P= CN, and what defaults should be set to. In particular, for a non-PCN packet (i.e. doesn't match any= flow-state) that clashes with a PCN DSCP and is ECN-capable, the recommend= ed choice of 3 is: * re-mark the DSCP to a DSCP that is not PCN-compati= ble; [...] In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. Actually, the whole of the ingress behaviour section (5.1) = has been re-written, incorporating material that was previously repeated in= both edge-behaviours (agreed with IESG and with edge-behaviour authors, of= course). Altho it largely does the same thing technically, it is written t= o cover the complete range of possible scenarios, and it now gives defaults= and recommended choices. I don't think it's controversial, but shout if it= is. < http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding= -09#section-5.1 > Bob PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: * Added note about fail-safe to protect other traffi= c in the event of tunnel misconfiguration. * Changed section heading to be about applicability = of environments to the encoding, rather than the enco= ding to the environments. * Completely re-wrote PCN-ingress Node Behaviour sec= tion. * Changed PCN interior node to PCN-node where the te= rm was intended to include all PCN-nodes. * Clarified status of ECN/PCN co-existence appendix.= Removed inconsistent assertion in this appendix that an ad= mission- control DSCP alone can indicate that arriving traf= fic is PCN- traffic. * A few clarifying editorial amendments and updated = refs. From: To: , , , , Date: Sun, 11 Mar 2012 17:52:23 -0700 Subject: New Version Notification - draft-ietf-pcn-= 3-in-1-encoding-09.txt New version (-09) has been submitted for draft-ietf= -pcn-3-in-1-encoding-09.txt. http://www.ietf.org/internet-drafts/draft-ietf-pcn-= 3-in-1-encoding-09.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn= -3-in-1-encoding-09 IETF Secretariat. ___________________________________________________________= _____ Bob Briscoe, BT Innovate & D= esign ________________________________________________________________ Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Wed Mar 21 01:11:56 2012 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 65C2721F8550 for ; Wed, 21 Mar 2012 01:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFK2Gqw9B3rh for ; Wed, 21 Mar 2012 01:11:55 -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 3573321F8546 for ; Wed, 21 Mar 2012 01:11:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 359015298; Wed, 21 Mar 2012 09:11:49 +0100 (MET) 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 XEKzs-Pmg1FY; Wed, 21 Mar 2012 09:11:45 +0100 (MET) 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 24B435271; Wed, 21 Mar 2012 09:11:45 +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 42EB7403E4D6; Wed, 21 Mar 2012 09:11:45 +0100 (CET) Message-ID: <4F698D41.3010309@informatik.uni-tuebingen.de> Date: Wed, 21 Mar 2012 09:11:45 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <4F68E62E.9080502@gmail.com> <4F68EDF1.8070004@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A6FC9@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A6FC9@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behaviour experiment 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, 21 Mar 2012 08:11:56 -0000 Hi Ruediger, hi Tom! Ruediger, you are right. The text should be "the aggregate rate of admitted flows on some links should come close to the *admissible rates* of these links." Regards, Michael Am 21.03.2012 08:25, schrieb Ruediger.Geib@telekom.de: > Hi Tom, hi Michael > > "network running near capacity" is correct if complete links transmit > PCN traffic only. Otherwise, "PCN network capacities running near > congestion (on at least one interface)" is better. That may also > simplify experiments, dedicated tunnels in a live network with > proper marking may suffice. > > Regards, > > Ruediger > > > Tom: >> This document describes an experimental edge node behaviour to >> implement PCN in a network. The experiment may be run in a network in >> which a substantial proportion of the traffic carried is in the form >> of inelastic flows and where admission control of micro-flows is >> applied at the edge. For the effects of PCN to be observable, at least >> some links of the network should be running near or at capacity. > Michael: > Better: "the aggregate rate of admitted flows on some links should come > close to the bandwidths of these links." > -- 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://kn.inf.uni-tuebingen.de From philip.eardley@bt.com Wed Mar 21 04:20:29 2012 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 C137A21F8639 for ; Wed, 21 Mar 2012 04:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.447 X-Spam-Level: X-Spam-Status: No, score=-103.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me+67f9PUXko for ; Wed, 21 Mar 2012 04:20:28 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF7221F8601 for ; Wed, 21 Mar 2012 04:20:28 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 11:20:26 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 21 Mar 2012 11:20:26 +0000 From: To: , Date: Wed, 21 Mar 2012 11:20:28 +0000 Thread-Topic: lets try again - a chair asking this time Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+5Z0XZ2QgAA833A= Message-ID: <9510D26531EF184D9017DF24659BB87F331D442F31@EMV65-UKRD.domain1.systemhost.net> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:20:29 -0000 Good spot! To me, either drop or re-mark to Best effort seem ok. I can see bob's argum= ent that it is nicer internet behaviour to treat as best effort than to dro= p. Adding a mgt alert seems very good. Since it does indeed differ from pcn architecture, i guess it needs a state= ment in the 'header' "Modifies 5559" and something in the Intro (?) that st= ates which para of 5559 is modified in what way.=20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Ruedi= ger.Geib@telekom.de Sent: 21 March 2012 08:08 To: sob@harvard.edu Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time Hi Scott, the passage you quote should result from a misconfiguration or an attack. Treatment of non-PCN-packets confused with a PCN-packet due to DSCP/ECN codepoinzt setting: ... In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. ... Clearing the ECN field is not an appropriate policing action, because a network node ought not to interfere with an e2e signal. Even if such packets seem like an attack, drop would be overkill, because such an attack can be neutralised by just re-marking the DSCP. And DSCP re-marking in the network is legitimate, because the DSCP is not considered an e2e signal. What's done here is remarking of a flow with a DSCP that has been agreed between two parties. On a consumer UNI, this may be an attack, on an NNI, this could indicate a misconfiguration. In the latter case, a management alert seems reasonable. Text to that may be added. I further quote the PCN architecture, which is informational, on the Ingress Node behaviour: Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Similarly, police packets that are part of a previously admitted flow, to check that the flow keeps to the agreed rate or flowspec (eg, see [RFC1633] for a microflow and its NSIS equivalent). This isn't in line with the proposed 3-in-1 (standards track) behaviour. Does this require an "Errata" atatement for RFC5559 (I'm not an expert on editing RFCs and may be wrong here)? Regards, Ruediger ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Bradn= er, Scott Sent: Tuesday, March 20, 2012 5:37 PM To: pcn@ietf.org Subject: [PCN] lets try again - a chair asking this time please let the list know what you think Scott Scott O Bradner Senior Technology Consultant Begin forwarded message: Date: Mon, 12 Mar 2012 03:30:11 +0000 To: "PCN IETF list" From: Bob Briscoe Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt PCN folks, Following IESG review (particularly Adrian Farrel's being t= he most comprehensive and useful), we've posted a new version of the PCN 3-= in-1 encoding. As well as a number of editorial changes, some technical ch= anges were needed in order to satisfy Adrian's request to specify exactly w= hat an implementer has to do at the ingress to allow ECN to co-exist with P= CN, and what defaults should be set to. In particular, for a non-PCN packet (i.e. doesn't match any= flow-state) that clashes with a PCN DSCP and is ECN-capable, the recommend= ed choice of 3 is: * re-mark the DSCP to a DSCP that is not PCN-compati= ble; [...] In the absence of any operator-specific configuration for this case, by default an implementation SHOULD re-mark the DSCP to zero. Actually, the whole of the ingress behaviour section (5.1) = has been re-written, incorporating material that was previously repeated in= both edge-behaviours (agreed with IESG and with edge-behaviour authors, of= course). Altho it largely does the same thing technically, it is written t= o cover the complete range of possible scenarios, and it now gives defaults= and recommended choices. I don't think it's controversial, but shout if it= is. < http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding= -09#section-5.1 > Bob PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: * Added note about fail-safe to protect other traffi= c in the event of tunnel misconfiguration. * Changed section heading to be about applicability = of environments to the encoding, rather than the enco= ding to the environments. * Completely re-wrote PCN-ingress Node Behaviour sec= tion. * Changed PCN interior node to PCN-node where the te= rm was intended to include all PCN-nodes. * Clarified status of ECN/PCN co-existence appendix.= Removed inconsistent assertion in this appendix that an ad= mission- control DSCP alone can indicate that arriving traf= fic is PCN- traffic. * A few clarifying editorial amendments and updated = refs. From: To: , , , , Date: Sun, 11 Mar 2012 17:52:23 -0700 Subject: New Version Notification - draft-ietf-pcn-= 3-in-1-encoding-09.txt New version (-09) has been submitted for draft-ietf= -pcn-3-in-1-encoding-09.txt. http://www.ietf.org/internet-drafts/draft-ietf-pcn-= 3-in-1-encoding-09.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn= -3-in-1-encoding-09 IETF Secretariat. ___________________________________________________________= _____ Bob Briscoe, BT Innovate & D= esign ________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Wed Mar 21 04:24:51 2012 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 0449621F8564 for ; Wed, 21 Mar 2012 04:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.153 X-Spam-Level: X-Spam-Status: No, score=-103.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+696KaBuaMY for ; Wed, 21 Mar 2012 04:24:50 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id F244021F860F for ; Wed, 21 Mar 2012 04:24:47 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 21 Mar 2012 11:24:46 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 21 Mar 2012 11:24:46 +0000 From: To: , , , Date: Wed, 21 Mar 2012 11:24:48 +0000 Thread-Topic: [PCN] lets try again - a chair asking this time Thread-Index: Ac0G4gWtAtt/m20STyycu2O2w/XbHAAcqF/A Message-ID: <9510D26531EF184D9017DF24659BB87F331D442F4E@EMV65-UKRD.domain1.systemhost.net> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <9510D26531EF184D9017DF24659BB87F331D442A7C@EMV65-UKRD.domain1.systemhost.net> <201203202140.q2KLe5ud007565@mtv-core-2.cisco.com> In-Reply-To: <201203202140.q2KLe5ud007565@mtv-core-2.cisco.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] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:24:51 -0000 To add to your nit, I think it may be helpful to add something like "(by default 000000 indicates the best-effort forwarding behaviour)" -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: 20 March 2012 21:40 To: karagian@cs.utwente.nl; Eardley,PL,Philip,DUB8 R; sob@harvard.edu; pcn@= ietf.org Subject: Re: [PCN] lets try again - a chair asking this time I know this is a nit, but shouldn't the text actually read Option #1 "... re-mark the DSCP to 000000." or even Option #2 "... re-mark the DSCP to 0." or even Option #3 "... re-mark the DSCP to zero (000000)." or even Option #4 "... re-mark the DSCP to zero (0)." instead of just "... re-mark the DSCP to zero." ? I prefer Option #1, but am happy with Option #3 over the others. IMO=20 this should not remain as it is. James At 02:25 PM 3/20/2012, karagian@cs.utwente.nl wrote: >Content-Language: nl-NL >Content-Type: multipart/alternative; >=20 >boundary=3D"_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_" > >Hi all, > > > >I think that the changes satisfy nicely the comments of Adrian! > > > >Best regards, > >Georgios > > > > > >---------- >Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens=20 >philip.eardley@bt.com [philip.eardley@bt.com] >Verzonden: dinsdag 20 maart 2012 17:46 >Aan: sob@harvard.edu; pcn@ietf.org >Onderwerp: Re: [PCN] lets try again - a chair asking this time > >Seems good to me. I like the inclusion of material previously in=20 >both the edge behaviour docs > > > >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf=20 >Of Bradner, Scott >Sent: 20 March 2012 16:37 >To: pcn@ietf.org >Subject: [PCN] lets try again - a chair asking this time > > > >please let the list know what you think > > > >Scott > > > >Scott O Bradner > >Senior Technology Consultant > > > >Begin forwarded message: > > > > > >Date: Mon, 12 Mar 2012 03:30:11 +0000 >To: "PCN IETF list" <pcn@ietf.org> >From: Bob Briscoe <bob.briscoe@bt.com> >Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt > >PCN folks, > >Following IESG review (particularly Adrian Farrel's being the most=20 >comprehensive and useful), we've posted a new version of the PCN=20 >3-in-1 encoding. > >As well as a number of editorial changes, some technical changes=20 >were needed in order to satisfy Adrian's request to specify exactly=20 >what an implementer has to do at the ingress to allow ECN to=20 >co-exist with PCN, and what defaults should be set to. > >In particular, for a non-PCN packet (i.e. doesn't match any=20 >flow-state) that clashes with a PCN DSCP and is ECN-capable, the=20 >recommended choice of 3 is: > > * re-mark the DSCP to a DSCP that is not PCN-compatible; > > > > >[...] > >In the > > absence of any operator-specific > >configuration for this case, by > > default an implementation SHOULD re-mark > >the DSCP to zero. > > > > >Actually, the whole of the ingress behaviour section (5.1) has been=20 >re-written, incorporating material that was previously repeated in=20 >both edge-behaviours (agreed with IESG and with edge-behaviour=20 >authors, of course). Altho it largely does the same thing=20 >technically, it is written to cover the complete range of possible=20 >scenarios, and it now gives defaults and recommended choices. I=20 >don't think it's controversial, but shout if it is. >< http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1= > > > > >Bob > >PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: > > * Added note about fail-safe to protect other traffic in the > event of tunnel misconfiguration. > > * Changed section heading to be about applicability of > environments to the encoding, rather than the encoding to the > environments. > > * Completely re-wrote PCN-ingress Node Behaviour section. > > * Changed PCN interior node to PCN-node where the term was > intended to include all PCN-nodes. > > * Clarified status of ECN/PCN co-existence appendix. Removed > inconsistent assertion in this appendix that an admission- > control DSCP alone can indicate that arriving traffic is PCN- > traffic. > > * A few clarifying editorial amendments and updated refs. > > > > >From: <internet-drafts@ietf.org> >To: <pcn-chairs@tools.ietf.org>, >=20 ><draft-ietf-pcn-3-in= -1-encoding@tools.ietf.org>,=20 ><ietfdbh@comcast.net>, > <adrian@olddog.co.uk>,=20 > <rjsparks@nostrum.com> >Date: Sun, 11 Mar 2012 17:52:23 -0700 >Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt > >New version (-09) has been submitted for=20 >draft-ietf-pcn-3-in-1-encoding-09.txt. >http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt= =20 > > > >Diff from previous version: >ht= tp://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09=20 > > >IETF Secretariat. > > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From tom.taylor.stds@gmail.com Wed Mar 21 05:18:11 2012 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 DF37E21F86E0 for ; Wed, 21 Mar 2012 05:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHFkTRSupwLL for ; Wed, 21 Mar 2012 05:18:11 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 450F021F86DF for ; Wed, 21 Mar 2012 05:18:11 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so782302obb.31 for ; Wed, 21 Mar 2012 05:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=l1EMH3AnudsfC2/SV/guwrf0JngI3w6LdOQfqAN2Pec=; b=gQVSYxfAlmslydFdgasn8T/Doj/4/KCLvznlcpcnkzQBhS38oB4jW8Etg628TA52gL LOXC03tfTg7lMoOBMx0tSCzXAM6Ey2LId2d8WBWyGdCdOL1zCa+MuEZXRxldUQuzcNHz SKpXf4oG3Ffx9h76Jmr/3IzMf0ecF26SPIDio3bz/EMIK9eb/hL10FoQBPIcePFR53zV ZFXIRbifWLJfPxDSkwfpiEBbvCgDPCMBE/SmLO9hQx/ATMDE9kFaAF0OmM8hpp4BXaEQ gk32OGngizctpP6RZMgKzlNmPKxFnuzgUATMmgQQfFTtDOHrnCcriqBsQXHvcslDi6BJ lZMQ== Received: by 10.182.174.101 with SMTP id br5mr4567399obc.0.1332332290883; Wed, 21 Mar 2012 05:18:10 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id v9sm1448141obo.9.2012.03.21.05.18.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 05:18:10 -0700 (PDT) Message-ID: <4F69C700.5090600@gmail.com> Date: Wed, 21 Mar 2012 08:18:08 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Michael Menth References: <4F68E62E.9080502@gmail.com> <4F68EDF1.8070004@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A6FC9@HE111648.emea1.cds.t-internal.com> <4F698D41.3010309@informatik.uni-tuebingen.de> In-Reply-To: <4F698D41.3010309@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120321-0, 21/03/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behaviour experiment 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, 21 Mar 2012 12:18:12 -0000 I did rework the wording to capture Ruediger's sense. Michael, your wording assumes that PCN is already running on the network, where in this case one is examining a network as a prospect for a PCN experiment. On 21/03/2012 4:11 AM, Michael Menth wrote: > Hi Ruediger, hi Tom! > > Ruediger, you are right. The text should be > > "the aggregate rate of admitted flows on some links should come > close to the *admissible rates* of these links." > > Regards, > > Michael > > Am 21.03.2012 08:25, schrieb Ruediger.Geib@telekom.de: >> Hi Tom, hi Michael >> >> "network running near capacity" is correct if complete links transmit >> PCN traffic only. Otherwise, "PCN network capacities running near >> congestion (on at least one interface)" is better. That may also >> simplify experiments, dedicated tunnels in a live network with >> proper marking may suffice. >> >> Regards, >> >> Ruediger >> >> >> Tom: >>> This document describes an experimental edge node behaviour to >>> implement PCN in a network. The experiment may be run in a network in >>> which a substantial proportion of the traffic carried is in the form >>> of inelastic flows and where admission control of micro-flows is >>> applied at the edge. For the effects of PCN to be observable, at least >>> some links of the network should be running near or at capacity. >> Michael: >> Better: "the aggregate rate of admitted flows on some links should come >> close to the bandwidths of these links." >> > From tom.taylor.stds@gmail.com Wed Mar 21 12:08:41 2012 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 8883321E80B0 for ; Wed, 21 Mar 2012 12:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4C7E2uxLIFry for ; Wed, 21 Mar 2012 12:08:40 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E500C21F8601 for ; Wed, 21 Mar 2012 12:08:39 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1401762ggm.31 for ; Wed, 21 Mar 2012 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=/DfqUvObih4S/3r5YWmXOZC732fQi6vXZzjYdDiHcgg=; b=GeVmUDAgszkw6LrDTDXxWrMfBqjliSkkeXCJKU1yqBFc4bLYjb+ETZbsgMuyJpja8O qyCBZS5S36Np9EoI8fl2n94BmUm1vigxDqu7Uos9SVoPM5tiAdO+q78t9Of6qUb0Q2En /UGdcxN2icqDW7+CUlxzYlFsu509cWoTbGBs0H/bKaWg/9A3T0zdmN+i31ODYt/OAdg0 p197bZ3xzwzeXAFKlRD/3kxIiSD4m+gHUQi5/DYuToefdHpCkvxmOVj0Bw/Fgvr2kbks S8rCrDz5OP5/jJ3bpt8NIdkt36XQs9X9d3DAxZEEM6H0I3DMJR3vtyNSyN8aDRQPDLak 5RDQ== Received: by 10.236.144.134 with SMTP id n6mr5208186yhj.45.1332356919438; Wed, 21 Mar 2012 12:08:39 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id 2sm3253127ane.12.2012.03.21.12.08.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:08:38 -0700 (PDT) Message-ID: <4F6A2736.8040403@gmail.com> Date: Wed, 21 Mar 2012 15:08:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pcn , David Harrington Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120321-0, 21/03/2012), Outbound message X-Antivirus-Status: Clean Subject: [PCN] Explanation of changes in the PCN edge behaviour drafts 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, 21 Mar 2012 19:08:41 -0000 All changes apply to both documents except for the change in description of the factor U, which is SM-specific. David, you may not have been aware of the need for item 10. Please verify that it is OK. Hope everyone is happy with the changes. Please note additional fixes called out at the end of item 13. I think these can be taken care of in AUTH 48. Changes 1. Added text in the introduction to describe the experiment (requested by Pete Resnick). 2. Lower-cased a MUST in the paragraph following the new text, talking about the need to fill out a per-hop behaviour template. (Part of an attempt to clean out unnecessary RFC 2119 language mentioned by two ADs.) 3. Trivial: replaced all t- and T- names for timers and durations with t_ and T_ as suggested by Stephen Farrell to avoid confusion with arithmetic operations. (Actually missed a few in the CL draft and will have to get them in AUTH 48.) 4. First line of Section 3.2.1: replaced "MUST" with "needs to" for metering. Changed "informational note" to "Note" after the bullets (both at Pete Resnick's suggestion). 5. Section 3.3, first paragraph, talking about support of flow admission and termination mechanisms: changed "A Decision Point MUST support both mechanisms, but ..." to "If a Decision Point supports both mechanisms, ...". (Pete Resnick -- couldn't see any interoperability issue to justify the MUST.) 6. Section 3.3.3, talking about failure to receive a response from the ingress node. Rewrote in an attempt both to satisfy Pete Resnick's concern about over-use of mandatory language and to make the mandatory procedures clearer. OLD A centralized Decision Point SHOULD start a timer t-sndFail when it sends a request for the estimated value of PCN-sent-rate to a given PCN-ingress-node. If the Decision Point fails to receive a response from the PCN-ingress-node before t-sndFail reaches the configurable value T-crit, the Decision Point SHOULD repeat the request but MAY also use ETM-rate as an estimate of the amount of traffic to be terminated in place of the quantity PCN-sent-rate - SAR specified in Section 3.3.2. Because this will over-estimate the amount of traffic to be terminated due to dropping of PCN-packets by interior nodes, the Decision Point SHOULD use multiple rounds of termination under these circumstances. If the second request to the PCN-ingress-node also fails, the Decision Point SHOULD notify management. The use of T-crit is an approximation. A more precise limit would be of the order of two round-trip times, plus an allowance for processing at each end, plus an allowance for variance in these values. NEW If a centralized Decision Point sends a request for the estimated value of PCN-sent-rate to a given PCN-ingress-node and fails to receive a response in a reasonable amount of time, the Decision Point SHOULD repeat the request once. While waiting after sending this second request, the Decision Point MAY begin selecting flows to terminate, using ETM-rate as an estimate of the amount of traffic to be terminated in place of the quantity PCN-sent-rate - SAR specified in Section 3.3.2. Because ETM-rate will over-estimate the amount of traffic to be terminated due to dropping of PCN-packets by interior nodes, the Decision Point SHOULD terminate less than the full amount ETM-rate in the first pass and recalculate the additional amount to terminate in additional passes based on subsequent reports from the PCN-egress-node. If the second request to the PCN-ingress- node also fails, the Decision Point MUST select flows to terminate based on the ETM-rate approximation as just described and should notify management. The response timer t_sndFail with upper bound T_crit is specified in Section 3.5. The use of T_crit is an approximation. A more precise limit would be of the order of two round-trip times, plus an allowance for processing at each end, plus an allowance for variance in these values. 7. Section 3.4, note giving an example of how the PCN-ingress-node does its estimate: changed the "MAY" to a "can". 8. Section 3.5, action for expiry of t_sndFail: referred back to Section 3.3.3 instead of the previous inaccurate summary of a fairly complex procedure. 9. Removed all RFC 2119 language from Section 4 (the per-hop behaviour section). Originally responding to a comment by Sean Turner that Section 4.2.1 claimed to paraphrase RFC 5559 but had such language where RFC 5559 did not. Decided that it wasn't necessary elsewhere in the section, either. 10. Based on discussion of the 3-in-1 draft, at Bob Briscoe's request, changed section 4.2.1 to focus only on the tunneling option and the resulting non-problem with use of ECN bits. OLD Packets at the ingress to the domain are classified as either PCN or non-PCN. Non-PCN packets MAY share the network with PCN packets within the domain. Because the encoding specified in [RFC5696] and used in this document requires the use of the ECN fields, PCN- ingress-nodes MUST prevent ECN-capable traffic that uses the same DSCP as PCN from entering the PCN-domain directly. The PCN-ingress- node can accomplish this in three ways. The choice between these depends on local policy. o ECN-capable traffic MAY be dropped. This policy is NOT RECOMMENDED, since it prevents the proper operation of end-to-end ECN as a means of controlling congestion. o ECN-capable traffic MAY be assigned a different DSCP from PCN traffic. This could mean that it is relegated to a lower-priority behaviour aggregate. o ECN-capable traffic MAY be tunneled across the PCN-domain. If this is done, the PCN-ingress-node MUST mark packets as either not-PCN or PCN-not-marked only after the encapsulation of the packet, including any initial setting of the ECN field, has been completed. NEW Packets at the ingress to the domain are classified as either PCN or non-PCN. Non-PCN packets can share the network with PCN packets within the domain. The encoding specified in [RFC5696] and used in this document requires the use of the ECN fields. PCN-ingress-nodes need to prevent ECN-capable traffic that uses the same DSCP as PCN from entering the PCN-domain directly. This is not an issue when tunneling of PCN-packets between the PCN-ingress-node and the PCN- egress-node is done, as recommended in Section 5.1.2, provided that the original ECN markings of arriving packets are preserved in the encapsulated headers. 11. In the next paragraph, originally said that PCN packets of non-admitted flows are dropped. Replaced this with "blocked" and a backward reference to the definition of blocking in Section 1. (Follow-through on comments by Brian Carpenter, fixed elsewhere. 12. Section 4.7: originally said PCN use of ECN bits could interfere with the end-to-end use of ECN. Replaced with the following text: The PCN CL per-domain behaviour could theoretically interfere with the use of end-to-end ECN due to reuse of ECN bits for PCN marking. However, this is not a problem in practice because of the need to tunnel PCN-packets from ingress to egress (see Section 5.1.2). The encapsulated header can retain the original ECN markings as received at the PCN-ingress-node, leaving the ECN bits in the encapsulating header fully available for use by PCN. 13. Section 5.1.3, basically editorial rearrangement of text to take account of the fact that the ingress node will always perform encapsulation. Talking about extensions to the DiffServ MIB. OLD ... The required extensions specifically include objects for re-marking the ECN field at the PCN-ingress-node and an extension to the classifiers to include the ECN field at PCN-interior and PCN-egress-nodes. In addition, the MIB has to be extended to include a potential encapsulation action following re-classification by ingress-egress- aggregate. Finally, a new metering algorithm may need to be defined at the PCN-interior-nodes to handle excess-traffic-marking. NEW ... The required extensions specifically include an encapsulation action following re- classification by ingress-egress-aggregate. In addition, the MIB has to be extended to include objects for marking the ECN field in the outer header at the PCN-ingress-node and an extension to the classifiers to include the ECN field at PCN-interior and PCN-egress- nodes. Finally, new metering algorithms may need to be defined at the PCN-interior-nodes to handle threshold-marking and packet-size- independent excess-traffic-marking. *Oops noted* -- that text was taken from the SM document. Have to remove the reference to threshold-marking, and have to mark that point "[CL-specific]" in the CL document. *Speaking of oops*: Section 5.1.1 still talks about the operator having to decide whether to use tunneling. Should that stay or go? 14. Security consideration added (Section 6), in response to comments by two ADs. Section now reads: [RFC5559] provides a general description of the security considerations for PCN. This memo introduces one new consideration, related to the use of a centralized Decision Point. The Decision Point itself is a trusted entity. However, its use implies the existence of an interface on the PCN-ingress-node through which communication of policy decisions takes place. That interface is a point of vulnerability which must be protected from denial of service attacks. 15. Fixed reference Mele12, naming the journal in which the article will appear. 16. SM-specific change in Section 3.3.2 to improve the description of the factor U. The new text reads: 1. [SM-specific] The sustainable aggregate rate (SAR) for the given ingress-egress-aggregate is estimated using the formula: SAR = U * NM-Rate for the latest reported interval, where U is a configurable factor greater than one which is the same for all ingress-egress- aggregates. In effect, the value of the PCN-supportable-rate for each link is approximated by the expression U*PCN-admissible-rate rather than being calculated explicitly. From menth@informatik.uni-tuebingen.de Wed Mar 21 14:14:55 2012 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 CA06421F873D for ; Wed, 21 Mar 2012 14:14:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdDryuqGYEfn for ; Wed, 21 Mar 2012 14:14:54 -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 5ECC721E8013 for ; Wed, 21 Mar 2012 14:14:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id CEBE45317; Wed, 21 Mar 2012 22:14:52 +0100 (MET) 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 6K4Uc00eW-J4; Wed, 21 Mar 2012 22:14:44 +0100 (MET) Received: from zcs-pu.informatik.uni-tuebingen.de (zcs-pu.Informatik.Uni-Tuebingen.De [134.2.12.61]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 933B05291; Wed, 21 Mar 2012 22:14:44 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-46-223-71-166.hsi.kabel-badenwuerttemberg.de [46.223.71.166]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3CFF21855DDC; Wed, 21 Mar 2012 22:14:44 +0100 (CET) Message-ID: <4F6A44C3.20506@informatik.uni-tuebingen.de> Date: Wed, 21 Mar 2012 22:14:43 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Tom Taylor References: <4F6A2736.8040403@gmail.com> In-Reply-To: <4F6A2736.8040403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Explanation of changes in the PCN edge behaviour drafts 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, 21 Mar 2012 21:14:55 -0000 Hi Tom, > Changes > > 1. Added text in the introduction to describe the experiment > (requested by Pete Resnick). * committed bandwidth is strange, you mean the rate of admitted traffic * link capacity is wrong, this should be admissible rate * a long duration of the experiment is not needed if pre-congestion is caused intentionally > 6. Section 3.3.3, talking about failure to receive a response from the > ingress node. Rewrote in an attempt both to satisfy Pete Resnick's > concern about over-use of mandatory language and to make the mandatory > procedures clearer. > > OLD > > A centralized Decision Point SHOULD start a timer t-sndFail when it > sends a request for the estimated value of PCN-sent-rate to a given > PCN-ingress-node. If the Decision Point fails to receive a response > from the PCN-ingress-node before t-sndFail reaches the configurable > value T-crit, the Decision Point SHOULD repeat the request but MAY > also use ETM-rate as an estimate of the amount of traffic to be > terminated in place of the quantity > > PCN-sent-rate - SAR > > specified in Section 3.3.2. Because this will over-estimate the > amount of traffic to be terminated due to dropping of PCN-packets by > interior nodes, the Decision Point SHOULD use multiple rounds of > termination under these circumstances. If the second request to the > PCN-ingress-node also fails, the Decision Point SHOULD notify > management. > > The use of T-crit is an approximation. A more precise limit would > be of the order of two round-trip times, plus an allowance for > processing at each end, plus an allowance for variance in these > values. > > NEW > > If a centralized Decision Point sends a request for the estimated > value of PCN-sent-rate to a given PCN-ingress-node and fails to > receive a response in a reasonable amount of time, the Decision Point > SHOULD repeat the request once. While waiting after sending this > second request, the Decision Point MAY begin selecting flows to > terminate, using ETM-rate as an estimate of the amount of traffic to > be terminated in place of the quantity > > PCN-sent-rate - SAR Using ETM-Rate instead of (PCN-sent-rate - SAR) may be a correct workaround for CL but not for SM! With SM, the PCN traffic rate is terminated down to the admissible rate in the absence of traffic loss. The approach corresponding to CL would be (NM-Rate + ETM-Rate - SAR). > > specified in Section 3.3.2. Because ETM-rate will over-estimate the > amount of traffic to be terminated due to dropping of PCN-packets by > interior nodes, the Decision Point SHOULD terminate less than the > full amount ETM-rate in the first pass and recalculate the additional > amount to terminate in additional passes based on subsequent reports > from the PCN-egress-node. If the second request to the PCN-ingress- > node also fails, the Decision Point MUST select flows to terminate > based on the ETM-rate approximation as just described and should > notify management. > > The response timer t_sndFail with upper bound T_crit is specified > in Section 3.5. The use of T_crit is an approximation. A more > precise limit would be of the order of two round-trip times, plus > an allowance for processing at each end, plus an allowance for > variance in these values. This works for CL but not for SM, see my previous email! > NEW > > Packets at the ingress to the domain are classified as either PCN or > non-PCN. Non-PCN packets can share the network with PCN packets > within the domain. The encoding specified in [RFC5696] and used in > this document requires the use of the ECN fields. PCN-ingress-nodes > need to prevent ECN-capable traffic that uses the same DSCP as PCN > from entering the PCN-domain directly. This is not an issue when > tunneling of PCN-packets between the PCN-ingress-node and the PCN- > egress-node is done, as recommended in Section 5.1.2, provided that > the original ECN markings of arriving packets are preserved in the > encapsulated headers. Moving the old text to 3-in-1 means that this doc is now aware of 3-in-1. Therefore, we should base this edge behavior no longer on baseline encoding (RFC5696) but on 3-in-1. > > 11. In the next paragraph, originally said that PCN packets of > non-admitted flows are dropped. Replaced this with "blocked" and a > backward reference to the definition of blocking in Section 1. > (Follow-through on comments by Brian Carpenter, fixed elsewhere. I think to remember that 3-in-1 recommended recoloring as preferred policing option. > 13. Section 5.1.3, basically editorial rearrangement of text to take > account of the fact that the ingress node will always perform > encapsulation. Talking about extensions to the DiffServ MIB. > > OLD > > ... The required > extensions specifically include objects for re-marking the ECN field > at the PCN-ingress-node and an extension to the classifiers to > include the ECN field at PCN-interior and PCN-egress-nodes. In > addition, the MIB has to be extended to include a potential > encapsulation action following re-classification by ingress-egress- > aggregate. Finally, a new metering algorithm may need to be defined > at the PCN-interior-nodes to handle excess-traffic-marking. > > NEW > > ... The required > extensions specifically include an encapsulation action following re- > classification by ingress-egress-aggregate. In addition, the MIB which MIB? > has > to be extended to include objects for marking the ECN field in the > outer header at the PCN-ingress-node and an extension to the > classifiers to include the ECN field at PCN-interior and PCN-egress- > nodes. Finally, new metering algorithms may need to be defined at > the PCN-interior-nodes to handle threshold-marking and packet-size- > independent excess-traffic-marking. I do not understand why the defined marking algorithms are not sufficient. Also packet-size-independent excess-traffic-marking is defined (see 2.4 in RFC5670). 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://kn.inf.uni-tuebingen.de From tom.taylor.stds@gmail.com Wed Mar 21 14:47:42 2012 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 8BD9821E80EA for ; Wed, 21 Mar 2012 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eYHADxIule4 for ; Wed, 21 Mar 2012 14:47:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0AB921E80DC for ; Wed, 21 Mar 2012 14:47:41 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1511879yhk.31 for ; Wed, 21 Mar 2012 14:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=T+3Bt9JC404Iz+3G+f9wM4QdvaxHxVPjdAhBmzWqKto=; b=a/z5W8tmTKXdvkKKInYzVSX0K283leOcuDSqZ0uJKUkXbBMBhN2h6KHJg1hwxyuFzn vgiNXEtGa5AODnmX7zANvNnZVG2OjVkIYtbS3ZEjttgfUGKjjgITPR/dxQRt25nSgQit gdUacD35vzLncaoy1DR1GAdMvRTUX1bG8SLu2Lci9hZfMPaZVt18FRB+hOSv0cbhUk0D L2oJxnWd8lLve1Yu/E1IKl69XZNBC3rmTFSM23PbbRzw+ZL5AU2HhEagDALEES4iV102 /n9EnEc9Hxku/ETGVDFTeeEhH3NI0llGXlQixhlOzIj0s6x6W6tM8DOsfNtxn7kWPSAm qE4Q== Received: by 10.236.78.72 with SMTP id f48mr5587020yhe.121.1332366461374; Wed, 21 Mar 2012 14:47:41 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id d25sm7706006yhe.4.2012.03.21.14.47.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 14:47:40 -0700 (PDT) Message-ID: <4F6A4C7B.8050607@gmail.com> Date: Wed, 21 Mar 2012 17:47:39 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Michael Menth References: <4F6A2736.8040403@gmail.com> <4F6A44C3.20506@informatik.uni-tuebingen.de> In-Reply-To: <4F6A44C3.20506@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120321-1, 21/03/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn Subject: Re: [PCN] Explanation of changes in the PCN edge behaviour drafts 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, 21 Mar 2012 21:47:42 -0000 My comments in turn below, marked with [PTT]. David, we have a technical error in the SM document, introduced in the -06 version. Can I update it and resubmit? Tom Taylor On 21/03/2012 5:14 PM, Michael Menth wrote: > Hi Tom, > >> Changes >> >> 1. Added text in the introduction to describe the experiment >> (requested by Pete Resnick). > * committed bandwidth is strange, you mean the rate of admitted traffic > * link capacity is wrong, this should be admissible rate [PTT] That terminology is appropriate once PCN is running, but when you are evaluating a network in advance of installing PCN, I don't think you can talk about admissible rate. > * a long duration of the experiment is not needed if pre-congestion is > caused intentionally > [PTT] I thought hard about that, then decided operators might not be willing to do it. They would be throwing away customer revenue, or at least violating the terms of an SLA. > >> 6. Section 3.3.3, talking about failure to receive a response from the >> ingress node. Rewrote in an attempt both to satisfy Pete Resnick's >> concern about over-use of mandatory language and to make the mandatory >> procedures clearer. >> ... > This works for CL but not for SM, see my previous email! > [PTT] You are absolutely right. This comes from working on CL first, then cutting and pasting. The bad text has been there since the -06 version. I'll have to back it out to what was there in -05: no workaround, just notify management. >> NEW >> >> Packets at the ingress to the domain are classified as either PCN or >> non-PCN. Non-PCN packets can share the network with PCN packets >> within the domain. The encoding specified in [RFC5696] and used in >> this document requires the use of the ECN fields. PCN-ingress-nodes >> need to prevent ECN-capable traffic that uses the same DSCP as PCN >> from entering the PCN-domain directly. This is not an issue when >> tunneling of PCN-packets between the PCN-ingress-node and the PCN- >> egress-node is done, as recommended in Section 5.1.2, provided that >> the original ECN markings of arriving packets are preserved in the >> encapsulated headers. > Moving the old text to 3-in-1 means that this doc is now aware of > 3-in-1. Therefore, we should base this edge behavior no longer on > baseline encoding (RFC5696) but on 3-in-1. > [PTT] I don't think we have to, although it might be reasonable. The argument is that there is no need for the old text because we are using tunneling. >> >> 11. In the next paragraph, originally said that PCN packets of >> non-admitted flows are dropped. Replaced this with "blocked" and a >> backward reference to the definition of blocking in Section 1. >> (Follow-through on comments by Brian Carpenter, fixed elsewhere. > I think to remember that 3-in-1 recommended recoloring as preferred > policing option. [PTT] We agreed on local policy as the answer when discussing Brian Carpenter's review comments. > >> 13. Section 5.1.3, basically editorial rearrangement of text to take >> account of the fact that the ingress node will always perform >> encapsulation. Talking about extensions to the DiffServ MIB. >> >> OLD >> >> ... The required >> extensions specifically include objects for re-marking the ECN field >> at the PCN-ingress-node and an extension to the classifiers to >> include the ECN field at PCN-interior and PCN-egress-nodes. In >> addition, the MIB has to be extended to include a potential >> encapsulation action following re-classification by ingress-egress- >> aggregate. Finally, a new metering algorithm may need to be defined >> at the PCN-interior-nodes to handle excess-traffic-marking. >> >> NEW >> >> ... The required >> extensions specifically include an encapsulation action following re- >> classification by ingress-egress-aggregate. In addition, the MIB > which MIB? [PTT] DiffServ MIB [RFC3289], referenced in the document. > >> has >> to be extended to include objects for marking the ECN field in the >> outer header at the PCN-ingress-node and an extension to the >> classifiers to include the ECN field at PCN-interior and PCN-egress- >> nodes. Finally, new metering algorithms may need to be defined at >> the PCN-interior-nodes to handle threshold-marking and packet-size- >> independent excess-traffic-marking. > I do not understand why the defined marking algorithms are not > sufficient. Also packet-size-independent excess-traffic-marking is > defined (see 2.4 in RFC5670). > The above passage is talking about whether the DiffServ MIB supports the defined marking algorithms, not saying that new algorithms are needed. > Regards, > > Michael > From menth@informatik.uni-tuebingen.de Wed Mar 21 16:52:41 2012 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 B1A2521E8130 for ; Wed, 21 Mar 2012 16:52:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWF32ZYpA60R for ; Wed, 21 Mar 2012 16:52:40 -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 421B921E8123 for ; Wed, 21 Mar 2012 16:52:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id CA4F25322; Thu, 22 Mar 2012 00:52:38 +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 eJTeL6RhGjXF; Thu, 22 Mar 2012 00:52:31 +0100 (MET) 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 058BB512E; Thu, 22 Mar 2012 00:52:30 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-46-223-71-166.hsi.kabel-badenwuerttemberg.de [46.223.71.166]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6137C18566B7; Thu, 22 Mar 2012 00:52:25 +0100 (CET) Message-ID: <4F6A69B8.6010601@informatik.uni-tuebingen.de> Date: Thu, 22 Mar 2012 00:52:24 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Tom Taylor References: <4F6A2736.8040403@gmail.com> <4F6A44C3.20506@informatik.uni-tuebingen.de> <4F6A4C7B.8050607@gmail.com> In-Reply-To: <4F6A4C7B.8050607@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Explanation of changes in the PCN edge behaviour drafts 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, 21 Mar 2012 23:52:41 -0000 Hi Tom, Am 21.03.2012 22:47, schrieb Tom Taylor: > My comments in turn below, marked with [PTT]. > > David, we have a technical error in the SM document, introduced in the > -06 version. Can I update it and resubmit? > > Tom Taylor > > On 21/03/2012 5:14 PM, Michael Menth wrote: >> Hi Tom, >> >>> Changes >>> >>> 1. Added text in the introduction to describe the experiment >>> (requested by Pete Resnick). >> * committed bandwidth is strange, you mean the rate of admitted traffic >> * link capacity is wrong, this should be admissible rate > > [PTT] That terminology is appropriate once PCN is running, but when > you are evaluating a network in advance of installing PCN, I don't > think you can talk about admissible rate. But when you deploy PCN for the sake of an experiment, then you can. > >> * a long duration of the experiment is not needed if pre-congestion is >> caused intentionally >> > [PTT] I thought hard about that, then decided operators might not be > willing to do it. They would be throwing away customer revenue, or at > least violating the terms of an SLA. But when you want to perform the experiment, then you want to experience challenging conditions. Maybe in a testbed to avoid losing revenues. >> >>> 6. Section 3.3.3, talking about failure to receive a response from the >>> ingress node. Rewrote in an attempt both to satisfy Pete Resnick's >>> concern about over-use of mandatory language and to make the mandatory >>> procedures clearer. >>> > ... > >> This works for CL but not for SM, see my previous email! >> > [PTT] You are absolutely right. This comes from working on CL first, > then cutting and pasting. The bad text has been there since the -06 > version. I'll have to back it out to what was there in -05: no > workaround, just notify management. > >>> NEW >>> >>> Packets at the ingress to the domain are classified as either PCN or >>> non-PCN. Non-PCN packets can share the network with PCN packets >>> within the domain. The encoding specified in [RFC5696] and used in >>> this document requires the use of the ECN fields. PCN-ingress-nodes >>> need to prevent ECN-capable traffic that uses the same DSCP as PCN >>> from entering the PCN-domain directly. This is not an issue when >>> tunneling of PCN-packets between the PCN-ingress-node and the PCN- >>> egress-node is done, as recommended in Section 5.1.2, provided that >>> the original ECN markings of arriving packets are preserved in the >>> encapsulated headers. >> Moving the old text to 3-in-1 means that this doc is now aware of >> 3-in-1. Therefore, we should base this edge behavior no longer on >> baseline encoding (RFC5696) but on 3-in-1. >> > [PTT] I don't think we have to, although it might be reasonable. The > argument is that there is no need for the old text because we are > using tunneling. I'd suggest to substitute RFC5696 by 3-in-1 in general to avoid confusion by a soon obsoleted RFC. >>> >>> 11. In the next paragraph, originally said that PCN packets of >>> non-admitted flows are dropped. Replaced this with "blocked" and a >>> backward reference to the definition of blocking in Section 1. >>> (Follow-through on comments by Brian Carpenter, fixed elsewhere. >> I think to remember that 3-in-1 recommended recoloring as preferred >> policing option. > > [PTT] We agreed on local policy as the answer when discussing Brian > Carpenter's review comments. >> >>> 13. Section 5.1.3, basically editorial rearrangement of text to take >>> account of the fact that the ingress node will always perform >>> encapsulation. Talking about extensions to the DiffServ MIB. >>> >>> OLD >>> >>> ... The required >>> extensions specifically include objects for re-marking the ECN field >>> at the PCN-ingress-node and an extension to the classifiers to >>> include the ECN field at PCN-interior and PCN-egress-nodes. In >>> addition, the MIB has to be extended to include a potential >>> encapsulation action following re-classification by ingress-egress- >>> aggregate. Finally, a new metering algorithm may need to be defined >>> at the PCN-interior-nodes to handle excess-traffic-marking. >>> >>> NEW >>> >>> ... The required >>> extensions specifically include an encapsulation action following re- >>> classification by ingress-egress-aggregate. In addition, the MIB >> which MIB? > > [PTT] DiffServ MIB [RFC3289], referenced in the document. ok, now I see the reference was some sentences before >> >>> has >>> to be extended to include objects for marking the ECN field in the >>> outer header at the PCN-ingress-node and an extension to the >>> classifiers to include the ECN field at PCN-interior and PCN-egress- >>> nodes. Finally, new metering algorithms may need to be defined at >>> the PCN-interior-nodes to handle threshold-marking and packet-size- >>> independent excess-traffic-marking. >> I do not understand why the defined marking algorithms are not >> sufficient. Also packet-size-independent excess-traffic-marking is >> defined (see 2.4 in RFC5670). >> > The above passage is talking about whether the DiffServ MIB supports > the defined marking algorithms, not saying that new algorithms are > needed. ok, understand Regards, Michael > >> 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://kn.inf.uni-tuebingen.de From philip.eardley@bt.com Thu Mar 22 04:47:38 2012 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 39F7921F86AF; Thu, 22 Mar 2012 04:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pivNLLjgvORf; Thu, 22 Mar 2012 04:47:37 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B521F86AB; Thu, 22 Mar 2012 04:47:37 -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.213.0; Thu, 22 Mar 2012 11:47:36 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Thu, 22 Mar 2012 11:47:35 +0000 From: To: , Date: Thu, 22 Mar 2012 11:47:37 +0000 Thread-Topic: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt Thread-Index: Acz+8cwlNKtsPKipTKixKfQ/EPSp4AJKnqKg Message-ID: <9510D26531EF184D9017DF24659BB87F331D4BE860@EMV65-UKRD.domain1.systemhost.net> References: <20120310191250.10652.27259.idtracker@ietfa.amsl.com> In-Reply-To: <20120310191250.10652.27259.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [PCN] I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.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, 22 Mar 2012 11:47:38 -0000 SGksDQoNClNvcnJ5LCBJIGhhZCBzb21lIHByb2JsZW1zIHVuZGVyc3RhbmRpbmcgdGhlIGRyYWZ0 LiBJIHNwZW50IGEgY291cGxlIG9mIGhvdXJzIGFuZCBiYXNpY2FsbHkgY291bGRu4oCZdCBnZXQg YSBtZW50YWwgbW9kZWwgd2hhdCB0aGUgbWVjaGFuaXNtIGlzLiBpcyB0aGVyZSBhIHByZXNlbnRh dGlvbiB0aGF0IGNvdWxkIGhlbHAgbWUgdW5kZXJzdGFuZD8NCg0KU3VnZ2VzdCB5b3UgaW5jbHVk ZSBhIHByb2JsZW0gc3RhdGVtZW50LiBTb21ldGhpbmcgc2ltaWxhciB0byBTMS4xIG9mIHJmYzMx NzUgKFJTVlAgcmVzZXJ2YXRpb24gYWdncmVnYXRpb24pLiBGcm9tIGEgUENOIHBlcnNwZWN0aXZl LCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgcHVycG9zZS4gSXMgaXQgc2F2aW5nIHNvbWV0aGlu ZyAoc2lnbmFsbGluZz8pIHRoYXQgY291bGQgYmUgZG9uZSBpbiBhIGxlc3MgZWZmaWNpZW50IHdh eSB3aXRob3V0IHRoaXMgZG9jPyBPciBhY2hpZXZpbmcgc29tZXRoaW5nIGltcG9zc2libGUgd2l0 aG91dCBpdD8NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB5b3UgYnVpbGQgb24gNDg2MCAoZ2Vu ZXJpYyBhZ2dyZWdhdGUgcmVzZXJ2YXRpb25zKSByYXRoZXIgdGhhbiAzMTc1IChhZ2dyZWdhdGUg cmVzZXJ2YXRpb25zKQ0KDQpJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIG91dGxpbmUgdGhlIG92ZXJh bGwgYXJjaGl0ZWN0dXJlLiBGaWcgMSBoZWxwcyBhIGJpdCwgYnV0IEkgdGhpbmsgaXQgd291bGQg YmUgdmVyeSB1c2VmdWwgdG8gZ2l2ZSBleGFtcGxlcyBvZiBzaWduYWxsaW5nIGZvciB0aGUgYmFz aWMgY2FzZXMgKEkgcm91Z2hseSBndWVzcyB0aGVzZSBhcmUgd2hlbiB0aGVyZSBhcmUgZTJlIHJz dnAgbXNncyBmb3IgYSBuZXcgZmxvdyBhbmQgWzFdIHRoZXJlIGlzIGFscmVhZHkgUENOLXN0YXRl IGZvciB0aGUgcmVsZXZhbnQgcGFpciBvZiBQQ04tYm91bmRhcnktbm9kZXM7IFsyXSB3aGVuIHRo ZXJlIGlzbid0LikgVGhhdCB3b3VsZCBoZWxwIHNob3cgaG93IFBDTiwgUlNWUCBhbmQgZ2VuZXJp YyBhZ2dyZWdhdGVkIHJzdnAgZml0IHRvZ2V0aGVyLiBJIGRpZG4ndCB1bmRlcnN0YW5kIGhvdyAo YXQgd2hhdCBwb2ludCBpbiB5b3VyIHByb2NlZHVyZSkgdGhlIFBDTi1pbmdyZXNzLW5vZGUga25v d3Mgd2hpY2ggaXMgdGhlIHJlbGV2YW50IFBDTi1lZ3Jlc3Mtbm9kZQ0KIA0KSXQgaXMgcXVpdGUg aGFyZCB0byB3b3JrIG91dCBhdCB2YXJpb3VzIHBvaW50cyB3aGV0aGVyIGFkZHJlc3MgbWVhbnMg dGhlIGVuZCBob3N0IG9yIHRoZSBQQ04tYm91bmRhcnktbm9kZSBhZGRyZXNzLiANCg0KSSBmb3Vu ZCB0aGUgbGFzdCBwYXJhcyBvbiBwYWdlIDkgJiAxMCBub3QgdW5kZXJzdGFuZGFibGUgKG1hbnkt dG8tMSBtYXBwaW5nIG9mIHdoYXQtdG8td2hhdD8pLiBOb3RlIHRoYXQgaW5ncmVzcy1lZ3Jlc3Mt YWdncmVnYXRlIGlzICJ0aGUgY29sbGVjdGlvbiBvZiBQQ04tcGFja2V0cyBmcm9tIGFsbCBQQ04t Zmxvd3MgdGhhdCB0cmF2ZWwgaW4gb25lIGRpcmVjdGlvbiBiZXR3ZWVuIGEgc3BlY2lmaWMgcGFp ciBvZiBQQ04tYm91bmRhcnktbm9kZXMiIGFuZCBzb21lIG9mIHRoZSB0ZXh0IHNlZW1lZCB0byBj b250cmFkaWN0IHRoaXMgZGVmaW5pdGlvbi4gSSB0aGluayB5b3UgbWVhbjogImJldHdlZW4gYSBw YXJ0aWN1bGFyIHBhaXIgb2YgUENOLWJvdW5kYXJ5LW5vZGVzIHRoZXJlIE1BWSBiZSBzZXZlcmFs IGdlbmVyaWMgYWdncmVnYXRlIHJlc2VydmF0aW9ucyI/IChJIGRvbid0IHJlYWxseSB1bmRlcnN0 YW5kIHdoeSB5b3UgbWlnaHQgd2FudCB0aGF0KQ0KDQoyLjEuMSAiVGhlIFBIQi1JRCAoUGVyIEhv cCBCZWhhdmlvciBJZGVudGlmaWNhdGlvbiBDb2RlKSB1c2VkLCBTSE9VTEQgYmUgc2V0IGVxdWFs IHRvIFBDTi1jb21wYXRpYmxlIERpZmZzZXJ2IGNvZGVwb2ludChzKS4iIC0gYXJlbuKAmXQgdGhl eSBkaWZmZXJlbnQgbGVuZ3Rocz8gDQoNCkkgdGhpbmsgW2RyYWZ0LWlldGYtcGNuLXNpZ25hbGlu Zy1yZXF1aXJlbWVudHMtMDhdLCBbUkZDNTY3MF0gYW5kIFtSRkM1Njk2XSBhcmUgcHJvYmFibHkg SW5mb3JtYXRpdmUgcmVmcyAocmF0aGVyIHRoYW4gbm9ybWF0aXZlKSwgYW5kIHBlcmhhcHMgW1JG QzU1NTldIGlzIE5vcm1hdGl2ZSByYXRoZXIgdGhhbiBJbmZvcm1hdGl2ZS4NCg0KSWYgeW91IGhh dmUgdGltZSwgaXQgd291bGQgYmUgZ29vZCB0byBmaW5kIGEgY29ybmVyIGluIFBhcmlzIHNvIHlv dSBjYW4gZXhwbGFpbiBpdCB0byBtZSAtIHRoYW5rcyENCg0KQmVzdCB3aXNoZXMNCnBoaWwNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRzdndnLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnDQpTZW50OiAxMCBNYXJjaCAyMDEyIDE5OjEzDQpUbzogaS1kLWFubm91bmNl QGlldGYub3JnDQpDYzogdHN2d2dAaWV0Zi5vcmcNClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtdHN2d2ctcnN2cC1wY24tMDEudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLiBU aGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdy b3VwIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCglUaXRsZSAgICAgICAgICAgOiBHZW5l cmljIEFnZ3JlZ2F0aW9uIG9mIFJlc291cmNlIFJlU2VyVmF0aW9uIFByb3RvY29sIChSU1ZQKSBm b3IgSVB2NCBBbmQgSVB2NiBSZXNlcnZhdGlvbnMgb3ZlciBQQ04gZG9tYWlucw0KCUF1dGhvcihz KSAgICAgICA6IEdlb3JnaW9zIEthcmFnaWFubmlzDQogICAgICAgICAgICAgICAgICAgICAgICAg IEFudXJhZyBCaGFyZ2F2YQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdHN2d2ctcnN2 cC1wY24tMDEudHh0DQoJUGFnZXMgICAgICAgICAgIDogMjYNCglEYXRlICAgICAgICAgICAgOiAy MDEyLTAzLTEwDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBleHRlbnNpb25zIHRv IHRoZSBHZW5lcmljIEFnZ3JlZ2F0ZWQgUlNWUA0KICAgW1JGQzQ4NjBdIGZvciBzdXBwb3J0IG9m IHRoZSBQQ04gQ29udHJvbGxlZCBMb2FkIChDTCkgYW5kIFNpbmdsZQ0KICAgTWFya2luZyAoU00p IGVkZ2UgYmVoYXZpb3JzIG92ZXIgYSBEaWZmc2VydiBjbG91ZCB1c2luZyBQcmUtDQogICBDb25n ZXN0aW9uIE5vdGlmaWNhdGlvbi4NCg0KDQoNCg0KDQpBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1E cmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt dHN2d2ctcnN2cC1wY24tMDEudHh0DQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQoNClRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi10c3Z3Zy1yc3ZwLXBjbi0wMS50 eHQNCg0K From karagian@cs.utwente.nl Thu Mar 22 05:07:57 2012 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 E3AD421F8682; Thu, 22 Mar 2012 05:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwZc6a94U-La; Thu, 22 Mar 2012 05:07:57 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABAB21F8664; Thu, 22 Mar 2012 05:07:56 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 22 Mar 2012 13:07:59 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Thu, 22 Mar 2012 13:07:55 +0100 From: To: Thread-Topic: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt Thread-Index: AQHM/vHPyDzMOlz96k6m6JtqOWLXI5Z2NICAgAATJLs= Date: Thu, 22 Mar 2012 12:07:54 +0000 Message-ID: References: <20120310191250.10652.27259.idtracker@ietfa.amsl.com>, <9510D26531EF184D9017DF24659BB87F331D4BE860@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331D4BE860@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, tsvwg@ietf.org Subject: Re: [PCN] I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.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, 22 Mar 2012 12:07:58 -0000 Hi Phil, I think that some of your comments/questions can be answered by the slides = that=20 were presented during IETF 81 in Quebec city, see below, where the initial = version of the draft had been presented, at both tsvwg and pcn wg meetings: http://www.ietf.org/proceedings/81/slides/pcn-0.pdf http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf Best regards, Georgios ________________________________________ Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens philip.eardley@= bt.com [philip.eardley@bt.com] Verzonden: donderdag 22 maart 2012 12:47 Aan: pcn@ietf.org; tsvwg@ietf.org Onderwerp: RE: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt Hi, Sorry, I had some problems understanding the draft. I spent a couple of hou= rs and basically couldn=92t get a mental model what the mechanism is. is th= ere a presentation that could help me understand? Suggest you include a problem statement. Something similar to S1.1 of rfc31= 75 (RSVP reservation aggregation). From a PCN perspective, I don=92t unders= tand the purpose. Is it saving something (signalling?) that could be done i= n a less efficient way without this doc? Or achieving something impossible = without it? I don't understand why you build on 4860 (generic aggregate reservations) r= ather than 3175 (aggregate reservations) It would be helpful to outline the overall architecture. Fig 1 helps a bit,= but I think it would be very useful to give examples of signalling for the= basic cases (I roughly guess these are when there are e2e rsvp msgs for a = new flow and [1] there is already PCN-state for the relevant pair of PCN-bo= undary-nodes; [2] when there isn't.) That would help show how PCN, RSVP and= generic aggregated rsvp fit together. I didn't understand how (at what poi= nt in your procedure) the PCN-ingress-node knows which is the relevant PCN-= egress-node It is quite hard to work out at various points whether address means the en= d host or the PCN-boundary-node address. I found the last paras on page 9 & 10 not understandable (many-to-1 mapping= of what-to-what?). Note that ingress-egress-aggregate is "the collection o= f PCN-packets from all PCN-flows that travel in one direction between a spe= cific pair of PCN-boundary-nodes" and some of the text seemed to contradict= this definition. I think you mean: "between a particular pair of PCN-bound= ary-nodes there MAY be several generic aggregate reservations"? (I don't re= ally understand why you might want that) 2.1.1 "The PHB-ID (Per Hop Behavior Identification Code) used, SHOULD be se= t equal to PCN-compatible Diffserv codepoint(s)." - aren=92t they different= lengths? I think [draft-ietf-pcn-signaling-requirements-08], [RFC5670] and [RFC5696]= are probably Informative refs (rather than normative), and perhaps [RFC555= 9] is Normative rather than Informative. If you have time, it would be good to find a corner in Paris so you can exp= lain it to me - thanks! Best wishes phil -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: 10 March 2012 19:13 To: i-d-announce@ietf.org Cc: tsvwg@ietf.org Subject: I-D Action: draft-ietf-tsvwg-rsvp-pcn-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working = Group of the IETF. Title : Generic Aggregation of Resource ReSerVation Proto= col (RSVP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-01.txt Pages : 26 Date : 2012-03-10 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-01.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-tsvwg-rsvp-pcn-01.txt= From Internet-Drafts@ietf.org Thu Mar 22 06:55:41 2012 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 E41CC21F8597; Thu, 22 Mar 2012 06:55:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STQ9bcH3aS78; Thu, 22 Mar 2012 06:55:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A45F21F858D; Thu, 22 Mar 2012 06:55:40 -0700 (PDT) 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: 4.00 Message-ID: <20120322135540.25904.21655.idtracker@ietfa.amsl.com> Date: Thu, 22 Mar 2012 06:55:40 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-cl-edge-behaviour-13.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, 22 Mar 2012 13:55:41 -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 : PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation Author(s) : A. Charny, et al Filename : draft-ietf-pcn-cl-edge-behaviour Pages : 34 Date : July 6, 2009 Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-13.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-cl-edge-behaviour"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-22065540.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Mar 22 07:02:05 2012 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 B29F021F8599; Thu, 22 Mar 2012 07:02:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt9uE5UtRAJ5; Thu, 22 Mar 2012 07:02:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237E121F84B9; Thu, 22 Mar 2012 07:02:05 -0700 (PDT) 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: 4.00 Message-ID: <20120322140205.29040.87349.idtracker@ietfa.amsl.com> Date: Thu, 22 Mar 2012 07:02:05 -0700 Cc: pcn@ietf.org Subject: [PCN] I-D ACTION:draft-ietf-pcn-sm-edge-behaviour-10.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, 22 Mar 2012 14:02:05 -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 : PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation Author(s) : A. Charny, et al Filename : draft-ietf-pcn-sm-edge-behaviour Pages : 32 Date : July 6, 2009 Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN-boundary-node behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-10.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-sm-edge-behaviour"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-22070205.I-D@ietf.org> --NextPart-- From bob.briscoe@bt.com Thu Mar 22 12:06:10 2012 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 8318621E802A for ; Thu, 22 Mar 2012 12:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZvM73EYEcL3 for ; Thu, 22 Mar 2012 12:06:09 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 07F5B21E801F for ; Thu, 22 Mar 2012 12:06:09 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:05:49 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:05:45 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Mar 2012 19:05:42 +0000 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 1332443141986; Thu, 22 Mar 2012 19:05:41 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.129.95]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2MJ5c7J028978; Thu, 22 Mar 2012 19:05:38 GMT Message-ID: <201203221905.q2MJ5c7J028978@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2012 19:05:38 +0000 To: Michael Menth From: Bob Briscoe In-Reply-To: <4F68F318.1000107@informatik.uni-tuebingen.de> References: <4F68E62E.9080502@gmail.com> <4F68EDF1.8070004@informatik.uni-tuebingen.de> <4F68F278.50108@gmail.com> <4F68F318.1000107@informatik.uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org Subject: Re: [PCN] PCN edge behaviour experiment 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, 22 Mar 2012 19:06:10 -0000 Michael, One way to do this would be to administratively shut down a link or node, allow protection to shift traffic and monitor whether PCN starts admission control. But it would be a brave operator who did this with live traffic, even if it had been simulated first. I guess you might do it for a few tens of seconds when you know measured traffic will fit into protection capacity but above the admissable rate, check it works then bring the link back up. Bob At 21:14 20/03/2012, Michael Menth wrote: >I don't suggest artifical traffic to cause admitted traffic >exceeding the PCN threshold but real traffic. A planned experiment >does not imply artifical traffic. > >Am 20.03.2012 22:11, schrieb Tom Taylor: >>Good points. That means the experiment doesn't have to run very >>long to meet the first two objectives. I do have one concern that >>if you introduce artificial traffic then maybe you don't get the >>same outcome that real traffic gives you. I figure it's inevitable >>that the benefits of PCN with real traffic in a real network will >>be less than our simulations show, if only because real networks >>tend to be over-provided with capacity. >> >>On 20/03/2012 4:52 PM, Michael Menth wrote: >>>Hi Tom, >>> >>> >>>Am 20.03.2012 21:18, schrieb Tom Taylor: >>>>I am making what I trust will be the final revisions to the edge >>>>behaviour documents in response to IESG comments. Amongst other >>>>things, this is the text I propose to add in the introduction to >>>>justify the Experimental status of the documents. The text will be the >>>>same for CL and for SM, following on Ruediger's observation that both >>>>behaviours are valid in different contexts. Comments are welcomed. >>>> >>>>--- >>>> >>>>This document describes an experimental edge node behaviour to >>>>implement PCN in a network. The experiment may be run in a network in >>>>which a substantial proportion of the traffic carried is in the form >>>>of inelastic flows and where admission control of micro-flows is >>>>applied at the edge. For the effects of PCN to be observable, at least >>>>some links of the network should be running near or at capacity. >>>Better: "the aggregate rate of admitted flows on some links should come >>>close to the bandwidths of these links." >>> >>>>The amount of effort required to prepare the network for the >>>>experiment (see Section 5.1) may constrain the size of network to >>>>which it is applied. The purposes of the experiment are: >>>> >>>>- to validate the specification of the CL [SM] edge behaviour; >>>> >>>>- to evaluate the effectiveness of the CL [SM] edge behaviour in >>>>preserving quality of service for admitted flows; and >>>> >>>>- to evaluate PCN's potential for reducing the amount of capital and >>>>operational costs in comparison to alternative methods of assuring >>>>quality of service. >>>> >>>>For the first two objectives, the experiment should run long enough >>>>for the network to experience sharp peaks of traffic in at least some >>>>directions. >>>These peaks could be intentionally caused for the sake of the experiment >>>so that the effect of admission control is visible. >>> >>>>It would also be desirable to observe PCN performance in the face of >>>>failures in the network. A period in the order of a month or two in >>>>busy season may be enough. The third objective is more difficult, and >>>>could require observation over a period long enough for traffic demand >>>>to grow to the point where additional capacity must be provisioned at >>>>some points in the network. >>>Also failures could be intentionally caused for the sake of the >>>experiment. Capacity shortage on backup paths could also be planned for >>>so that the effect of flow termination is visible. >>> >>>Best wishes, >>> >>>Michael >>> >>>>_______________________________________________ >>>>PCN mailing list >>>>PCN@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pcn > >-- >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://kn.inf.uni-tuebingen.de > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Mar 22 12:22:41 2012 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 2167521F853E for ; Thu, 22 Mar 2012 12:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UegdBsjMetDK for ; Thu, 22 Mar 2012 12:22:39 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3421F8533 for ; Thu, 22 Mar 2012 12:22:37 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:22:24 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:22:23 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Mar 2012 19:22:21 +0000 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 1332444141285; Thu, 22 Mar 2012 19:22:21 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.129.95]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2MJMIwd029049; Thu, 22 Mar 2012 19:22:19 GMT Message-ID: <201203221922.q2MJMIwd029049@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2012 19:22:18 +0000 To: Tom Taylor From: Bob Briscoe In-Reply-To: <4F68E62E.9080502@gmail.com> References: <4F68E62E.9080502@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn Subject: Re: [PCN] PCN edge behaviour experiment 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, 22 Mar 2012 19:22:41 -0000 Tom, Your original text was good, and I agree with the way people have converged on improvements so far. I want to go back to your first posting and pick out a couple of other parts of the text... Perhaps the proposed text is rather too prescriptive about what a valid experiment would be. I suggest: s/The purposes of the experiment are:/ /Vendors and operators will have their own purposes for conducting experiments, but example purposes would be:/ One more comment inline... At 20:18 20/03/2012, Tom Taylor wrote: >I am making what I trust will be the final revisions to the edge >behaviour documents in response to IESG comments. Amongst other >things, this is the text I propose to add in the introduction to >justify the Experimental status of the documents. The text will be >the same for CL and for SM, following on Ruediger's observation that >both behaviours are valid in different contexts. Comments are welcomed. > >--- > >This document describes an experimental edge node behaviour to >implement PCN in a network. [snip] >The purposes of the experiment are: [snip] >- to evaluate PCN's potential for reducing the amount of capital and > operational costs in comparison to alternative methods of assuring > quality of service. > >For the first two objectives, the experiment should run long enough >for the network to experience sharp peaks of traffic in at least >some directions. It would also be desirable to observe PCN >performance in the face of failures in the network. A period in the >order of a month or two in busy season may be enough. The third >objective is more difficult, and could require observation over a >period long enough for traffic demand to grow to the point where >additional capacity must be provisioned at some points in the network. The third objective may not necessarily require a wait for capacity to actually be provisioned. The main unknown costs are: a) cost of implementation and operation of PCN (relative to an alternative) b) any differences in capacity costs due to differences in feasible utilisation An experimental deployment is the best way to quantify (a). But (b) may be sufficiently quantifiable using projections without having to wait for capacity to need replacing. Bob >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Mar 22 12:35:21 2012 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 CC97C21E8018 for ; Thu, 22 Mar 2012 12:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmgsVRMFcWCz for ; Thu, 22 Mar 2012 12:35:20 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2A73C21F8598 for ; Thu, 22 Mar 2012 12:35:20 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:35:15 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 19:35:18 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Mar 2012 19:35:15 +0000 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 1332444915547; Thu, 22 Mar 2012 19:35:15 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.129.95]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2MJZDIv029095; Thu, 22 Mar 2012 19:35:14 GMT Message-ID: <201203221935.q2MJZDIv029095@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2012 19:35:12 +0000 To: "James M. Polk" From: Bob Briscoe In-Reply-To: <201203202140.q2KLe5ud007565@mtv-core-2.cisco.com> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <9510D26531EF184D9017DF24659BB87F331D442A7C@EMV65-UKRD.domain1.systemhost.net> <201203202140.q2KLe5ud007565@mtv-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 19:35:21 -0000 James, Done (Option #3), unless my co-authors would rather choose another option. You will have seen a manually posted draft-ietf-pcn-3-in-1-encoding-10 just appear (at the request of our AD). But we will do another rev for changes like this. Bob At 21:40 20/03/2012, James M. Polk wrote: >I know this is a nit, but shouldn't the text actually read > >Option #1 "... re-mark the DSCP to 000000." > >or even > >Option #2 "... re-mark the DSCP to 0." > >or even > >Option #3 "... re-mark the DSCP to zero (000000)." > >or even > >Option #4 "... re-mark the DSCP to zero (0)." > >instead of just > > "... re-mark the DSCP to zero." > >? > >I prefer Option #1, but am happy with Option #3 over the others. IMO >this should not remain as it is. > >James > >At 02:25 PM 3/20/2012, karagian@cs.utwente.nl wrote: >>Content-Language: nl-NL >>Content-Type: multipart/alternative; >>boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C150D7EXMBX04adutwent_" >> >>Hi all, >> >> >> >>I think that the changes satisfy nicely the comments of Adrian! >> >> >> >>Best regards, >> >>Georgios >> >> >> >> >> >>---------- >>Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens >>philip.eardley@bt.com [philip.eardley@bt.com] >>Verzonden: dinsdag 20 maart 2012 17:46 >>Aan: sob@harvard.edu; pcn@ietf.org >>Onderwerp: Re: [PCN] lets try again - a chair asking this time >> >>Seems good to me. I like the inclusion of material previously in >>both the edge behaviour docs >> >> >> >>From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >>Of Bradner, Scott >>Sent: 20 March 2012 16:37 >>To: pcn@ietf.org >>Subject: [PCN] lets try again - a chair asking this time >> >> >> >>please let the list know what you think >> >> >> >>Scott >> >> >> >>Scott O Bradner >> >>Senior Technology Consultant >> >> >> >>Begin forwarded message: >> >> >> >> >> >>Date: Mon, 12 Mar 2012 03:30:11 +0000 >>To: "PCN IETF list" <pcn@ietf.org> >>From: Bob Briscoe <bob.briscoe@bt.com> >>Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt >> >>PCN folks, >> >>Following IESG review (particularly Adrian Farrel's being the most >>comprehensive and useful), we've posted a new version of the PCN >>3-in-1 encoding. >> >>As well as a number of editorial changes, some technical changes >>were needed in order to satisfy Adrian's request to specify exactly >>what an implementer has to do at the ingress to allow ECN to >>co-exist with PCN, and what defaults should be set to. >> >>In particular, for a non-PCN packet (i.e. doesn't match any >>flow-state) that clashes with a PCN DSCP and is ECN-capable, the >>recommended choice of 3 is: >> >> * re-mark the DSCP to a DSCP that is not PCN-compatible; >> >> >> >> >>[...] >> >>In the >> >> absence of any operator-specific >> >>configuration for this case, by >> >> default an implementation SHOULD re-mark >> >>the DSCP to zero. >> >> >> >> >>Actually, the whole of the ingress behaviour section (5.1) has been >>re-written, incorporating material that was previously repeated in >>both edge-behaviours (agreed with IESG and with edge-behaviour >>authors, of course). Altho it largely does the same thing >>technically, it is written to cover the complete range of possible >>scenarios, and it now gives defaults and recommended choices. I >>don't think it's controversial, but shout if it is. >>< http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 > >> >> >> >>Bob >> >>PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: >> >> * Added note about fail-safe to protect other traffic in the >> event of tunnel misconfiguration. >> >> * Changed section heading to be about applicability of >> environments to the encoding, rather than the encoding to the >> environments. >> >> * Completely re-wrote PCN-ingress Node Behaviour section. >> >> * Changed PCN interior node to PCN-node where the term was >> intended to include all PCN-nodes. >> >> * Clarified status of ECN/PCN co-existence appendix. Removed >> inconsistent assertion in this appendix that an admission- >> control DSCP alone can indicate that arriving traffic is PCN- >> traffic. >> >> * A few clarifying editorial amendments and updated refs. >> >> >> >> >>From: <internet-drafts@ietf.org> >>To: <pcn-chairs@tools.ietf.org>, >><draft-ietf-pcn-3-in-1-encoding@tools.ietf.org>, >><ietfdbh@comcast.net>, >> <adrian@olddog.co.uk>, >> <rjsparks@nostrum.com> >>Date: Sun, 11 Mar 2012 17:52:23 -0700 >>Subject: New Version Notification - draft-ietf-pcn-3-in-1-encoding-09.txt >> >>New version (-09) has been submitted for >>draft-ietf-pcn-3-in-1-encoding-09.txt. >>http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt >> >> >> >>Diff from previous version: >>http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09 >> >> >>IETF Secretariat. >> >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >> >> >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www.ietf.org/mailman/listinfo/pcn > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Mar 22 13:20:32 2012 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 28A1E21E801B for ; Thu, 22 Mar 2012 13:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLa156cQkkxu for ; Thu, 22 Mar 2012 13:20:31 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6944221F855D for ; Thu, 22 Mar 2012 13:20:30 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 22 Mar 2012 20:20:21 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 20:20:25 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Mar 2012 20:20:24 +0000 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 1332447622944; Thu, 22 Mar 2012 20:20:22 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.129.95]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2MKKJiF029179; Thu, 22 Mar 2012 20:20:20 GMT Message-ID: <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2012 20:20:19 +0000 To: , From: Bob Briscoe In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1. cds.t-internal.com> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 20:20:32 -0000 Ruediger, [Scott, a question for you at the end] At 08:07 21/03/2012, Ruediger.Geib@telekom.de wrote: >Hi Scott, > >the passage you quote should result from a misconfiguration or an attack. > > Treatment of non-PCN-packets confused with a PCN-packet > due to DSCP/ECN codepoinzt setting: > ... > In the absence of any operator-specific > configuration for this case, by > default an implementation SHOULD re-mark > the DSCP to zero. > ... > Clearing the ECN field is not an appropriate > policing action, because a network node ought not to interfere > with an e2e signal. Even if such packets seem like an attack, > drop would be overkill, because such an attack can be neutralised > by just re-marking the DSCP. And DSCP re-marking in the network > is legitimate, because the DSCP is not considered an e2e signal. > >What's done here is remarking of a flow with a DSCP that has been >agreed between two parties. On a consumer UNI, this may be an attack, >on an NNI, this could indicate a misconfiguration. Yes, when I realised this could be a mistake or an attack, I realised remarking the DSCP was the right approach to recommend, because it allows the operator to control this as part of their general DSCP re-marking policy. BTW, the default of "re-mark to zero", was merely so /implementers/ have a default. It's not intended to be the recommended policy for operators. >In the latter case, >a management alert seems reasonable. Text to that may be added. Good catch. In fact, an alert for an attack is also worth suggesting. I suggest the following text after "...re-mark the DSCP to zero (000000)." "Whichever policing action is chosen, the PCN-ingress-node SHOULD log the event and MAY also raise an alarm. Alarms SHOULD be rate-limited so that the anomalous packets will not amplify into a flood of alarm messages." >I further quote the PCN architecture, which is informational, on the >Ingress Node behaviour: > > Police - police, by dropping any packets received with a DSCP > indicating PCN transport that do not belong to an admitted flow. > (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.) Similarly, > police packets that are part of a previously admitted flow, to > check that the flow keeps to the agreed rate or flowspec (eg, see > [RFC1633] for a microflow and its NSIS equivalent). > >This isn't in line with the proposed 3-in-1 (standards track) behaviour. You're right. When we wrote this point in the architecture I think we were only thinking about blocked flows. I don't think that text was intended to catch packets that had never even asked to be admitted (i.e. mistakes or attacks). >Does this require an "Errata" atatement for RFC5559 (I'm not an expert on >editing RFCs and may be wrong here)? You're right that something needs doing about this statement in the architecture. We could say in 3-in-1 that it updates RFC5559. That would require an extra section in 3-in-1 saying exactly which part of the architecture it updates. I prefer your erratum suggestion because it flags the problem in the doc that now needs clarifying, so it's more likely to be noticed by people reading the deprecated text. But we'll have to see whether this would be accepted as an erratum. The relevant rule is #7 here: "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update. " If we wrote an erratum to RFC5559, it would be legitimate, because the para you have quoted has two contradictory statements in it anyway. I doubt an erratum can refer to an RFC published later (3-in-1), because errata are meant to correct what the document should have said at the time. I think we could compose an erratum that resolved the contradiction in that paragraph while at the same time making it "not inconsistent" with what we now want to say in 3-in-1. Scott, can you advise? Bob >Regards, > >Ruediger > >________________________________ > >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >Of Bradner, Scott >Sent: Tuesday, March 20, 2012 5:37 PM >To: pcn@ietf.org >Subject: [PCN] lets try again - a chair asking this time > > >please let the list know what you think > >Scott > >Scott O Bradner >Senior Technology Consultant > > > >Begin forwarded message: > > > > > > Date: Mon, 12 Mar 2012 03:30:11 +0000 > To: "PCN IETF list" > From: Bob Briscoe > Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.txt > > PCN folks, > > Following IESG review (particularly Adrian Farrel's > being the most comprehensive and useful), we've posted a new > version of the PCN 3-in-1 encoding. > > As well as a number of editorial changes, some > technical changes were needed in order to satisfy Adrian's request > to specify exactly what an implementer has to do at the ingress to > allow ECN to co-exist with PCN, and what defaults should be set to. > > In particular, for a non-PCN packet (i.e. doesn't > match any flow-state) that clashes with a PCN DSCP and is > ECN-capable, the recommended choice of 3 is: > > * re-mark the DSCP to a DSCP that is not > PCN-compatible; > > > > > [...] > In the > absence of any operator-specific > configuration for this case, by > default an implementation SHOULD re-mark > the DSCP to zero. > > > > Actually, the whole of the ingress behaviour > section (5.1) has been re-written, incorporating material that was > previously repeated in both edge-behaviours (agreed with IESG and > with edge-behaviour authors, of course). Altho it largely does the > same thing technically, it is written to cover the complete range > of possible scenarios, and it now gives defaults and recommended > choices. I don't think it's controversial, but shout if it is. > < > http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 > > > > > > Bob > > PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09: > > * Added note about fail-safe to protect > other traffic in the > event of tunnel misconfiguration. > > * Changed section heading to be about applicability of > environments to the encoding, rather than > the encoding to the > environments. > > * Completely re-wrote PCN-ingress Node > Behaviour section. > > * Changed PCN interior node to PCN-node > where the term was > intended to include all PCN-nodes. > > * Clarified status of ECN/PCN co-existence > appendix. Removed > inconsistent assertion in this appendix > that an admission- > control DSCP alone can indicate that > arriving traffic is PCN- > traffic. > > * A few clarifying editorial amendments and > updated refs. > > > > > > From: > To: , > >, , > , > Date: Sun, 11 Mar 2012 17:52:23 -0700 > Subject: New Version Notification - > draft-ietf-pcn-3-in-1-encoding-09.txt > > New version (-09) has been submitted for > draft-ietf-pcn-3-in-1-encoding-09.txt. > >http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt > > > Diff from previous version: > >http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcn-3-in-1-encoding-09 > > IETF Secretariat. > > > >________________________________________________________________ > Bob Briscoe, BT > Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From sob@harvard.edu Thu Mar 22 13:35:06 2012 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 9321C21F850B for ; Thu, 22 Mar 2012 13:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.466 X-Spam-Level: X-Spam-Status: No, score=-103.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K58zRFocWZIN for ; Thu, 22 Mar 2012 13:35:05 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id C894721F84EE for ; Thu, 22 Mar 2012 13:35:05 -0700 (PDT) Received: from exchange.university.harvard.edu (unknown [10.35.2.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 50088EA68A; Thu, 22 Mar 2012 16:35:05 -0400 (EDT) Received: from ENTWHUBT0000001.university.harvard.edu (10.32.8.202) by ENTWEDGE0000000.university.harvard.edu (10.35.2.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 22 Mar 2012 16:34:36 -0400 Received: from ENTWEXMB0000004.university.harvard.edu ([169.254.3.128]) by ENTWHUBT0000001.university.harvard.edu ([10.32.8.202]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 16:35:04 -0400 From: "Bradner, Scott" To: Bob Briscoe Thread-Topic: [PCN] lets try again - a chair asking this time Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+w== Date: Thu, 22 Mar 2012 20:35:04 +0000 Message-ID: <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> In-Reply-To: <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.166.5.69] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 20:35:06 -0000 On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote: > Ruediger, >=20 > [Scott, a question for you at the end] >=20 >=20 >=20 > I prefer your erratum suggestion because it flags the problem in the doc = that now needs clarifying, so it's more likely to be noticed by people read= ing the deprecated text. But we'll have to see whether this would be accept= ed as an erratum. The relevant rule is #7 here: > >=20 > "Changes that modify the working of a protocol to something that might be= different from the intended consensus when the document was approved shoul= d be either Hold for Document Update or Rejected. Deciding between these tw= o depends on judgment. Changes that are clearly modifications to the intend= ed consensus, or involve large textual changes, should be Rejected. In uncl= ear situations, small changes can be Hold for Document Update. " >=20 > If we wrote an erratum to RFC5559, it would be legitimate, because the pa= ra you have quoted has two contradictory statements in it anyway. I doubt a= n erratum can refer to an RFC published later (3-in-1), because errata are = meant to correct what the document should have said at the time. I think we= could compose an erratum that resolved the contradiction in that paragraph= while at the same time making it "not inconsistent" with what we now want = to say in 3-in-1. >=20 > Scott, can you advise? that sounds logical Scott From bob.briscoe@bt.com Thu Mar 22 15:58:40 2012 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 97B1621E801F for ; Thu, 22 Mar 2012 15:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGR6xZfjMbYH for ; Thu, 22 Mar 2012 15:58:39 -0700 (PDT) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id EED1721E801B for ; Thu, 22 Mar 2012 15:58:31 -0700 (PDT) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 22:58:26 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 22:58:29 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Mar 2012 22:58:29 +0000 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 133245710832; Thu, 22 Mar 2012 22:58:28 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.16.10]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2MMwQfX029549; Thu, 22 Mar 2012 22:58:26 GMT Message-ID: <201203222258.q2MMwQfX029549@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2012 22:57:21 +0000 To: Tom Taylor From: Bob Briscoe In-Reply-To: <4F6A69B8.6010601@informatik.uni-tuebingen.de> References: <4F6A2736.8040403@gmail.com> <4F6A44C3.20506@informatik.uni-tuebingen.de> <4F6A4C7B.8050607@gmail.com> <4F6A69B8.6010601@informatik.uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn Subject: Re: [PCN] Explanation of changes in the PCN edge behaviour drafts 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, 22 Mar 2012 22:58:40 -0000 Tom, inline tagged [BB]... At 23:52 21/03/2012, Michael Menth wrote: >Hi Tom, >Am 21.03.2012 22:47, schrieb Tom Taylor: >>My comments in turn below, marked with [PTT]. >>On 21/03/2012 5:14 PM, Michael Menth wrote: >>>Hi Tom, >>> >>>>NEW >>>> >>>>Packets at the ingress to the domain are classified as either PCN or >>>>non-PCN. Non-PCN packets can share the network with PCN packets >>>>within the domain. The encoding specified in [RFC5696] and used in >>>>this document requires the use of the ECN fields. PCN-ingress-nodes >>>>need to prevent ECN-capable traffic that uses the same DSCP as PCN >>>>from entering the PCN-domain directly. This is not an issue when >>>>tunneling of PCN-packets between the PCN-ingress-node and the PCN- >>>>egress-node is done, as recommended in Section 5.1.2, provided that >>>>the original ECN markings of arriving packets are preserved in the >>>>encapsulated headers. [BB] Section 5.1.2 doesn't actually recommend tunnelling, at least not in normative language. All it says is: " As a result, the only way to construct such filters reliably is to tunnel the packets from the PCN-ingress- node to the PCN-egress-node. " In fact we shouldn't only receommend tunnelling, because that's not actually true. One could implement CL-PCN by layering rather than tunneling. This would work if PCN edge-nodes were the only IP-aware nodes in the PCN domain, and PCN metering & marking was done at the lower layer (e.g. MPLS) on interior nodes. This would affect the assumed core network behaviour too. At the start of S.2. I suggest a sentence such as: OLD: " This section describes the assumed behaviour for PCN-interior-nodes in the PCN-domain. " SUGGESTED: " This section describes the assumed behaviour for IP-aware PCN-interior-nodes in the PCN-domain. " And add at end of Section 2: "An alternative would be to use PCN in MPLS on interior nodes. In this case all references to the PCN encoding for IP [3-in-1] would be replaced by references to the PCN encoding for MPLS described in Appendix A of [RFC5129] (Appendix C of [3-in-1] also gives useful examples of the PCN encoding in MPLS). In the rest of this document IP-aware interior nodes are assumed. " In addition, we should state in the introduction (and possibly the abstract) that this doc assumes IP-aware PCN nodes, but MPLS interior nodes are briefly discussed as an alternative. It may help to call these edge-behaviours CL-IP and SM-IP, not just CL & SM. Then later someone could produce near-identical copies of these RFCs called CL-MPLS and SM-MPLS (the latter makes more sense than the former because of codepoint restrictions). These wouldn't use tunnelling, and would refer to a different encoding, but would otherwise be fairly identical. [Another alternative is to use Layer 3 Ethernet switches as interior nodes. L3 switches do forwarding on Ethernet addresses, but they can bury into the IP header in the payload for the Diffserv & ECN fields (Microsoft has deployed ECN-marking on Layer-3 switches within its data centres). However, there's no need to mention an Ethernet option in the docs - it's a can-of-worms for standards because some see it as a layering violation. This little aside was for the list, not the doc.] >>>Moving the old text to 3-in-1 means that this doc is now aware of >>>3-in-1. Therefore, we should base this edge behavior no longer on >>>baseline encoding (RFC5696) but on 3-in-1. >>[PTT] I don't think we have to, although it might be reasonable. >>The argument is that there is no need for the old text because we >>are using tunneling. >I'd suggest to substitute RFC5696 by 3-in-1 in general to avoid >confusion by a soon obsoleted RFC. [BB] I agree. I believe the edge-behaviours and 3-in-1 are all going through together so it would be wrong to refer to a doc that 3-in-1 obsoletes. The RFC-Editor will substitute the appropriate RFCxxxx for 3-in-1, which will be a normative reference. I'm afraid you will also need to substitute the new names for the two marked codepoints (PM->ETM & EXP->ThM), but SM will only need one (ETM). >>>>11. In the next paragraph, originally said that PCN packets of >>>>non-admitted flows are dropped. Replaced this with "blocked" and a >>>>backward reference to the definition of blocking in Section 1. >>>>(Follow-through on comments by Brian Carpenter, fixed elsewhere. >>>I think to remember that 3-in-1 recommended recoloring as preferred >>>policing option. >> >>[PTT] We agreed on local policy as the answer when discussing Brian >>Carpenter's review comments. [BB] There's a distinction needed between: i) treatment of packets of a flow that has asked to be admitted but been blocked and ii) packets where there has never been a request for their flow to be admitted, but they happen to be using a PCN-compatible DSCP and an ECN-capable codepoint. For case (i) it would be perfectly reasonable to drop, but re-marking the DSCP would also be a reasonable policy. For case (ii) drop would be unreasonable, because these packets just happen to be using a PCN codepoint outside the PCN domain, but they're not PCN-traffic. PCN nodes have no business interfering with non-PCN traffic. However they've got to do something to prevent confusion. So the safest action is to re-mark the DSCP. If the behaviour for (i) & (ii) are different this could be awkward, because it means the PCN-ingress has to remember all the flows it has blocked in order to treat them differently from packets that never asked to be admitted. How long does it remember blocked flows for? So a sensible policy would be to treat both (i) & (ii) the same to save having to remember blocked flows. But from a standards viewpoint, we should still make the distinction, because the treatment of each should be a policy choice, not something we should prejudge. The edge-behaviour docs are the right place to deal with case (i), but for the latter case both edge-behaviour docs need to refer to the new Section 5.1 of [3-in-1]. The logic here is that edge-behaviours deal with flow-related stuff, while 3-in-1 deals with individual packets. [3-in-1] refers to the edge-behaviours for handling packets of signalled flows. The split between specs here is unfortunate, but necessary. >>>>13. Section 5.1.3, basically editorial rearrangement of text to take >>>>account of the fact that the ingress node will always perform >>>>encapsulation. [BB] Again, there may need to be some reference to layering as an alternative to tunnelling. >>>>Talking about extensions to the DiffServ MIB. >>>> >>>>OLD >>>> >>>>... The required >>>>extensions specifically include objects for re-marking the ECN field >>>>at the PCN-ingress-node and an extension to the classifiers to >>>>include the ECN field at PCN-interior and PCN-egress-nodes. In >>>>addition, the MIB has to be extended to include a potential >>>>encapsulation action following re-classification by ingress-egress- >>>>aggregate. Finally, a new metering algorithm may need to be defined >>>>at the PCN-interior-nodes to handle excess-traffic-marking. >>>> >>>>NEW >>>> >>>>... The required >>>>extensions specifically include an encapsulation action following re- >>>>classification by ingress-egress-aggregate. In addition, the MIB >>>which MIB? >> >>[PTT] DiffServ MIB [RFC3289], referenced in the document. >ok, now I see the reference was some sentences before > >>> >>>>has >>>>to be extended to include objects for marking the ECN field in the >>>>outer header at the PCN-ingress-node and an extension to the >>>>classifiers to include the ECN field at PCN-interior and PCN-egress- >>>>nodes. Finally, new metering algorithms may need to be defined at >>>>the PCN-interior-nodes to handle threshold-marking and packet-size- >>>>independent excess-traffic-marking. >>>I do not understand why the defined marking algorithms are not >>>sufficient. Also packet-size-independent excess-traffic-marking is >>>defined (see 2.4 in RFC5670). >>The above passage is talking about whether the DiffServ MIB >>supports the defined marking algorithms, not saying that new >>algorithms are needed. >ok, understand [BB] The text is still misleading. We on the list only understand because you've explained on the list. Perhaps: s/Finally, new metering algorithms may need to be defined/ /Finally, new MIB entries for the metering algorithms may need to be defined/ Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Mar 22 16:54:22 2012 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 A7CAD21E801B for ; Thu, 22 Mar 2012 16:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnnhHcDP-uoL for ; Thu, 22 Mar 2012 16:54:22 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id A15ED21E803D for ; Thu, 22 Mar 2012 16:54:21 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 23:54:03 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 23:54:01 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Thu, 22 Mar 2012 23:54:00 +0000 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 1332460437133; Thu, 22 Mar 2012 23:53:57 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.16.10]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2MNrref029724; Thu, 22 Mar 2012 23:53:54 GMT Message-ID: <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Mar 2012 23:53:54 +0000 To: "Bradner, Scott" From: Bob Briscoe In-Reply-To: <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 23:54:22 -0000 Scott, If an erratum is rejected, we'll have to update the architecture via 3-in-1. Therefore, we'll have to post the erratum quickly, so that we know whether it has been rejected or not before 3-in-1 gets thru the RFC-Editor. Here's the erratum I will post unless anyone can suggest a better way: ==================================================================== RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009 Source of RFC: pcn (tsv) Type: Technical Reported By: Bob Briscoe Date Reported: 2012-03-XX Section 4.2 says: o Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) It should say: o Police - police, by dropping or re-marking the DSCP of any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Notes: The change makes the first sentence consistent with the parenthesis, otherwise the two contradict. The first sentence as it stands could be interpreted to mean that dropping is the only allowed policing action, whereas the parenthesis shows that downgrading was also considered appropriate. ==================================================================== Bob At 20:35 22/03/2012, Bradner, Scott wrote: >On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote: > > > Ruediger, > > > > [Scott, a question for you at the end] > > > > > > > > I prefer your erratum suggestion because it flags the problem in > the doc that now needs clarifying, so it's more likely to be > noticed by people reading the deprecated text. But we'll have to > see whether this would be accepted as an erratum. The relevant rule is #7 here: > > > > > > "Changes that modify the working of a protocol to something that > might be different from the intended consensus when the document > was approved should be either Hold for Document Update or Rejected. > Deciding between these two depends on judgment. Changes that are > clearly modifications to the intended consensus, or involve large > textual changes, should be Rejected. In unclear situations, small > changes can be Hold for Document Update. " > > > > If we wrote an erratum to RFC5559, it would be legitimate, > because the para you have quoted has two contradictory statements > in it anyway. I doubt an erratum can refer to an RFC published > later (3-in-1), because errata are meant to correct what the > document should have said at the time. I think we could compose an > erratum that resolved the contradiction in that paragraph while at > the same time making it "not inconsistent" with what we now want to > say in 3-in-1. > > > > Scott, can you advise? > >that sounds logical > >Scott ________________________________________________________________ Bob Briscoe, BT Innovate & Design From sob@harvard.edu Thu Mar 22 17:01:45 2012 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 6230021E804A for ; Thu, 22 Mar 2012 17:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLkMZ-I7JEAq for ; Thu, 22 Mar 2012 17:01:44 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB5821E8048 for ; Thu, 22 Mar 2012 17:01:44 -0700 (PDT) Received: from exchange.university.harvard.edu (unknown [10.35.2.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id EF391EA66D; Thu, 22 Mar 2012 20:01:28 -0400 (EDT) Received: from ENTWHUBT0000007.university.harvard.edu (192.168.236.27) by ENTWEDGE0000000.university.harvard.edu (10.35.2.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 22 Mar 2012 20:00:44 -0400 Received: from ENTWEXMB0000004.university.harvard.edu ([169.254.3.128]) by ENTWHUBT0000007.university.harvard.edu ([::1]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 20:01:13 -0400 From: "Bradner, Scott" To: Bob Briscoe Thread-Topic: [PCN] lets try again - a chair asking this time Thread-Index: AQHNBreta/Ow8il9OUGlwXRtWwuu+w== Date: Fri, 23 Mar 2012 00:01:12 +0000 Message-ID: References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> In-Reply-To: <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.248.127.162] Content-Type: text/plain; charset="us-ascii" Content-ID: <53770BD8C3C9FB409569FF81D2F88033@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 00:01:45 -0000 looks right to me Scott On Mar 22, 2012, at 7:53 PM, Bob Briscoe wrote: > Scott, >=20 > If an erratum is rejected, we'll have to update the architecture via 3-in= -1. >=20 > Therefore, we'll have to post the erratum quickly, so that we know whethe= r it has been rejected or not before 3-in-1 gets thru the RFC-Editor. >=20 > Here's the erratum I will post unless anyone can suggest a better way: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009 > Source of RFC: pcn (tsv) >=20 > Type: Technical >=20 > Reported By: Bob Briscoe > Date Reported: 2012-03-XX >=20 > Section 4.2 says: >=20 > o Police - police, by dropping any packets received with a DSCP > indicating PCN transport that do not belong to an admitted flow. > (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.) >=20 >=20 > It should say: >=20 > o Police - police, by dropping or re-marking the DSCP of any packets > received with a DSCP indicating PCN transport that do not belong > to an admitted flow. (A prospective PCN-flow that is rejected could > be blocked or admitted into a lower-priority behaviour aggregate.) >=20 >=20 > Notes: >=20 > The change makes the first sentence consistent with the parenthesis, othe= rwise the two contradict. The first sentence as it stands could be interpre= ted to mean that dropping is the only allowed policing action, whereas the = parenthesis shows that downgrading was also considered appropriate. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > Bob >=20 > At 20:35 22/03/2012, Bradner, Scott wrote: >=20 >> On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote: >>=20 >> > Ruediger, >> > >> > [Scott, a question for you at the end] >> > >> > >> > >> > I prefer your erratum suggestion because it flags the problem in the d= oc that now needs clarifying, so it's more likely to be noticed by people r= eading the deprecated text. But we'll have to see whether this would be acc= epted as an erratum. The relevant rule is #7 here: >> > >> > >> > "Changes that modify the working of a protocol to something that might= be different from the intended consensus when the document was approved sh= ould be either Hold for Document Update or Rejected. Deciding between these= two depends on judgment. Changes that are clearly modifications to the int= ended consensus, or involve large textual changes, should be Rejected. In u= nclear situations, small changes can be Hold for Document Update. " >> > >> > If we wrote an erratum to RFC5559, it would be legitimate, because the= para you have quoted has two contradictory statements in it anyway. I doub= t an erratum can refer to an RFC published later (3-in-1), because errata a= re meant to correct what the document should have said at the time. I think= we could compose an erratum that resolved the contradiction in that paragr= aph while at the same time making it "not inconsistent" with what we now wa= nt to say in 3-in-1. >> > >> > Scott, can you advise? >>=20 >> that sounds logical >>=20 >> Scott >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 From menth@informatik.uni-tuebingen.de Fri Mar 23 02:24:45 2012 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 963FF21F84EA for ; Fri, 23 Mar 2012 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[AWL=0.618, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR2txU9BIZIy for ; Fri, 23 Mar 2012 02:24:39 -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 71F3B21F84AE for ; Fri, 23 Mar 2012 02:24:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E42B852F8; Fri, 23 Mar 2012 10:24:30 +0100 (MET) 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 vCnaXDjfp9eY; Fri, 23 Mar 2012 10:24:26 +0100 (MET) 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 D0D6C52B7; Fri, 23 Mar 2012 10:24:26 +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 4E6974090035; Fri, 23 Mar 2012 10:24:27 +0100 (CET) Message-ID: <4F6C414B.8050705@informatik.uni-tuebingen.de> Date: Fri, 23 Mar 2012 10:24:27 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: pcn@ietf.org, Bob Briscoe , "Scott O. Bradner" References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> In-Reply-To: <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 09:24:45 -0000 Hi Bob, Am 23.03.2012 00:53, schrieb Bob Briscoe: > Scott, > > If an erratum is rejected, we'll have to update the architecture via > 3-in-1. > > Therefore, we'll have to post the erratum quickly, so that we know > whether it has been rejected or not before 3-in-1 gets thru the > RFC-Editor. > > Here's the erratum I will post unless anyone can suggest a better way: > > ==================================================================== > RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009 > Source of RFC: pcn (tsv) > > Type: Technical > > Reported By: Bob Briscoe > Date Reported: 2012-03-XX > > Section 4.2 says: > > o Police - police, by dropping any packets received with a DSCP > indicating PCN transport that do not belong to an admitted flow. > (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.) > > > It should say: > > o Police - police, by dropping or re-marking the DSCP of any packets > received with a DSCP indicating PCN transport that do not belong > to an admitted flow. (A prospective PCN-flow that is rejected could > be blocked or admitted into a lower-priority behaviour aggregate.) > > > Notes: > > The change makes the first sentence consistent with the parenthesis, > otherwise the two contradict. The first sentence as it stands could be > interpreted to mean that dropping is the only allowed policing action, > whereas the parenthesis shows that downgrading was also considered > appropriate. What does block in the parentheses mean? The same as reject? Or does blocking imply dropping instead of remarking the DSCP? I find the text clearer without the parentheses. Re-marking the DSCP must imply downgrading (could be added) which does not exclude admission into a lower-priority behavior aggregate. Regards, Michael > ==================================================================== > > > Bob > > At 20:35 22/03/2012, Bradner, Scott wrote: > >> On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote: >> >> > Ruediger, >> > >> > [Scott, a question for you at the end] >> > >> > >> > >> > I prefer your erratum suggestion because it flags the problem in >> the doc that now needs clarifying, so it's more likely to be noticed >> by people reading the deprecated text. But we'll have to see whether >> this would be accepted as an erratum. The relevant rule is #7 here: >> > >> > >> > "Changes that modify the working of a protocol to something that >> might be different from the intended consensus when the document was >> approved should be either Hold for Document Update or Rejected. >> Deciding between these two depends on judgment. Changes that are >> clearly modifications to the intended consensus, or involve large >> textual changes, should be Rejected. In unclear situations, small >> changes can be Hold for Document Update. " >> > >> > If we wrote an erratum to RFC5559, it would be legitimate, because >> the para you have quoted has two contradictory statements in it >> anyway. I doubt an erratum can refer to an RFC published later >> (3-in-1), because errata are meant to correct what the document >> should have said at the time. I think we could compose an erratum >> that resolved the contradiction in that paragraph while at the same >> time making it "not inconsistent" with what we now want to say in >> 3-in-1. >> > >> > Scott, can you advise? >> >> that sounds logical >> >> Scott > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- 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://kn.inf.uni-tuebingen.de From Ruediger.Geib@telekom.de Fri Mar 23 03:06:06 2012 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 CA33E21F84EC for ; Fri, 23 Mar 2012 03:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG0h2nD5Kdaf for ; Fri, 23 Mar 2012 03:06:02 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id DFDFA21F8514 for ; Fri, 23 Mar 2012 03:06:01 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 23 Mar 2012 11:05:28 +0100 Received: from HE113657.emea1.cds.t-internal.com (10.134.99.17) by HE113472.emea1.cds.t-internal.com (10.134.93.130) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 23 Mar 2012 11:05:16 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.76]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 23 Mar 2012 11:05:16 +0100 From: To: Date: Fri, 23 Mar 2012 11:05:15 +0100 Thread-Topic: [PCN] lets try again - a chair asking this time Thread-Index: Ac0IaTiMik9YXRUzTvOcnBt0/Gd2gAAcwArg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A475C595@HE111648.emea1.cds.t-internal.com> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> In-Reply-To: <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:06:07 -0000 Bob, thanks, your proposal on log and alert (and the proposed erratum) work well with me. Regards, Ruediger -----Original Message----- From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: Thursday, March 22, 2012 9:20 PM To: Geib, R=FCdiger; sob@harvard.edu Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time Ruediger, [Scott, a question for you at the end] At 08:07 21/03/2012, Ruediger.Geib@telekom.de wrote: >Hi Scott, > >the passage you quote should result from a misconfiguration or an attack. > > Treatment of non-PCN-packets confused with a PCN-packet > due to DSCP/ECN codepoinzt setting: > ... > In the absence of any operator-specific > configuration for this case, by > default an implementation SHOULD re-mark > the DSCP to zero. > ... > Clearing the ECN field is not an appropriate > policing action, because a network node ought not to interfere > with an e2e signal. Even if such packets seem like an attack, > drop would be overkill, because such an attack can be neutralised > by just re-marking the DSCP. And DSCP re-marking in the network > is legitimate, because the DSCP is not considered an e2e signal. > >What's done here is remarking of a flow with a DSCP that has been >agreed between two parties. On a consumer UNI, this may be an attack, >on an NNI, this could indicate a misconfiguration. Yes, when I realised this could be a mistake or an attack, I realised remarking the DSCP was the right approach to recommend, because it allows the operator to control this as part of their general DSCP re-marking policy. BTW, the default of "re-mark to zero", was merely so /implementers/ have a default. It's not intended to be the recommended policy for operator= s. >In the latter case, >a management alert seems reasonable. Text to that may be added. Good catch. In fact, an alert for an attack is also worth suggesting. I suggest the following text after "...re-mark the DSCP to zero (000000)." "Whichever policing action is chosen, the PCN-ingress-node SHOULD log the event and MAY also raise an alarm. Alarms SHOULD be rate-limited so that the anomalous packets will not amplify into a flood of alarm messag= es." >I further quote the PCN architecture, which is informational, on the >Ingress Node behaviour: > > Police - police, by dropping any packets received with a DSCP > indicating PCN transport that do not belong to an admitted flow. > (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.) Similarly, > police packets that are part of a previously admitted flow, to > check that the flow keeps to the agreed rate or flowspec (eg, see > [RFC1633] for a microflow and its NSIS equivalent). > >This isn't in line with the proposed 3-in-1 (standards track) behaviour. You're right. When we wrote this point in the architecture I think we were only thinking about blocked flows. I don't think that text was intended to catch packets that had never even asked to be admitted (i.e. mistakes or attacks). >Does this require an "Errata" atatement for RFC5559 (I'm not an expert on >editing RFCs and may be wrong here)? You're right that something needs doing about this statement in the architecture. We could say in 3-in-1 that it updates RFC5559. That would require an extra section in 3-in-1 saying exactly which part of the architecture it updates. I prefer your erratum suggestion because it flags the problem in the doc that now needs clarifying, so it's more likely to be noticed by people reading the deprecated text. But we'll have to see whether this would be accepted as an erratum. The relevant rule is #7 here: "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update. " If we wrote an erratum to RFC5559, it would be legitimate, because the para you have quoted has two contradictory statements in it anyway. I doubt an erratum can refer to an RFC published later (3-in-1), because errata are meant to correct what the document should have said at the time. I think we could compose an erratum that resolved the contradiction in that paragraph while at the same time making it "not inconsistent" with what we now want to say in 3-in-1. Scott, can you advise? Bob >Regards, > >Ruediger > >________________________________ > >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >Of Bradner, Scott >Sent: Tuesday, March 20, 2012 5:37 PM >To: pcn@ietf.org >Subject: [PCN] lets try again - a chair asking this time > > >please let the list know what you think > >Scott > >Scott O Bradner >Senior Technology Consultant > > > >Begin forwarded message: > > > > > > Date: Mon, 12 Mar 2012 03:30:11 +0000 > To: "PCN IETF list" > From: Bob Briscoe > Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.t= xt > > PCN folks, > > Following IESG review (particularly Adrian Farrel's > being the most comprehensive and useful), we've posted a new > version of the PCN 3-in-1 encoding. > > As well as a number of editorial changes, some > technical changes were needed in order to satisfy Adrian's request > to specify exactly what an implementer has to do at the ingress to > allow ECN to co-exist with PCN, and what defaults should be set to. > > In particular, for a non-PCN packet (i.e. doesn't > match any flow-state) that clashes with a PCN DSCP and is > ECN-capable, the recommended choice of 3 is: > > * re-mark the DSCP to a DSCP that is not > PCN-compatible; > > > > > [...] > In the > absence of any operator-specific > configuration for this case, by > default an implementation SHOULD re-mark > the DSCP to zero. > > > > Actually, the whole of the ingress behaviour > section (5.1) has been re-written, incorporating material that was > previously repeated in both edge-behaviours (agreed with IESG and > with edge-behaviour authors, of course). Altho it largely does the > same thing technically, it is written to cover the complete range > of possible scenarios, and it now gives defaults and recommended > choices. I don't think it's controversial, but shout if it is. > < > http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 > > > > > > Bob > > PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09= : > > * Added note about fail-safe to protect > other traffic in the > event of tunnel misconfiguration. > > * Changed section heading to be about applicabilit= y of > environments to the encoding, rather than > the encoding to the > environments. > > * Completely re-wrote PCN-ingress Node > Behaviour section. > > * Changed PCN interior node to PCN-node > where the term was > intended to include all PCN-nodes. > > * Clarified status of ECN/PCN co-existence > appendix. Removed > inconsistent assertion in this appendix > that an admission- > control DSCP alone can indicate that > arriving traffic is PCN- > traffic. > > * A few clarifying editorial amendments and > updated refs. > > > > > > From: > To: , > >, , > , > Date: Sun, 11 Mar 2012 17:52:23 -0700 > Subject: New Version Notification - > draft-ietf-pcn-3-in-1-encoding-09.txt > > New version (-09) has been submitted for > draft-ietf-pcn-3-in-1-encoding-09.txt. > >http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt > > > Diff from previous version: > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09 > > IETF Secretariat. > > > >________________________________________________________________ > Bob Briscoe, BT > Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Fri Mar 23 03:15:30 2012 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 52BC121F850B for ; Fri, 23 Mar 2012 03:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac3BjH5w8O1v for ; Fri, 23 Mar 2012 03:15:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id A63D721F84B6 for ; Fri, 23 Mar 2012 03:15:25 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Mar 2012 10:15:18 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.164]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 23 Mar 2012 10:15:18 +0000 From: To: , Date: Fri, 23 Mar 2012 10:15:23 +0000 Thread-Topic: [PCN] lets try again - a chair asking this time Thread-Index: Ac0IaTiMik9YXRUzTvOcnBt0/Gd2gAAcwArgAABnxJA= Message-ID: <9510D26531EF184D9017DF24659BB87F331D4BEED3@EMV65-UKRD.domain1.systemhost.net> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A475C595@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A475C595@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:15:30 -0000 Sounds good to me -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Ruedi= ger.Geib@telekom.de Sent: 23 March 2012 10:05 To: Briscoe,RJ,Bob,DUB8 R Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time Bob, thanks, your proposal on log and alert (and the proposed erratum) work well with me. Regards, Ruediger -----Original Message----- From: Bob Briscoe [mailto:bob.briscoe@bt.com] Sent: Thursday, March 22, 2012 9:20 PM To: Geib, R=FCdiger; sob@harvard.edu Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time Ruediger, [Scott, a question for you at the end] At 08:07 21/03/2012, Ruediger.Geib@telekom.de wrote: >Hi Scott, > >the passage you quote should result from a misconfiguration or an attack. > > Treatment of non-PCN-packets confused with a PCN-packet > due to DSCP/ECN codepoinzt setting: > ... > In the absence of any operator-specific > configuration for this case, by > default an implementation SHOULD re-mark > the DSCP to zero. > ... > Clearing the ECN field is not an appropriate > policing action, because a network node ought not to interfere > with an e2e signal. Even if such packets seem like an attack, > drop would be overkill, because such an attack can be neutralised > by just re-marking the DSCP. And DSCP re-marking in the network > is legitimate, because the DSCP is not considered an e2e signal. > >What's done here is remarking of a flow with a DSCP that has been >agreed between two parties. On a consumer UNI, this may be an attack, >on an NNI, this could indicate a misconfiguration. Yes, when I realised this could be a mistake or an attack, I realised remarking the DSCP was the right approach to recommend, because it allows the operator to control this as part of their general DSCP re-marking policy. BTW, the default of "re-mark to zero", was merely so /implementers/ have a default. It's not intended to be the recommended policy for operator= s. >In the latter case, >a management alert seems reasonable. Text to that may be added. Good catch. In fact, an alert for an attack is also worth suggesting. I suggest the following text after "...re-mark the DSCP to zero (000000)." "Whichever policing action is chosen, the PCN-ingress-node SHOULD log the event and MAY also raise an alarm. Alarms SHOULD be rate-limited so that the anomalous packets will not amplify into a flood of alarm messag= es." >I further quote the PCN architecture, which is informational, on the >Ingress Node behaviour: > > Police - police, by dropping any packets received with a DSCP > indicating PCN transport that do not belong to an admitted flow. > (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.) Similarly, > police packets that are part of a previously admitted flow, to > check that the flow keeps to the agreed rate or flowspec (eg, see > [RFC1633] for a microflow and its NSIS equivalent). > >This isn't in line with the proposed 3-in-1 (standards track) behaviour. You're right. When we wrote this point in the architecture I think we were only thinking about blocked flows. I don't think that text was intended to catch packets that had never even asked to be admitted (i.e. mistakes or attacks). >Does this require an "Errata" atatement for RFC5559 (I'm not an expert on >editing RFCs and may be wrong here)? You're right that something needs doing about this statement in the architecture. We could say in 3-in-1 that it updates RFC5559. That would require an extra section in 3-in-1 saying exactly which part of the architecture it updates. I prefer your erratum suggestion because it flags the problem in the doc that now needs clarifying, so it's more likely to be noticed by people reading the deprecated text. But we'll have to see whether this would be accepted as an erratum. The relevant rule is #7 here: "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected. In unclear situations, small changes can be Hold for Document Update. " If we wrote an erratum to RFC5559, it would be legitimate, because the para you have quoted has two contradictory statements in it anyway. I doubt an erratum can refer to an RFC published later (3-in-1), because errata are meant to correct what the document should have said at the time. I think we could compose an erratum that resolved the contradiction in that paragraph while at the same time making it "not inconsistent" with what we now want to say in 3-in-1. Scott, can you advise? Bob >Regards, > >Ruediger > >________________________________ > >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >Of Bradner, Scott >Sent: Tuesday, March 20, 2012 5:37 PM >To: pcn@ietf.org >Subject: [PCN] lets try again - a chair asking this time > > >please let the list know what you think > >Scott > >Scott O Bradner >Senior Technology Consultant > > > >Begin forwarded message: > > > > > > Date: Mon, 12 Mar 2012 03:30:11 +0000 > To: "PCN IETF list" > From: Bob Briscoe > Subject: New Version: draft-ietf-pcn-3-in-1-encoding-09.t= xt > > PCN folks, > > Following IESG review (particularly Adrian Farrel's > being the most comprehensive and useful), we've posted a new > version of the PCN 3-in-1 encoding. > > As well as a number of editorial changes, some > technical changes were needed in order to satisfy Adrian's request > to specify exactly what an implementer has to do at the ingress to > allow ECN to co-exist with PCN, and what defaults should be set to. > > In particular, for a non-PCN packet (i.e. doesn't > match any flow-state) that clashes with a PCN DSCP and is > ECN-capable, the recommended choice of 3 is: > > * re-mark the DSCP to a DSCP that is not > PCN-compatible; > > > > > [...] > In the > absence of any operator-specific > configuration for this case, by > default an implementation SHOULD re-mark > the DSCP to zero. > > > > Actually, the whole of the ingress behaviour > section (5.1) has been re-written, incorporating material that was > previously repeated in both edge-behaviours (agreed with IESG and > with edge-behaviour authors, of course). Altho it largely does the > same thing technically, it is written to cover the complete range > of possible scenarios, and it now gives defaults and recommended > choices. I don't think it's controversial, but shout if it is. > < > http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 > > > > > > Bob > > PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -09= : > > * Added note about fail-safe to protect > other traffic in the > event of tunnel misconfiguration. > > * Changed section heading to be about applicabilit= y of > environments to the encoding, rather than > the encoding to the > environments. > > * Completely re-wrote PCN-ingress Node > Behaviour section. > > * Changed PCN interior node to PCN-node > where the term was > intended to include all PCN-nodes. > > * Clarified status of ECN/PCN co-existence > appendix. Removed > inconsistent assertion in this appendix > that an admission- > control DSCP alone can indicate that > arriving traffic is PCN- > traffic. > > * A few clarifying editorial amendments and > updated refs. > > > > > > From: > To: , > >, , > , > Date: Sun, 11 Mar 2012 17:52:23 -0700 > Subject: New Version Notification - > draft-ietf-pcn-3-in-1-encoding-09.txt > > New version (-09) has been submitted for > draft-ietf-pcn-3-in-1-encoding-09.txt. > >http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt > > > Diff from previous version: > >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09 > > IETF Secretariat. > > > >________________________________________________________________ > Bob Briscoe, BT > Innovate & Design > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From tm444@hermes.cam.ac.uk Fri Mar 23 03:29:28 2012 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 3070D21F84EB for ; Fri, 23 Mar 2012 03:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.266 X-Spam-Level: X-Spam-Status: No, score=-6.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fakwYIWwS+vU for ; Fri, 23 Mar 2012 03:29:24 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id A98A121F84D2 for ; Fri, 23 Mar 2012 03:29:23 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:54881) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1SB1kH-0001Eq-sH (Exim 4.72) (return-path ); Fri, 23 Mar 2012 10:29:21 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Toby Moncaster In-Reply-To: <9510D26531EF184D9017DF24659BB87F331D4BEED3@EMV65-UKRD.domain1.systemhost.net> Date: Fri, 23 Mar 2012 10:29:21 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <263712C5-2C56-48B9-820C-77BAC9A22265@cl.cam.ac.uk> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A475C595@HE111648.emea1.cds.t-internal.com> <9510D26531EF184D9017DF24659BB87F331D4BEED3@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1257) Sender: "T. Moncaster" Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:29:28 -0000 +1 On 23 Mar 2012, at 10:15, wrote: > Sounds good to me >=20 >=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Ruediger.Geib@telekom.de > Sent: 23 March 2012 10:05 > To: Briscoe,RJ,Bob,DUB8 R > Cc: pcn@ietf.org > Subject: Re: [PCN] lets try again - a chair asking this time >=20 > Bob, >=20 > thanks, your proposal on log and alert (and the proposed erratum) > work well with me. >=20 > Regards, >=20 > Ruediger >=20 > -----Original Message----- > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > Sent: Thursday, March 22, 2012 9:20 PM > To: Geib, R=FCdiger; sob@harvard.edu > Cc: pcn@ietf.org > Subject: Re: [PCN] lets try again - a chair asking this time >=20 > Ruediger, >=20 > [Scott, a question for you at the end] >=20 > At 08:07 21/03/2012, Ruediger.Geib@telekom.de wrote: >> Hi Scott, >>=20 >> the passage you quote should result from a misconfiguration or an = attack. >>=20 >> Treatment of non-PCN-packets confused with a PCN-packet >> due to DSCP/ECN codepoinzt setting: >> ... >> In the absence of any operator-specific >> configuration for this case, by >> default an implementation SHOULD re-mark >> the DSCP to zero. >> ... >> Clearing the ECN field is not an appropriate >> policing action, because a network node ought not to interfere >> with an e2e signal. Even if such packets seem like an attack, >> drop would be overkill, because such an attack can be = neutralised >> by just re-marking the DSCP. And DSCP re-marking in the network >> is legitimate, because the DSCP is not considered an e2e signal. >>=20 >> What's done here is remarking of a flow with a DSCP that has been >> agreed between two parties. On a consumer UNI, this may be an attack, >> on an NNI, this could indicate a misconfiguration. >=20 > Yes, when I realised this could be a mistake or an attack, I realised > remarking the DSCP was the right approach to recommend, because it > allows the operator to control this as part of their general DSCP > re-marking policy. >=20 > BTW, the default of "re-mark to zero", was merely so /implementers/ > have a default. It's not intended to be the recommended policy for = operators. >=20 >> In the latter case, >> a management alert seems reasonable. Text to that may be added. >=20 > Good catch. In fact, an alert for an attack is also worth suggesting. > I suggest the following text after "...re-mark the DSCP to zero = (000000)." >=20 > "Whichever policing action is chosen, the PCN-ingress-node SHOULD log > the event and MAY also raise an alarm. Alarms SHOULD be rate-limited > so that the anomalous packets will not amplify into a flood of alarm = messages." >=20 >=20 >> I further quote the PCN architecture, which is informational, on the >> Ingress Node behaviour: >>=20 >> Police - police, by dropping any packets received with a DSCP >> indicating PCN transport that do not belong to an admitted flow. >> (A prospective PCN-flow that is rejected could be blocked or >> admitted into a lower-priority behaviour aggregate.) Similarly, >> police packets that are part of a previously admitted flow, to >> check that the flow keeps to the agreed rate or flowspec (eg, = see >> [RFC1633] for a microflow and its NSIS equivalent). >>=20 >> This isn't in line with the proposed 3-in-1 (standards track) = behaviour. >=20 > You're right. When we wrote this point in the architecture I think we > were only thinking about blocked flows. I don't think that text was > intended to catch packets that had never even asked to be admitted > (i.e. mistakes or attacks). >=20 >> Does this require an "Errata" atatement for RFC5559 (I'm not an = expert on >> editing RFCs and may be wrong here)? >=20 > You're right that something needs doing about this statement in the > architecture. We could say in 3-in-1 that it updates RFC5559. That > would require an extra section in 3-in-1 saying exactly which part of > the architecture it updates. >=20 > I prefer your erratum suggestion because it flags the problem in the > doc that now needs clarifying, so it's more likely to be noticed by > people reading the deprecated text. But we'll have to see whether > this would be accepted as an erratum. The relevant rule is #7 here: > >=20 > "Changes that modify the working of a protocol to something that > might be different from the intended consensus when the document was > approved should be either Hold for Document Update or Rejected. > Deciding between these two depends on judgment. Changes that are > clearly modifications to the intended consensus, or involve large > textual changes, should be Rejected. In unclear situations, small > changes can be Hold for Document Update. " >=20 > If we wrote an erratum to RFC5559, it would be legitimate, because > the para you have quoted has two contradictory statements in it > anyway. I doubt an erratum can refer to an RFC published later > (3-in-1), because errata are meant to correct what the document > should have said at the time. I think we could compose an erratum > that resolved the contradiction in that paragraph while at the same > time making it "not inconsistent" with what we now want to say in = 3-in-1. >=20 > Scott, can you advise? >=20 >=20 > Bob >=20 >=20 >> Regards, >>=20 >> Ruediger >>=20 >> ________________________________ >>=20 >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >> Of Bradner, Scott >> Sent: Tuesday, March 20, 2012 5:37 PM >> To: pcn@ietf.org >> Subject: [PCN] lets try again - a chair asking this time >>=20 >>=20 >> please let the list know what you think >>=20 >> Scott >>=20 >> Scott O Bradner >> Senior Technology Consultant >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>=20 >>=20 >>=20 >>=20 >> Date: Mon, 12 Mar 2012 03:30:11 +0000 >> To: "PCN IETF list" >> From: Bob Briscoe >> Subject: New Version: = draft-ietf-pcn-3-in-1-encoding-09.txt >>=20 >> PCN folks, >>=20 >> Following IESG review (particularly Adrian Farrel's >> being the most comprehensive and useful), we've posted a new >> version of the PCN 3-in-1 encoding. >>=20 >> As well as a number of editorial changes, some >> technical changes were needed in order to satisfy Adrian's request >> to specify exactly what an implementer has to do at the ingress to >> allow ECN to co-exist with PCN, and what defaults should be set to. >>=20 >> In particular, for a non-PCN packet (i.e. doesn't >> match any flow-state) that clashes with a PCN DSCP and is >> ECN-capable, the recommended choice of 3 is: >>=20 >> * re-mark the DSCP to a DSCP that is not >> PCN-compatible; >>=20 >>=20 >>=20 >>=20 >> [...] >> In the >> absence of any operator-specific >> configuration for this case, by >> default an implementation SHOULD re-mark >> the DSCP to zero. >>=20 >>=20 >>=20 >> Actually, the whole of the ingress behaviour >> section (5.1) has been re-written, incorporating material that was >> previously repeated in both edge-behaviours (agreed with IESG and >> with edge-behaviour authors, of course). Altho it largely does the >> same thing technically, it is written to cover the complete range >> of possible scenarios, and it now gives defaults and recommended >> choices. I don't think it's controversial, but shout if it is. >> < >> = http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section-5.1 >> = = > >>=20 >>=20 >>=20 >> Bob >>=20 >> PS. Changes =46rom draft-ietf-pcn-3-in-1-encoding-08 = to -09: >>=20 >> * Added note about fail-safe to protect >> other traffic in the >> event of tunnel misconfiguration. >>=20 >> * Changed section heading to be about = applicability of >> environments to the encoding, rather than >> the encoding to the >> environments. >>=20 >> * Completely re-wrote PCN-ingress Node >> Behaviour section. >>=20 >> * Changed PCN interior node to PCN-node >> where the term was >> intended to include all PCN-nodes. >>=20 >> * Clarified status of ECN/PCN co-existence >> appendix. Removed >> inconsistent assertion in this appendix >> that an admission- >> control DSCP alone can indicate that >> arriving traffic is PCN- >> traffic. >>=20 >> * A few clarifying editorial amendments and >> updated refs. >>=20 >>=20 >>=20 >>=20 >>=20 >> From: >> To: , >>=20 >> , = , >> , = >> Date: Sun, 11 Mar 2012 17:52:23 -0700 >> Subject: New Version Notification - >> draft-ietf-pcn-3-in-1-encoding-09.txt >>=20 >> New version (-09) has been submitted for >> draft-ietf-pcn-3-in-1-encoding-09.txt. >>=20 >> = http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09.txt >>=20 >>=20 >> Diff from previous version: >>=20 >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09 >>=20 >> IETF Secretariat. >>=20 >>=20 >>=20 >> ________________________________________________________________ >> Bob Briscoe, BT >> Innovate & Design >>=20 >> = ________________________________________________________________ >> Bob Briscoe, BT Innovate & = Design >>=20 >>=20 >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design >=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 karagian@cs.utwente.nl Fri Mar 23 03:30:25 2012 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 238E521F8505 for ; Fri, 23 Mar 2012 03:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ocSopebjvN7 for ; Fri, 23 Mar 2012 03:30:21 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id A9ECE21F84D5 for ; Fri, 23 Mar 2012 03:30:20 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 23 Mar 2012 11:30:26 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 23 Mar 2012 11:30:19 +0100 From: To: , Thread-Topic: [PCN] lets try again - a chair asking this time Thread-Index: AQHNCGkza/Ow8il9OUGlwXRtWwuu+5Z3l0yAgAAC1YCAAAPngIAAEQHg Date: Fri, 23 Mar 2012 10:30:19 +0000 Message-ID: References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A475C595@HE111648.emea1.cds.t-internal.com> <9510D26531EF184D9017DF24659BB87F331D4BEED3@EMV65-UKRD.domain1.systemhost.net> <263712C5-2C56-48B9-820C-77BAC9A22265@cl.cam.ac.uk> In-Reply-To: <263712C5-2C56-48B9-820C-77BAC9A22265@cl.cam.ac.uk> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:30:25 -0000 +1 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Toby Moncaster > Sent: vrijdag 23 maart 2012 11:29 > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] lets try again - a chair asking this time >=20 > +1 > On 23 Mar 2012, at 10:15, wrote: >=20 > > Sounds good to me > > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > Ruediger.Geib@telekom.de > > Sent: 23 March 2012 10:05 > > To: Briscoe,RJ,Bob,DUB8 R > > Cc: pcn@ietf.org > > Subject: Re: [PCN] lets try again - a chair asking this time > > > > Bob, > > > > thanks, your proposal on log and alert (and the proposed erratum) work > > well with me. > > > > Regards, > > > > Ruediger > > > > -----Original Message----- > > From: Bob Briscoe [mailto:bob.briscoe@bt.com] > > Sent: Thursday, March 22, 2012 9:20 PM > > To: Geib, R=FCdiger; sob@harvard.edu > > Cc: pcn@ietf.org > > Subject: Re: [PCN] lets try again - a chair asking this time > > > > Ruediger, > > > > [Scott, a question for you at the end] > > > > At 08:07 21/03/2012, Ruediger.Geib@telekom.de wrote: > >> Hi Scott, > >> > >> the passage you quote should result from a misconfiguration or an atta= ck. > >> > >> Treatment of non-PCN-packets confused with a PCN-packet > >> due to DSCP/ECN codepoinzt setting: > >> ... > >> In the absence of any operator-specific > >> configuration for this case, by > >> default an implementation SHOULD re-mark > >> the DSCP to zero. > >> ... > >> Clearing the ECN field is not an appropriate > >> policing action, because a network node ought not to interfere > >> with an e2e signal. Even if such packets seem like an attack, > >> drop would be overkill, because such an attack can be neutralised > >> by just re-marking the DSCP. And DSCP re-marking in the network > >> is legitimate, because the DSCP is not considered an e2e signal. > >> > >> What's done here is remarking of a flow with a DSCP that has been > >> agreed between two parties. On a consumer UNI, this may be an attack, > >> on an NNI, this could indicate a misconfiguration. > > > > Yes, when I realised this could be a mistake or an attack, I realised > > remarking the DSCP was the right approach to recommend, because it > > allows the operator to control this as part of their general DSCP > > re-marking policy. > > > > BTW, the default of "re-mark to zero", was merely so /implementers/ > > have a default. It's not intended to be the recommended policy for > operators. > > > >> In the latter case, > >> a management alert seems reasonable. Text to that may be added. > > > > Good catch. In fact, an alert for an attack is also worth suggesting. > > I suggest the following text after "...re-mark the DSCP to zero (000000= )." > > > > "Whichever policing action is chosen, the PCN-ingress-node SHOULD log > > the event and MAY also raise an alarm. Alarms SHOULD be rate-limited > > so that the anomalous packets will not amplify into a flood of alarm > messages." > > > > > >> I further quote the PCN architecture, which is informational, on the > >> Ingress Node behaviour: > >> > >> Police - police, by dropping any packets received with a DSCP > >> indicating PCN transport that do not belong to an admitted flow. > >> (A prospective PCN-flow that is rejected could be blocked or > >> admitted into a lower-priority behaviour aggregate.) Similarly, > >> police packets that are part of a previously admitted flow, to > >> check that the flow keeps to the agreed rate or flowspec (eg, see > >> [RFC1633] for a microflow and its NSIS equivalent). > >> > >> This isn't in line with the proposed 3-in-1 (standards track) behaviou= r. > > > > You're right. When we wrote this point in the architecture I think we > > were only thinking about blocked flows. I don't think that text was > > intended to catch packets that had never even asked to be admitted > > (i.e. mistakes or attacks). > > > >> Does this require an "Errata" atatement for RFC5559 (I'm not an > >> expert on editing RFCs and may be wrong here)? > > > > You're right that something needs doing about this statement in the > > architecture. We could say in 3-in-1 that it updates RFC5559. That > > would require an extra section in 3-in-1 saying exactly which part of > > the architecture it updates. > > > > I prefer your erratum suggestion because it flags the problem in the > > doc that now needs clarifying, so it's more likely to be noticed by > > people reading the deprecated text. But we'll have to see whether this > > would be accepted as an erratum. The relevant rule is #7 here: > > > > > > "Changes that modify the working of a protocol to something that might > > be different from the intended consensus when the document was > > approved should be either Hold for Document Update or Rejected. > > Deciding between these two depends on judgment. Changes that are > > clearly modifications to the intended consensus, or involve large > > textual changes, should be Rejected. In unclear situations, small > > changes can be Hold for Document Update. " > > > > If we wrote an erratum to RFC5559, it would be legitimate, because the > > para you have quoted has two contradictory statements in it anyway. I > > doubt an erratum can refer to an RFC published later (3-in-1), because > > errata are meant to correct what the document should have said at the > > time. I think we could compose an erratum that resolved the > > contradiction in that paragraph while at the same time making it "not > > inconsistent" with what we now want to say in 3-in-1. > > > > Scott, can you advise? > > > > > > Bob > > > > > >> Regards, > >> > >> Ruediger > >> > >> ________________________________ > >> > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > >> Bradner, Scott > >> Sent: Tuesday, March 20, 2012 5:37 PM > >> To: pcn@ietf.org > >> Subject: [PCN] lets try again - a chair asking this time > >> > >> > >> please let the list know what you think > >> > >> Scott > >> > >> Scott O Bradner > >> Senior Technology Consultant > >> > >> > >> > >> Begin forwarded message: > >> > >> > >> > >> > >> > >> Date: Mon, 12 Mar 2012 03:30:11 +0000 > >> To: "PCN IETF list" > >> From: Bob Briscoe > >> Subject: New Version: > >> draft-ietf-pcn-3-in-1-encoding-09.txt > >> > >> PCN folks, > >> > >> Following IESG review (particularly Adrian Farrel's > >> being the most comprehensive and useful), we've posted a new version > >> of the PCN 3-in-1 encoding. > >> > >> As well as a number of editorial changes, some > >> technical changes were needed in order to satisfy Adrian's request to > >> specify exactly what an implementer has to do at the ingress to allow > >> ECN to co-exist with PCN, and what defaults should be set to. > >> > >> In particular, for a non-PCN packet (i.e. doesn't > >> match any flow-state) that clashes with a PCN DSCP and is > >> ECN-capable, the recommended choice of 3 is: > >> > >> * re-mark the DSCP to a DSCP that is not > >> PCN-compatible; > >> > >> > >> > >> > >> [...] > >> In the > >> absence of any operator-specific > >> configuration for this case, by > >> default an implementation SHOULD re-mark > >> the DSCP to zero. > >> > >> > >> > >> Actually, the whole of the ingress behaviour section > >> (5.1) has been re-written, incorporating material that was previously > >> repeated in both edge-behaviours (agreed with IESG and with > >> edge-behaviour authors, of course). Altho it largely does the same > >> thing technically, it is written to cover the complete range of > >> possible scenarios, and it now gives defaults and recommended > >> choices. I don't think it's controversial, but shout if it is. > >> < > >> http://tools.ietf.org/html/draft-ietf-pcn-3-in-1-encoding-09#section- > >> 5.1 > >> >> -5.1> > > >> > >> > >> > >> Bob > >> > >> PS. Changes From draft-ietf-pcn-3-in-1-encoding-08 to -= 09: > >> > >> * Added note about fail-safe to protect other > >> traffic in the > >> event of tunnel misconfiguration. > >> > >> * Changed section heading to be about applicabil= ity of > >> environments to the encoding, rather than the > >> encoding to the > >> environments. > >> > >> * Completely re-wrote PCN-ingress Node > >> Behaviour section. > >> > >> * Changed PCN interior node to PCN-node where > >> the term was > >> intended to include all PCN-nodes. > >> > >> * Clarified status of ECN/PCN co-existence > >> appendix. Removed > >> inconsistent assertion in this appendix that > >> an admission- > >> control DSCP alone can indicate that arriving > >> traffic is PCN- > >> traffic. > >> > >> * A few clarifying editorial amendments and > >> updated refs. > >> > >> > >> > >> > >> > >> From: > >> To: , > >> > >> , > , > >> , > >> Date: Sun, 11 Mar 2012 17:52:23 -0700 > >> Subject: New Version Notification - > >> draft-ietf-pcn-3-in-1-encoding-09.txt > >> > >> New version (-09) has been submitted for > >> draft-ietf-pcn-3-in-1-encoding-09.txt. > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-09 > >> .txt > >> > >> > >> Diff from previous version: > >> > >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pcn-3-in-1-encoding-09 > >> > >> IETF Secretariat. > >> > >> > >> > >> > __________________________________________________________ > ______ > >> Bob Briscoe, BT > >> Innovate & Design > >> > >> > __________________________________________________________ > ______ > >> Bob Briscoe, BT Innovate & Desig= n > >> > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From tom.taylor.stds@gmail.com Fri Mar 23 04:34:50 2012 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 E941721F8535 for ; Fri, 23 Mar 2012 04:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlichCPBzRnG for ; Fri, 23 Mar 2012 04:34:49 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1821F8543 for ; Fri, 23 Mar 2012 04:34:49 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2741073obb.31 for ; Fri, 23 Mar 2012 04:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=8Z6uopCTJE5cqHPJLj9OE/lNyOsE8qBrnrp3/1l3okg=; b=GiGklYh0/CuU0dO7tJgGI9eve1OT0MuTSfDDHOPJm3kI/zJyxJCogftJHN3omf+vVY euGxYuwZjZpwALDg9HhH+v+CVvpjDzd+IcZD1VDYjD7cvSr8FIX+PSnvNPAYsB5UyvwH gLKmCQaZE0mrwSAvzFXPAFh1tK0r9ylhgYqzxrApuLZulrQxj6ftMgKFPvuFe7l3xF/j CMR+H8IORwmm5qQSwPkYW48grgkfLrSod1vpUXOg/sbSCE4HWFuTtlnQcpJFJT0TJkm5 O9YJhz3VQTMauCtIHf3Aru/3Vb7oZiRLk7KwNxk8Oyo/m3HHQP3Y4G3hWqfhRMCecz2+ CffQ== Received: by 10.182.159.65 with SMTP id xa1mr14161119obb.25.1332502489394; Fri, 23 Mar 2012 04:34:49 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id h7sm5921236oeh.9.2012.03.23.04.34.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 04:34:48 -0700 (PDT) Message-ID: <4F6C5FD7.1000804@gmail.com> Date: Fri, 23 Mar 2012 07:34:47 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bob Briscoe References: <4F6A2736.8040403@gmail.com> <4F6A44C3.20506@informatik.uni-tuebingen.de> <4F6A4C7B.8050607@gmail.com> <4F6A69B8.6010601@informatik.uni-tuebingen.de> <201203222258.q2MMwQfX029549@bagheera.jungle.bt.co.uk> In-Reply-To: <201203222258.q2MMwQfX029549@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120323-0, 23/03/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn Subject: Re: [PCN] Explanation of changes in the PCN edge behaviour drafts 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: Fri, 23 Mar 2012 11:34:51 -0000 I'm left wondering what to do with all these remarks, given that we have passed not only WGLC but also IESG approval. I will await AD direction. The most I can do at this point is surmise that I have erred as editor and some of my changes should be backed out. On 22/03/2012 6:57 PM, Bob Briscoe wrote: > Tom, > > inline tagged [BB]... > > At 23:52 21/03/2012, Michael Menth wrote: >> Hi Tom, >> Am 21.03.2012 22:47, schrieb Tom Taylor: >>> My comments in turn below, marked with [PTT]. >>> On 21/03/2012 5:14 PM, Michael Menth wrote: >>>> Hi Tom, >>>> >>>>> NEW >>>>> >>>>> Packets at the ingress to the domain are classified as either PCN or >>>>> non-PCN. Non-PCN packets can share the network with PCN packets >>>>> within the domain. The encoding specified in [RFC5696] and used in >>>>> this document requires the use of the ECN fields. PCN-ingress-nodes >>>>> need to prevent ECN-capable traffic that uses the same DSCP as PCN >>>>> from entering the PCN-domain directly. This is not an issue when >>>>> tunneling of PCN-packets between the PCN-ingress-node and the PCN- >>>>> egress-node is done, as recommended in Section 5.1.2, provided that >>>>> the original ECN markings of arriving packets are preserved in the >>>>> encapsulated headers. > > [BB] Section 5.1.2 doesn't actually recommend tunnelling, at least not > in normative language. All it says is: > " As a result, the only way to construct > such filters reliably is to tunnel the packets from the PCN-ingress- > node to the PCN-egress-node. > " > In fact we shouldn't only receommend tunnelling, because that's not > actually true. One could implement CL-PCN by layering rather than > tunneling. This would work if PCN edge-nodes were the only IP-aware > nodes in the PCN domain, and PCN metering & marking was done at the > lower layer (e.g. MPLS) on interior nodes. > > This would affect the assumed core network behaviour too. At the start > of S.2. I suggest a sentence such as: > > OLD: > " This section describes the assumed behaviour for PCN-interior-nodes > in the PCN-domain. > " > SUGGESTED: > " This section describes the assumed behaviour for IP-aware > PCN-interior-nodes > in the PCN-domain. > " > > And add at end of Section 2: > "An alternative would be to use PCN in MPLS on interior nodes. In this > case all references to the PCN encoding for IP [3-in-1] would be > replaced by references to the PCN encoding for MPLS described in > Appendix A of [RFC5129] (Appendix C of [3-in-1] also gives useful > examples of the PCN encoding in MPLS). In the rest of this document > IP-aware interior nodes are assumed. " > > In addition, we should state in the introduction (and possibly the > abstract) that this doc assumes IP-aware PCN nodes, but MPLS interior > nodes are briefly discussed as an alternative. > > It may help to call these edge-behaviours CL-IP and SM-IP, not just CL & > SM. Then later someone could produce near-identical copies of these RFCs > called CL-MPLS and SM-MPLS (the latter makes more sense than the former > because of codepoint restrictions). These wouldn't use tunnelling, and > would refer to a different encoding, but would otherwise be fairly > identical. > > [Another alternative is to use Layer 3 Ethernet switches as interior > nodes. L3 switches do forwarding on Ethernet addresses, but they can > bury into the IP header in the payload for the Diffserv & ECN fields > (Microsoft has deployed ECN-marking on Layer-3 switches within its data > centres). However, there's no need to mention an Ethernet option in the > docs - it's a can-of-worms for standards because some see it as a > layering violation. This little aside was for the list, not the doc.] > > >>>> Moving the old text to 3-in-1 means that this doc is now aware of >>>> 3-in-1. Therefore, we should base this edge behavior no longer on >>>> baseline encoding (RFC5696) but on 3-in-1. >>> [PTT] I don't think we have to, although it might be reasonable. The >>> argument is that there is no need for the old text because we are >>> using tunneling. >> I'd suggest to substitute RFC5696 by 3-in-1 in general to avoid >> confusion by a soon obsoleted RFC. > > [BB] I agree. I believe the edge-behaviours and 3-in-1 are all going > through together so it would be wrong to refer to a doc that 3-in-1 > obsoletes. The RFC-Editor will substitute the appropriate RFCxxxx for > 3-in-1, which will be a normative reference. > > I'm afraid you will also need to substitute the new names for the two > marked codepoints (PM->ETM & EXP->ThM), but SM will only need one (ETM). > > > >>>>> 11. In the next paragraph, originally said that PCN packets of >>>>> non-admitted flows are dropped. Replaced this with "blocked" and a >>>>> backward reference to the definition of blocking in Section 1. >>>>> (Follow-through on comments by Brian Carpenter, fixed elsewhere. >>>> I think to remember that 3-in-1 recommended recoloring as preferred >>>> policing option. >>> >>> [PTT] We agreed on local policy as the answer when discussing Brian >>> Carpenter's review comments. > > [BB] There's a distinction needed between: > i) treatment of packets of a flow that has asked to be admitted but been > blocked and > ii) packets where there has never been a request for their flow to be > admitted, but they happen to be using a PCN-compatible DSCP and an > ECN-capable codepoint. > > For case (i) it would be perfectly reasonable to drop, but re-marking > the DSCP would also be a reasonable policy. > For case (ii) drop would be unreasonable, because these packets just > happen to be using a PCN codepoint outside the PCN domain, but they're > not PCN-traffic. PCN nodes have no business interfering with non-PCN > traffic. However they've got to do something to prevent confusion. So > the safest action is to re-mark the DSCP. > > If the behaviour for (i) & (ii) are different this could be awkward, > because it means the PCN-ingress has to remember all the flows it has > blocked in order to treat them differently from packets that never asked > to be admitted. How long does it remember blocked flows for? > > So a sensible policy would be to treat both (i) & (ii) the same to save > having to remember blocked flows. But from a standards viewpoint, we > should still make the distinction, because the treatment of each should > be a policy choice, not something we should prejudge. > > The edge-behaviour docs are the right place to deal with case (i), but > for the latter case both edge-behaviour docs need to refer to the new > Section 5.1 of [3-in-1]. The logic here is that edge-behaviours deal > with flow-related stuff, while 3-in-1 deals with individual packets. > [3-in-1] refers to the edge-behaviours for handling packets of signalled > flows. > > The split between specs here is unfortunate, but necessary. > > >>>>> 13. Section 5.1.3, basically editorial rearrangement of text to take >>>>> account of the fact that the ingress node will always perform >>>>> encapsulation. > > [BB] Again, there may need to be some reference to layering as an > alternative to tunnelling. > >>>>> Talking about extensions to the DiffServ MIB. >>>>> >>>>> OLD >>>>> >>>>> ... The required >>>>> extensions specifically include objects for re-marking the ECN field >>>>> at the PCN-ingress-node and an extension to the classifiers to >>>>> include the ECN field at PCN-interior and PCN-egress-nodes. In >>>>> addition, the MIB has to be extended to include a potential >>>>> encapsulation action following re-classification by ingress-egress- >>>>> aggregate. Finally, a new metering algorithm may need to be defined >>>>> at the PCN-interior-nodes to handle excess-traffic-marking. >>>>> >>>>> NEW >>>>> >>>>> ... The required >>>>> extensions specifically include an encapsulation action following re- >>>>> classification by ingress-egress-aggregate. In addition, the MIB >>>> which MIB? >>> >>> [PTT] DiffServ MIB [RFC3289], referenced in the document. >> ok, now I see the reference was some sentences before >> >>>> >>>>> has >>>>> to be extended to include objects for marking the ECN field in the >>>>> outer header at the PCN-ingress-node and an extension to the >>>>> classifiers to include the ECN field at PCN-interior and PCN-egress- >>>>> nodes. Finally, new metering algorithms may need to be defined at >>>>> the PCN-interior-nodes to handle threshold-marking and packet-size- >>>>> independent excess-traffic-marking. >>>> I do not understand why the defined marking algorithms are not >>>> sufficient. Also packet-size-independent excess-traffic-marking is >>>> defined (see 2.4 in RFC5670). >>> The above passage is talking about whether the DiffServ MIB supports >>> the defined marking algorithms, not saying that new algorithms are >>> needed. >> ok, understand > > [BB] The text is still misleading. We on the list only understand > because you've explained on the list. Perhaps: > > s/Finally, new metering algorithms may need to be defined/ > /Finally, new MIB entries for the metering algorithms may need to be > defined/ > > Cheers > > > > Bob > > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > From karagian@cs.utwente.nl Fri Mar 23 10:00:48 2012 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 65E8F21F84B9; Fri, 23 Mar 2012 10:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehADX+Vb7+6j; Fri, 23 Mar 2012 10:00:47 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 05A8421F84AA; Fri, 23 Mar 2012 10:00:46 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 23 Mar 2012 18:00:50 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 23 Mar 2012 18:00:42 +0100 From: To: , Thread-Topic: question on whether assumptions draft-ietf-tsvwg-rsvp-pcn-01.txt brake PCN CL and PCN SM specs Thread-Index: Ac0JFnnRmD7ThugwTJ6RFUmxYyQIAQ== Date: Fri, 23 Mar 2012 17:00:42 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.89.12.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [PCN] question on whether assumptions draft-ietf-tsvwg-rsvp-pcn-01.txt brake PCN CL and PCN SM specs 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: Fri, 23 Mar 2012 17:00:48 -0000 SGkgYWxsLA0KDQpUaGUgZHJhZnQtaWV0Zi10c3Z3Zy1yc3ZwLXBjbi0wMS50eHQgY29uc2lkZXJz IHRoYXQgdGhlIGZvbGxvd2luZyB0d28gYXNzdW1wdGlvbnMgY2FuIGJlIHN1cHBvcnRlZCB3aXRo b3V0IGJyZWFraW5nIHRoZSANCmRyYWZ0LWlldGYtcGNuLXNtLWVkZ2UtYmVoYXZpb3VyLTEwLnR4 dCAgYW5kIGRyYWZ0LWlldGYtcGNuLWNsLWVkZ2UtYmVoYXZpb3VyLTEzLnR4dCBiZWhhdmlvdXJz LiANCg0KbykgTW9yZSB0aGFuIG9uZSBJRUFzIGJldHdlZW4gc2FtZSBwYWlyIG9mIFBDTiBlZGdl IG5vZGVzIHNob3VsZCBiZSBzdXBwb3J0ZWQsIHdoaWxlIGVhY2ggb2YgdGhlbSBzaG91bGQgdXNl IGEgZGlmZmVyZW50IFBIQi1JRCB2YWx1ZSAoRFNDUCB2YWx1ZSkuDQpXaHk6IFRoaXMgaXMgdXNl ZnVsIGZvciB0aGUgY2FzZSB0aGF0IFdoZW4gSUVBIHN1cHBvcnRlZCBieSBhIFBDTi1pbmdyZXNz LW5vZGUgaXMgaW4gUENOLWFkbWlzc2lvbiBzdGF0ZSwgdGhlbiBiYXNlZCBvbiBsb2NhbCBwb2xp Y3ksIHJlcXVlc3RpbmcgZTJlIFJTVlAgc2Vzc2lvbiBzaG91bGQgYmUgZWl0aGVyIHJlamVjdGVk IG9yIG1hcHBlZCB0byBhbm90aGVyIElFQSB0aGF0IGlzIE5PVCBpbiBQQ04tYWRtaXNzaW9uLXN0 YXRlDQoNCg0KbykgV2hlbiBmb3IgSUVBIHN1cHBvcnRlZCBieSBQQ04taW5ncmVzcy1ub2RlIGlu Y29taW5nIHRyYWZmaWMgbmVlZHMgcmVkdWNlZCB0aGVuIGJhc2VkIG9uIGEgbG9jYWwgcG9saWN5 IGFuZCBmb3Igc2FtZSBJRUEsIHNlbGVjdHMgYSBudW1iZXIgb2YgZTJlIFJTVlAgc2Vzc2lvbnMg KGluZGl2aWR1YWwgZmxvd3MpICB0byBiZSBlaXRoZXIgdGVybWluYXRlZCBvciB0byByZWR1Y2Ug cmVzZXJ2ZWQgYmFuZHdpZHRoIG9mIGUyZSBSU1ZQIHNlc3Npb25zIChpbmRpdmlkdWFsIGZsb3dz ICksIGluIG9yZGVyIHRvIHNvbHZlIGNvbmdlc3Rpb24gaW4gUENOLWRvbWFpbi4NCldoeTogVGhp cyBpcyB1c2VmdWwsIHNpbmNlIGZsb3dzIHdpbGwgbm90IGJlIHRlcm1pbmF0ZWQgdW5uZWNlc3Nh cnksIGFuZCBhdCB0aGUgc2FtZSB0aW1lICB0aGUgSUVBIGJhbmR3aWR0aCBpcyByZWR1Y2VkIHRv IHNvbHZlIHRoZSBzZXZlcmUgY29uZ2VzdGlvbiENCg0KRHVyaW5nIHRoZSBwcmVzZW50YXRpb24g b2YgdGhlIGluaXRpYWwgUlNWUCBvdmVyIFBDTiBkcmFmdCBkdXJpbmcgdGhlIElFVEYgODEgKHRz dndnKSwgaWYgSSByZWNhbGwgd2VsbCwgaXQgd2FzIGFncmVlZCB0aGF0IHRoZXNlIGFzc3VtcHRp b25zIHdpbGwgbm90IGJyYWtlIHRoZXNlIHNwZWNpZmljYXRpb25zIQ0KDQpQbGVhc2UgY29tbWVu dCBvbiB0aGUgYWJvdmUhDQoNCg0KQmVzdCByZWdhcmRzLA0KR2Vvcmdpb3MNCg0K From bob.briscoe@bt.com Fri Mar 23 12:29:42 2012 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 D357B21E8025 for ; Fri, 23 Mar 2012 12:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.673 X-Spam-Level: X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOACGMcNdmEU for ; Fri, 23 Mar 2012 12:29:38 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECDE21E8024 for ; Fri, 23 Mar 2012 12:29:38 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 23 Mar 2012 19:29:32 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Mar 2012 19:29:36 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.247.3; Fri, 23 Mar 2012 19:29:35 +0000 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 1332530977736; Fri, 23 Mar 2012 19:29:37 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2NJTXN1000554; Fri, 23 Mar 2012 19:29:33 GMT Message-ID: <201203231929.q2NJTXN1000554@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Mar 2012 19:29:31 +0000 To: Michael Menth From: Bob Briscoe In-Reply-To: <4F6C414B.8050705@informatik.uni-tuebingen.de> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> <4F6C414B.8050705@informatik.uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org, "Scott O. Bradner" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 19:29:42 -0000 Michael, Phil Eardley has suggested this complete re-write, which solves the problem you point out, and I think makes the whole thing clearer: ============================================================================ Section 4.2 says: o Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) It should say: o Police - drop or re-mark to a lower-priority behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Notes: In the existing text the first sentence contradicts the parenthesis. It could be interpreted to mean that dropping is the only allowed policing action, whereas the parenthesis shows that downgrading was also considered appropriate. Also the existing text used the term 'blocking' as a different action to 'downgrading', whereas Section 3.6 just above this text has said '"Blocking" means it is dropped or downgraded to a lower-priority behaviour aggregate,...' ============================================================================ ==Background== In RFC5559 the term 'block' has been used to mean three different actions in two different contexts: 1) Blocking packets: " block ECN-capable traffic that uses the same DSCP as PCN from entering the PCN-domain directly. "Blocking" means it is dropped or downgraded to a lower-priority behaviour aggregate, or alternatively such traffic may be tunnelled through the PCN-domain" 2a) Blocking rejected flows: " (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.)" 2b) Blocking flows " ...whether to admit or block a new flow..." So for packets (1), 'block' is defined to mean any of drop, downgrade or tunnel, but for rejected flows in this one case (2a) 'block' is being used to only mean drop, but throughout the rest of the doc (2b) 'block' is used as just the opposite of admit, as a general term that I assume may be associated with various actions. Bob At 09:24 23/03/2012, Michael Menth wrote: >Hi Bob, > >Am 23.03.2012 00:53, schrieb Bob Briscoe: >>Scott, >> >>If an erratum is rejected, we'll have to update the architecture via 3-in-1. >> >>Therefore, we'll have to post the erratum quickly, so that we know >>whether it has been rejected or not before 3-in-1 gets thru the RFC-Editor. >> >>Here's the erratum I will post unless anyone can suggest a better way: >> >>==================================================================== >>RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009 >>Source of RFC: pcn (tsv) >> >>Type: Technical >> >>Reported By: Bob Briscoe >>Date Reported: 2012-03-XX >> >>Section 4.2 says: >> >> o Police - police, by dropping any packets received with a DSCP >> indicating PCN transport that do not belong to an admitted flow. >> (A prospective PCN-flow that is rejected could be blocked or >> admitted into a lower-priority behaviour aggregate.) >> >> >>It should say: >> >> o Police - police, by dropping or re-marking the DSCP of any packets >> received with a DSCP indicating PCN transport that do not belong >> to an admitted flow. (A prospective PCN-flow that is rejected could >> be blocked or admitted into a lower-priority behaviour aggregate.) >> >> >>Notes: >> >>The change makes the first sentence consistent with the >>parenthesis, otherwise the two contradict. The first sentence as it >>stands could be interpreted to mean that dropping is the only >>allowed policing action, whereas the parenthesis shows that >>downgrading was also considered appropriate. > >What does block in the parentheses mean? The same as reject? Or does >blocking imply dropping instead of remarking the DSCP? I find the >text clearer without the parentheses. Re-marking the DSCP must imply >downgrading (could be added) which does not exclude admission into a >lower-priority behavior aggregate. > >Regards, > > Michael > > >>==================================================================== >> >> >>Bob >> >>At 20:35 22/03/2012, Bradner, Scott wrote: >> >>>On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote: >>> >>> > Ruediger, >>> > >>> > [Scott, a question for you at the end] >>> > >>> > >>> > >>> > I prefer your erratum suggestion because it flags the problem >>> in the doc that now needs clarifying, so it's more likely to be >>> noticed by people reading the deprecated text. But we'll have to >>> see whether this would be accepted as an erratum. The relevant rule is #7 here: >>> > >>> > >>> > "Changes that modify the working of a protocol to something >>> that might be different from the intended consensus when the >>> document was approved should be either Hold for Document Update >>> or Rejected. Deciding between these two depends on judgment. >>> Changes that are clearly modifications to the intended consensus, >>> or involve large textual changes, should be Rejected. In unclear >>> situations, small changes can be Hold for Document Update. " >>> > >>> > If we wrote an erratum to RFC5559, it would be legitimate, >>> because the para you have quoted has two contradictory statements >>> in it anyway. I doubt an erratum can refer to an RFC published >>> later (3-in-1), because errata are meant to correct what the >>> document should have said at the time. I think we could compose >>> an erratum that resolved the contradiction in that paragraph >>> while at the same time making it "not inconsistent" with what we >>> now want to say in 3-in-1. >>> > >>> > Scott, can you advise? >>> >>>that sounds logical >>> >>>Scott >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www.ietf.org/mailman/listinfo/pcn > >-- >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://kn.inf.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Fri Mar 23 13:06:19 2012 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 4F65821E805E for ; Fri, 23 Mar 2012 13:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGw4rzT4UjJz for ; Fri, 23 Mar 2012 13:06:17 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 67F1521E804E for ; Fri, 23 Mar 2012 13:06:16 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 23 Mar 2012 20:06:10 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Mar 2012 20:06:14 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.247.3; Fri, 23 Mar 2012 20:06:09 +0000 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 1332533174360; Fri, 23 Mar 2012 20:06:14 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2NK67VD000671; Fri, 23 Mar 2012 20:06:07 GMT Message-ID: <201203232006.q2NK67VD000671@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Mar 2012 20:06:04 +0000 To: Tom Taylor From: Bob Briscoe In-Reply-To: <4F6C5FD7.1000804@gmail.com> References: <4F6A2736.8040403@gmail.com> <4F6A44C3.20506@informatik.uni-tuebingen.de> <4F6A4C7B.8050607@gmail.com> <4F6A69B8.6010601@informatik.uni-tuebingen.de> <201203222258.q2MMwQfX029549@bagheera.jungle.bt.co.uk> <4F6C5FD7.1000804@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn Subject: Re: [PCN] Explanation of changes in the PCN edge behaviour drafts 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: Fri, 23 Mar 2012 20:06:19 -0000 Tom, * The rephrasing of the experiments and MIBs text is editorial trivia - up to you whether to listen - but the sort of thing that is often handled during AUTH48. * Replacing references to obsoleted RFC5696 will have to be dealt with during RFC-Editor stage anyway, but as the changes are quite extensive, it will be worth having the WG check them. * The ingress behaviour issue can largely be solved by keeping the text about flow-policing in these docs but referring out for packet-policing: to the new ingress behaviour text in 3-in-1. (On this point I did email you on 3-Mar, and re-sent two reminders since. But I admit the other points are new.) * The issue that is most serious is allowing for MPLS as well as IP. I've realised it potentially affects 3-in-1 too, but less so (because 3-in-1 defines itself as the encoding for IP). Sorry about this, such an important point, but it only just struck me. I suggest we take AD direction on just the last point (if you are willing to take the other stuff in your stride). Bob (Ditto, now that the IESG has no more discusses with 3-in-1, I'm getting more WG comments than ever. But at least they are quite benign.) At 11:34 23/03/2012, Tom Taylor wrote: >I'm left wondering what to do with all these remarks, given that we >have passed not only WGLC but also IESG approval. I will await AD >direction. The most I can do at this point is surmise that I have >erred as editor and some of my changes should be backed out. > >On 22/03/2012 6:57 PM, Bob Briscoe wrote: >>Tom, >> >>inline tagged [BB]... >> >>At 23:52 21/03/2012, Michael Menth wrote: >>>Hi Tom, >>>Am 21.03.2012 22:47, schrieb Tom Taylor: >>>>My comments in turn below, marked with [PTT]. >>>>On 21/03/2012 5:14 PM, Michael Menth wrote: >>>>>Hi Tom, >>>>> >>>>>>NEW >>>>>> >>>>>>Packets at the ingress to the domain are classified as either PCN or >>>>>>non-PCN. Non-PCN packets can share the network with PCN packets >>>>>>within the domain. The encoding specified in [RFC5696] and used in >>>>>>this document requires the use of the ECN fields. PCN-ingress-nodes >>>>>>need to prevent ECN-capable traffic that uses the same DSCP as PCN >>>>>>from entering the PCN-domain directly. This is not an issue when >>>>>>tunneling of PCN-packets between the PCN-ingress-node and the PCN- >>>>>>egress-node is done, as recommended in Section 5.1.2, provided that >>>>>>the original ECN markings of arriving packets are preserved in the >>>>>>encapsulated headers. >> >>[BB] Section 5.1.2 doesn't actually recommend tunnelling, at least not >>in normative language. All it says is: >>" As a result, the only way to construct >>such filters reliably is to tunnel the packets from the PCN-ingress- >>node to the PCN-egress-node. >>" >>In fact we shouldn't only receommend tunnelling, because that's not >>actually true. One could implement CL-PCN by layering rather than >>tunneling. This would work if PCN edge-nodes were the only IP-aware >>nodes in the PCN domain, and PCN metering & marking was done at the >>lower layer (e.g. MPLS) on interior nodes. >> >>This would affect the assumed core network behaviour too. At the start >>of S.2. I suggest a sentence such as: >> >>OLD: >>" This section describes the assumed behaviour for PCN-interior-nodes >>in the PCN-domain. >>" >>SUGGESTED: >>" This section describes the assumed behaviour for IP-aware >>PCN-interior-nodes >>in the PCN-domain. >>" >> >>And add at end of Section 2: >>"An alternative would be to use PCN in MPLS on interior nodes. In this >>case all references to the PCN encoding for IP [3-in-1] would be >>replaced by references to the PCN encoding for MPLS described in >>Appendix A of [RFC5129] (Appendix C of [3-in-1] also gives useful >>examples of the PCN encoding in MPLS). In the rest of this document >>IP-aware interior nodes are assumed. " >> >>In addition, we should state in the introduction (and possibly the >>abstract) that this doc assumes IP-aware PCN nodes, but MPLS interior >>nodes are briefly discussed as an alternative. >> >>It may help to call these edge-behaviours CL-IP and SM-IP, not just CL & >>SM. Then later someone could produce near-identical copies of these RFCs >>called CL-MPLS and SM-MPLS (the latter makes more sense than the former >>because of codepoint restrictions). These wouldn't use tunnelling, and >>would refer to a different encoding, but would otherwise be fairly >>identical. >> >>[Another alternative is to use Layer 3 Ethernet switches as interior >>nodes. L3 switches do forwarding on Ethernet addresses, but they can >>bury into the IP header in the payload for the Diffserv & ECN fields >>(Microsoft has deployed ECN-marking on Layer-3 switches within its data >>centres). However, there's no need to mention an Ethernet option in the >>docs - it's a can-of-worms for standards because some see it as a >>layering violation. This little aside was for the list, not the doc.] >> >> >>>>>Moving the old text to 3-in-1 means that this doc is now aware of >>>>>3-in-1. Therefore, we should base this edge behavior no longer on >>>>>baseline encoding (RFC5696) but on 3-in-1. >>>>[PTT] I don't think we have to, although it might be reasonable. The >>>>argument is that there is no need for the old text because we are >>>>using tunneling. >>>I'd suggest to substitute RFC5696 by 3-in-1 in general to avoid >>>confusion by a soon obsoleted RFC. >> >>[BB] I agree. I believe the edge-behaviours and 3-in-1 are all going >>through together so it would be wrong to refer to a doc that 3-in-1 >>obsoletes. The RFC-Editor will substitute the appropriate RFCxxxx for >>3-in-1, which will be a normative reference. >> >>I'm afraid you will also need to substitute the new names for the two >>marked codepoints (PM->ETM & EXP->ThM), but SM will only need one (ETM). >> >> >> >>>>>>11. In the next paragraph, originally said that PCN packets of >>>>>>non-admitted flows are dropped. Replaced this with "blocked" and a >>>>>>backward reference to the definition of blocking in Section 1. >>>>>>(Follow-through on comments by Brian Carpenter, fixed elsewhere. >>>>>I think to remember that 3-in-1 recommended recoloring as preferred >>>>>policing option. >>>> >>>>[PTT] We agreed on local policy as the answer when discussing Brian >>>>Carpenter's review comments. >> >>[BB] There's a distinction needed between: >>i) treatment of packets of a flow that has asked to be admitted but been >>blocked and >>ii) packets where there has never been a request for their flow to be >>admitted, but they happen to be using a PCN-compatible DSCP and an >>ECN-capable codepoint. >> >>For case (i) it would be perfectly reasonable to drop, but re-marking >>the DSCP would also be a reasonable policy. >>For case (ii) drop would be unreasonable, because these packets just >>happen to be using a PCN codepoint outside the PCN domain, but they're >>not PCN-traffic. PCN nodes have no business interfering with non-PCN >>traffic. However they've got to do something to prevent confusion. So >>the safest action is to re-mark the DSCP. >> >>If the behaviour for (i) & (ii) are different this could be awkward, >>because it means the PCN-ingress has to remember all the flows it has >>blocked in order to treat them differently from packets that never asked >>to be admitted. How long does it remember blocked flows for? >> >>So a sensible policy would be to treat both (i) & (ii) the same to save >>having to remember blocked flows. But from a standards viewpoint, we >>should still make the distinction, because the treatment of each should >>be a policy choice, not something we should prejudge. >> >>The edge-behaviour docs are the right place to deal with case (i), but >>for the latter case both edge-behaviour docs need to refer to the new >>Section 5.1 of [3-in-1]. The logic here is that edge-behaviours deal >>with flow-related stuff, while 3-in-1 deals with individual packets. >>[3-in-1] refers to the edge-behaviours for handling packets of signalled >>flows. >> >>The split between specs here is unfortunate, but necessary. >> >> >>>>>>13. Section 5.1.3, basically editorial rearrangement of text to take >>>>>>account of the fact that the ingress node will always perform >>>>>>encapsulation. >> >>[BB] Again, there may need to be some reference to layering as an >>alternative to tunnelling. >> >>>>>>Talking about extensions to the DiffServ MIB. >>>>>> >>>>>>OLD >>>>>> >>>>>>... The required >>>>>>extensions specifically include objects for re-marking the ECN field >>>>>>at the PCN-ingress-node and an extension to the classifiers to >>>>>>include the ECN field at PCN-interior and PCN-egress-nodes. In >>>>>>addition, the MIB has to be extended to include a potential >>>>>>encapsulation action following re-classification by ingress-egress- >>>>>>aggregate. Finally, a new metering algorithm may need to be defined >>>>>>at the PCN-interior-nodes to handle excess-traffic-marking. >>>>>> >>>>>>NEW >>>>>> >>>>>>... The required >>>>>>extensions specifically include an encapsulation action following re- >>>>>>classification by ingress-egress-aggregate. In addition, the MIB >>>>>which MIB? >>>> >>>>[PTT] DiffServ MIB [RFC3289], referenced in the document. >>>ok, now I see the reference was some sentences before >>> >>>>> >>>>>>has >>>>>>to be extended to include objects for marking the ECN field in the >>>>>>outer header at the PCN-ingress-node and an extension to the >>>>>>classifiers to include the ECN field at PCN-interior and PCN-egress- >>>>>>nodes. Finally, new metering algorithms may need to be defined at >>>>>>the PCN-interior-nodes to handle threshold-marking and packet-size- >>>>>>independent excess-traffic-marking. >>>>>I do not understand why the defined marking algorithms are not >>>>>sufficient. Also packet-size-independent excess-traffic-marking is >>>>>defined (see 2.4 in RFC5670). >>>>The above passage is talking about whether the DiffServ MIB supports >>>>the defined marking algorithms, not saying that new algorithms are >>>>needed. >>>ok, understand >> >>[BB] The text is still misleading. We on the list only understand >>because you've explained on the list. Perhaps: >> >>s/Finally, new metering algorithms may need to be defined/ >>/Finally, new MIB entries for the metering algorithms may need to be >>defined/ >> >>Cheers >> >> >> >>Bob >> >> >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From menth@informatik.uni-tuebingen.de Fri Mar 23 13:36:23 2012 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 0D61A21F8652 for ; Fri, 23 Mar 2012 13:36: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cB2qQQ88qvpX for ; Fri, 23 Mar 2012 13:36:22 -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 A2A9121F864E for ; Fri, 23 Mar 2012 13:36:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 443E5524F; Fri, 23 Mar 2012 21:36:14 +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 EgwpspeY21QX; Fri, 23 Mar 2012 21:36:09 +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 014405226; Fri, 23 Mar 2012 21:36:08 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-078-043-207-168.hsi4.kabel-badenwuerttemberg.de [78.43.207.168]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 973CA40A28CA; Fri, 23 Mar 2012 21:36:07 +0100 (CET) Message-ID: <4F6CDEB7.8060302@informatik.uni-tuebingen.de> Date: Fri, 23 Mar 2012 21:36:07 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Bob Briscoe References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> <4F6C414B.8050705@informatik.uni-tuebingen.de> <201203231929.q2NJTXN1000554@bagheera.jungle.bt.co.uk> In-Reply-To: <201203231929.q2NJTXN1000554@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org, "Scott O. Bradner" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:36:23 -0000 That's fine with me. Michael Am 23.03.2012 20:29, schrieb Bob Briscoe: > Michael, > > Phil Eardley has suggested this complete re-write, which solves the > problem you point out, and I think makes the whole thing clearer: > ============================================================================ > > Section 4.2 says: > > o Police - police, by dropping any packets received with a DSCP > indicating PCN transport that do not belong to an admitted flow. > (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.) > > It should say: > > o Police - drop or re-mark to a lower-priority behaviour aggregate > i) packets received with a DSCP indicating PCN transport that do > not > belong to an admitted flow and ii) packets that are part of a flow > that asked to be admitted as a PCN-flow but was rejected. > > Notes: > > In the existing text the first sentence contradicts the parenthesis. > It could be interpreted to mean that dropping is the only allowed > policing action, whereas the parenthesis shows that downgrading was > also considered appropriate. > > Also the existing text used the term 'blocking' as a different action > to 'downgrading', whereas Section 3.6 just above this text has said > '"Blocking" means it is dropped or downgraded to a lower-priority > behaviour aggregate,...' > ============================================================================ > > > ==Background== > In RFC5559 the term 'block' has been used to mean three different > actions in two different contexts: > > 1) Blocking packets: > " block ECN-capable traffic that uses the same DSCP as PCN from > entering the PCN-domain directly. "Blocking" means it is dropped or > downgraded to a lower-priority behaviour aggregate, or alternatively > such traffic may be tunnelled through the PCN-domain" > > 2a) Blocking rejected flows: > " (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.)" > 2b) Blocking flows > " ...whether to admit or block a new flow..." > > So for packets (1), 'block' is defined to mean any of drop, downgrade > or tunnel, but for rejected flows in this one case (2a) 'block' is > being used to only mean drop, but throughout the rest of the doc (2b) > 'block' is used as just the opposite of admit, as a general term that > I assume may be associated with various actions. > > > Bob > > > At 09:24 23/03/2012, Michael Menth wrote: >> Hi Bob, >> >> Am 23.03.2012 00:53, schrieb Bob Briscoe: >>> Scott, >>> >>> If an erratum is rejected, we'll have to update the architecture via >>> 3-in-1. >>> >>> Therefore, we'll have to post the erratum quickly, so that we know >>> whether it has been rejected or not before 3-in-1 gets thru the >>> RFC-Editor. >>> >>> Here's the erratum I will post unless anyone can suggest a better way: >>> >>> ==================================================================== >>> RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009 >>> Source of RFC: pcn (tsv) >>> >>> Type: Technical >>> >>> Reported By: Bob Briscoe >>> Date Reported: 2012-03-XX >>> >>> Section 4.2 says: >>> >>> o Police - police, by dropping any packets received with a DSCP >>> indicating PCN transport that do not belong to an admitted flow. >>> (A prospective PCN-flow that is rejected could be blocked or >>> admitted into a lower-priority behaviour aggregate.) >>> >>> >>> It should say: >>> >>> o Police - police, by dropping or re-marking the DSCP of any >>> packets >>> received with a DSCP indicating PCN transport that do not belong >>> to an admitted flow. (A prospective PCN-flow that is rejected >>> could >>> be blocked or admitted into a lower-priority behaviour >>> aggregate.) >>> >>> >>> Notes: >>> >>> The change makes the first sentence consistent with the parenthesis, >>> otherwise the two contradict. The first sentence as it stands could >>> be interpreted to mean that dropping is the only allowed policing >>> action, whereas the parenthesis shows that downgrading was also >>> considered appropriate. >> >> What does block in the parentheses mean? The same as reject? Or does >> blocking imply dropping instead of remarking the DSCP? I find the >> text clearer without the parentheses. Re-marking the DSCP must imply >> downgrading (could be added) which does not exclude admission into a >> lower-priority behavior aggregate. >> >> Regards, >> >> Michael >> >> >>> ==================================================================== >>> >>> >>> Bob >>> >>> At 20:35 22/03/2012, Bradner, Scott wrote: >>> >>>> On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote: >>>> >>>> > Ruediger, >>>> > >>>> > [Scott, a question for you at the end] >>>> > >>>> > >>>> > >>>> > I prefer your erratum suggestion because it flags the problem in >>>> the doc that now needs clarifying, so it's more likely to be >>>> noticed by people reading the deprecated text. But we'll have to >>>> see whether this would be accepted as an erratum. The relevant rule >>>> is #7 here: >>>> > >>>> > >>>> > "Changes that modify the working of a protocol to something that >>>> might be different from the intended consensus when the document >>>> was approved should be either Hold for Document Update or Rejected. >>>> Deciding between these two depends on judgment. Changes that are >>>> clearly modifications to the intended consensus, or involve large >>>> textual changes, should be Rejected. In unclear situations, small >>>> changes can be Hold for Document Update. " >>>> > >>>> > If we wrote an erratum to RFC5559, it would be legitimate, >>>> because the para you have quoted has two contradictory statements >>>> in it anyway. I doubt an erratum can refer to an RFC published >>>> later (3-in-1), because errata are meant to correct what the >>>> document should have said at the time. I think we could compose an >>>> erratum that resolved the contradiction in that paragraph while at >>>> the same time making it "not inconsistent" with what we now want to >>>> say in 3-in-1. >>>> > >>>> > Scott, can you advise? >>>> >>>> that sounds logical >>>> >>>> Scott >>> >>> ________________________________________________________________ >>> Bob Briscoe, BT Innovate & Design >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >> >> -- >> 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://kn.inf.uni-tuebingen.de > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- 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://kn.inf.uni-tuebingen.de From wwwrun@rfc-editor.org Fri Mar 23 13:54:36 2012 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 6812221E8085 for ; Fri, 23 Mar 2012 13:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6kp5A8yevFf for ; Fri, 23 Mar 2012 13:54:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D93A621E804E for ; Fri, 23 Mar 2012 13:54:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 981B9B1E002; Fri, 23 Mar 2012 13:53:27 -0700 (PDT) To: philip.eardley@bt.com, wes@mti-systems.com, ietfdbh@comcast.net, sob@harvard.edu, slblake@petri-meat.com From: RFC Errata System Message-Id: <20120323205327.981B9B1E002@rfc-editor.org> Date: Fri, 23 Mar 2012 13:53:27 -0700 (PDT) Cc: pcn@ietf.org, rfc-editor@rfc-editor.org Subject: [PCN] [Technical Errata Reported] RFC5559 (3164) 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: Fri, 23 Mar 2012 20:54:36 -0000 The following errata report has been submitted for RFC5559, "Pre-Congestion Notification (PCN) Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5559&eid=3164 -------------------------------------- Type: Technical Reported by: Bob Briscoe Section: 4.2 Original Text ------------- o Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Corrected Text -------------- o Police - drop or re-mark to a lower-priority behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Notes ----- In the original text the first sentence contradicts the parenthesis. It could be interpreted to mean that dropping is the only allowed policing action, whereas the parenthesis shows that downgrading was also considered appropriate. Also the original text used the term 'blocking' as a different action to 'downgrading', whereas Section 3.6 just above this text has said '"Blocking" means it is dropped or downgraded to a lower-priority behaviour aggregate,...' Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5559 (draft-ietf-pcn-architecture-11) -------------------------------------- Title : Pre-Congestion Notification (PCN) Architecture Publication Date : June 2009 Author(s) : P. Eardley, Ed. Category : INFORMATIONAL Source : Congestion and Pre-Congestion Notification Area : Transport Stream : IETF Verifying Party : IESG From bob.briscoe@bt.com Fri Mar 23 13:56:14 2012 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 6FA2021E8088 for ; Fri, 23 Mar 2012 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv5n-OtA0csW for ; Fri, 23 Mar 2012 13:56:13 -0700 (PDT) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id E6CD521E804E for ; Fri, 23 Mar 2012 13:56:12 -0700 (PDT) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Mar 2012 20:55:53 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Mar 2012 20:55:52 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Fri, 23 Mar 2012 20:55:50 +0000 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 1332536149288; Fri, 23 Mar 2012 20:55:49 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2NKtlSB000811; Fri, 23 Mar 2012 20:55:47 GMT Message-ID: <201203232055.q2NKtlSB000811@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Mar 2012 20:55:46 +0000 To: Michael Menth From: Bob Briscoe In-Reply-To: <4F6CDEB7.8060302@informatik.uni-tuebingen.de> References: <201203201634.q2KGYPJY020918@bagheera.jungle.bt.co.uk> <4491D33D-6A78-4341-A334-DFE6C4870C65@harvard.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A46A70C7@HE111648.emea1.cds.t-internal.com> <201203222020.q2MKKJiF029179@bagheera.jungle.bt.co.uk> <801B613F-1C5F-459E-9C15-7FAE116C1B3E@harvard.edu> <201203222353.q2MNrref029724@bagheera.jungle.bt.co.uk> <4F6C414B.8050705@informatik.uni-tuebingen.de> <201203231929.q2NJTXN1000554@bagheera.jungle.bt.co.uk> <4F6CDEB7.8060302@informatik.uni-tuebingen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org, "Scott O. Bradner" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 20:56:14 -0000 Michael & all, I've submitted this erratum report. It is likely to be referred to the PCN ML anyway. Bob At 20:36 23/03/2012, Michael Menth wrote: >That's fine with me. > >Michael > >Am 23.03.2012 20:29, schrieb Bob Briscoe: >>Michael, >> >>Phil Eardley has suggested this complete re-write, which solves the >>problem you point out, and I think makes the whole thing clearer: >>============================================================================ >>Section 4.2 says: >> >> o Police - police, by dropping any packets received with a DSCP >> indicating PCN transport that do not belong to an admitted flow. >> (A prospective PCN-flow that is rejected could be blocked or >> admitted into a lower-priority behaviour aggregate.) >> >>It should say: >> >> o Police - drop or re-mark to a lower-priority behaviour aggregate >> i) packets received with a DSCP indicating PCN transport that do not >> belong to an admitted flow and ii) packets that are part of a flow >> that asked to be admitted as a PCN-flow but was rejected. >> >>Notes: >> >>In the existing text the first sentence contradicts the >>parenthesis. It could be interpreted to mean that dropping is the >>only allowed policing action, whereas the parenthesis shows that >>downgrading was also considered appropriate. >> >>Also the existing text used the term 'blocking' as a different >>action to 'downgrading', whereas Section 3.6 just above this text >>has said '"Blocking" means it is dropped or downgraded to a >>lower-priority behaviour aggregate,...' >>============================================================================ >> >>==Background== >>In RFC5559 the term 'block' has been used to mean three different >>actions in two different contexts: >> >>1) Blocking packets: >>" block ECN-capable traffic that uses the same DSCP as PCN from >> entering the PCN-domain directly. "Blocking" means it is dropped or >> downgraded to a lower-priority behaviour aggregate, or alternatively >> such traffic may be tunnelled through the PCN-domain" >> >>2a) Blocking rejected flows: >>" (A prospective PCN-flow that is rejected could be blocked or >> admitted into a lower-priority behaviour aggregate.)" >>2b) Blocking flows >>" ...whether to admit or block a new flow..." >> >>So for packets (1), 'block' is defined to mean any of drop, >>downgrade or tunnel, but for rejected flows in this one case (2a) >>'block' is being used to only mean drop, but throughout the rest of >>the doc (2b) 'block' is used as just the opposite of admit, as a >>general term that I assume may be associated with various actions. >> >> >>Bob >> >> >>At 09:24 23/03/2012, Michael Menth wrote: >>>Hi Bob, >>> >>>Am 23.03.2012 00:53, schrieb Bob Briscoe: >>>>Scott, >>>> >>>>If an erratum is rejected, we'll have to update the architecture >>>>via 3-in-1. >>>> >>>>Therefore, we'll have to post the erratum quickly, so that we >>>>know whether it has been rejected or not before 3-in-1 gets thru >>>>the RFC-Editor. >>>> >>>>Here's the erratum I will post unless anyone can suggest a better way: >>>> >>>>==================================================================== >>>>RFC5559, "Pre-Congestion Notification (PCN) Architecture", June 2009 >>>>Source of RFC: pcn (tsv) >>>> >>>>Type: Technical >>>> >>>>Reported By: Bob Briscoe >>>>Date Reported: 2012-03-XX >>>> >>>>Section 4.2 says: >>>> >>>> o Police - police, by dropping any packets received with a DSCP >>>> indicating PCN transport that do not belong to an admitted flow. >>>> (A prospective PCN-flow that is rejected could be blocked or >>>> admitted into a lower-priority behaviour aggregate.) >>>> >>>> >>>>It should say: >>>> >>>> o Police - police, by dropping or re-marking the DSCP of any packets >>>> received with a DSCP indicating PCN transport that do not belong >>>> to an admitted flow. (A prospective PCN-flow that is rejected could >>>> be blocked or admitted into a lower-priority behaviour aggregate.) >>>> >>>> >>>>Notes: >>>> >>>>The change makes the first sentence consistent with the >>>>parenthesis, otherwise the two contradict. The first sentence as >>>>it stands could be interpreted to mean that dropping is the only >>>>allowed policing action, whereas the parenthesis shows that >>>>downgrading was also considered appropriate. >>> >>>What does block in the parentheses mean? The same as reject? Or >>>does blocking imply dropping instead of remarking the DSCP? I find >>>the text clearer without the parentheses. Re-marking the DSCP must >>>imply downgrading (could be added) which does not exclude >>>admission into a lower-priority behavior aggregate. >>> >>>Regards, >>> >>> Michael >>> >>> >>>>==================================================================== >>>> >>>> >>>>Bob >>>> >>>>At 20:35 22/03/2012, Bradner, Scott wrote: >>>> >>>>>On Mar 22, 2012, at 4:20 PM, Bob Briscoe wrote: >>>>> >>>>> > Ruediger, >>>>> > >>>>> > [Scott, a question for you at the end] >>>>> > >>>>> > >>>>> > >>>>> > I prefer your erratum suggestion because it flags the problem >>>>> in the doc that now needs clarifying, so it's more likely to be >>>>> noticed by people reading the deprecated text. But we'll have >>>>> to see whether this would be accepted as an erratum. The >>>>> relevant rule is #7 here: >>>>> > >>>>> > >>>>> > "Changes that modify the working of a protocol to something >>>>> that might be different from the intended consensus when the >>>>> document was approved should be either Hold for Document Update >>>>> or Rejected. Deciding between these two depends on judgment. >>>>> Changes that are clearly modifications to the intended >>>>> consensus, or involve large textual changes, should be >>>>> Rejected. In unclear situations, small changes can be Hold for >>>>> Document Update. " >>>>> > >>>>> > If we wrote an erratum to RFC5559, it would be legitimate, >>>>> because the para you have quoted has two contradictory >>>>> statements in it anyway. I doubt an erratum can refer to an RFC >>>>> published later (3-in-1), because errata are meant to correct >>>>> what the document should have said at the time. I think we >>>>> could compose an erratum that resolved the contradiction in >>>>> that paragraph while at the same time making it "not >>>>> inconsistent" with what we now want to say in 3-in-1. >>>>> > >>>>> > Scott, can you advise? >>>>> >>>>>that sounds logical >>>>> >>>>>Scott >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, BT Innovate & Design >>>>_______________________________________________ >>>>PCN mailing list >>>>PCN@ietf.org >>>>https://www.ietf.org/mailman/listinfo/pcn >>> >>>-- >>>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://kn.inf.uni-tuebingen.de >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >-- >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://kn.inf.uni-tuebingen.de ________________________________________________________________ Bob Briscoe, BT Innovate & Design From karagian@cs.utwente.nl Fri Mar 23 14:44:53 2012 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 2275C21F8673 for ; Fri, 23 Mar 2012 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlIjmqzxMae3 for ; Fri, 23 Mar 2012 14:44:51 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id DADF121F8670 for ; Fri, 23 Mar 2012 14:44:50 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 23 Mar 2012 22:44:53 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 23 Mar 2012 22:44:45 +0100 From: To: , Thread-Topic: [PCN] Explanation of changes in the PCN edge behaviour drafts Thread-Index: AQHNCTBy2u6oElcMeEuLAQY5k35KpJZ4aG96 Date: Fri, 23 Mar 2012 21:44:44 +0000 Message-ID: References: <4F6A2736.8040403@gmail.com> <4F6A44C3.20506@informatik.uni-tuebingen.de> <4F6A4C7B.8050607@gmail.com> <4F6A69B8.6010601@informatik.uni-tuebingen.de> <201203222258.q2MMwQfX029549@bagheera.jungle.bt.co.uk> <4F6C5FD7.1000804@gmail.com>, <201203232006.q2NK67VD000671@bagheera.jungle.bt.co.uk> In-Reply-To: <201203232006.q2NK67VD000671@bagheera.jungle.bt.co.uk> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Explanation of changes in the PCN edge behaviour drafts 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: Fri, 23 Mar 2012 21:44:53 -0000 Hi Bob, Regarding the rephrased text: Police - drop or re-mark to a lower-priority behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Why should we emphasize the it should be remarked to a lower-priority behav= iour aggregate? Is it acceptable to rephrase the text in the following way (another instead= of low-priority): Police - drop or re-mark to another behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Bob Briscoe [bob.br= iscoe@bt.com] Verzonden: vrijdag 23 maart 2012 21:06 Aan: Tom Taylor CC: pcn Onderwerp: Re: [PCN] Explanation of changes in the PCN edge behaviour draf= ts Tom, * The rephrasing of the experiments and MIBs text is editorial trivia - up to you whether to listen - but the sort of thing that is often handled during AUTH48. * Replacing references to obsoleted RFC5696 will have to be dealt with during RFC-Editor stage anyway, but as the changes are quite extensive, it will be worth having the WG check them. * The ingress behaviour issue can largely be solved by keeping the text about flow-policing in these docs but referring out for packet-policing: to the new ingress behaviour text in 3-in-1. (On this point I did email you on 3-Mar, and re-sent two reminders since. But I admit the other points are new.) * The issue that is most serious is allowing for MPLS as well as IP. I've realised it potentially affects 3-in-1 too, but less so (because 3-in-1 defines itself as the encoding for IP). Sorry about this, such an important point, but it only just struck me. I suggest we take AD direction on just the last point (if you are willing to take the other stuff in your stride). Bob (Ditto, now that the IESG has no more discusses with 3-in-1, I'm getting more WG comments than ever. But at least they are quite benign.) At 11:34 23/03/2012, Tom Taylor wrote: >I'm left wondering what to do with all these remarks, given that we >have passed not only WGLC but also IESG approval. I will await AD >direction. The most I can do at this point is surmise that I have >erred as editor and some of my changes should be backed out. > >On 22/03/2012 6:57 PM, Bob Briscoe wrote: >>Tom, >> >>inline tagged [BB]... >> >>At 23:52 21/03/2012, Michael Menth wrote: >>>Hi Tom, >>>Am 21.03.2012 22:47, schrieb Tom Taylor: >>>>My comments in turn below, marked with [PTT]. >>>>On 21/03/2012 5:14 PM, Michael Menth wrote: >>>>>Hi Tom, >>>>> >>>>>>NEW >>>>>> >>>>>>Packets at the ingress to the domain are classified as either PCN or >>>>>>non-PCN. Non-PCN packets can share the network with PCN packets >>>>>>within the domain. The encoding specified in [RFC5696] and used in >>>>>>this document requires the use of the ECN fields. PCN-ingress-nodes >>>>>>need to prevent ECN-capable traffic that uses the same DSCP as PCN >>>>>>from entering the PCN-domain directly. This is not an issue when >>>>>>tunneling of PCN-packets between the PCN-ingress-node and the PCN- >>>>>>egress-node is done, as recommended in Section 5.1.2, provided that >>>>>>the original ECN markings of arriving packets are preserved in the >>>>>>encapsulated headers. >> >>[BB] Section 5.1.2 doesn't actually recommend tunnelling, at least not >>in normative language. All it says is: >>" As a result, the only way to construct >>such filters reliably is to tunnel the packets from the PCN-ingress- >>node to the PCN-egress-node. >>" >>In fact we shouldn't only receommend tunnelling, because that's not >>actually true. One could implement CL-PCN by layering rather than >>tunneling. This would work if PCN edge-nodes were the only IP-aware >>nodes in the PCN domain, and PCN metering & marking was done at the >>lower layer (e.g. MPLS) on interior nodes. >> >>This would affect the assumed core network behaviour too. At the start >>of S.2. I suggest a sentence such as: >> >>OLD: >>" This section describes the assumed behaviour for PCN-interior-nodes >>in the PCN-domain. >>" >>SUGGESTED: >>" This section describes the assumed behaviour for IP-aware >>PCN-interior-nodes >>in the PCN-domain. >>" >> >>And add at end of Section 2: >>"An alternative would be to use PCN in MPLS on interior nodes. In this >>case all references to the PCN encoding for IP [3-in-1] would be >>replaced by references to the PCN encoding for MPLS described in >>Appendix A of [RFC5129] (Appendix C of [3-in-1] also gives useful >>examples of the PCN encoding in MPLS). In the rest of this document >>IP-aware interior nodes are assumed. " >> >>In addition, we should state in the introduction (and possibly the >>abstract) that this doc assumes IP-aware PCN nodes, but MPLS interior >>nodes are briefly discussed as an alternative. >> >>It may help to call these edge-behaviours CL-IP and SM-IP, not just CL & >>SM. Then later someone could produce near-identical copies of these RFCs >>called CL-MPLS and SM-MPLS (the latter makes more sense than the former >>because of codepoint restrictions). These wouldn't use tunnelling, and >>would refer to a different encoding, but would otherwise be fairly >>identical. >> >>[Another alternative is to use Layer 3 Ethernet switches as interior >>nodes. L3 switches do forwarding on Ethernet addresses, but they can >>bury into the IP header in the payload for the Diffserv & ECN fields >>(Microsoft has deployed ECN-marking on Layer-3 switches within its data >>centres). However, there's no need to mention an Ethernet option in the >>docs - it's a can-of-worms for standards because some see it as a >>layering violation. This little aside was for the list, not the doc.] >> >> >>>>>Moving the old text to 3-in-1 means that this doc is now aware of >>>>>3-in-1. Therefore, we should base this edge behavior no longer on >>>>>baseline encoding (RFC5696) but on 3-in-1. >>>>[PTT] I don't think we have to, although it might be reasonable. The >>>>argument is that there is no need for the old text because we are >>>>using tunneling. >>>I'd suggest to substitute RFC5696 by 3-in-1 in general to avoid >>>confusion by a soon obsoleted RFC. >> >>[BB] I agree. I believe the edge-behaviours and 3-in-1 are all going >>through together so it would be wrong to refer to a doc that 3-in-1 >>obsoletes. The RFC-Editor will substitute the appropriate RFCxxxx for >>3-in-1, which will be a normative reference. >> >>I'm afraid you will also need to substitute the new names for the two >>marked codepoints (PM->ETM & EXP->ThM), but SM will only need one (ETM). >> >> >> >>>>>>11. In the next paragraph, originally said that PCN packets of >>>>>>non-admitted flows are dropped. Replaced this with "blocked" and a >>>>>>backward reference to the definition of blocking in Section 1. >>>>>>(Follow-through on comments by Brian Carpenter, fixed elsewhere. >>>>>I think to remember that 3-in-1 recommended recoloring as preferred >>>>>policing option. >>>> >>>>[PTT] We agreed on local policy as the answer when discussing Brian >>>>Carpenter's review comments. >> >>[BB] There's a distinction needed between: >>i) treatment of packets of a flow that has asked to be admitted but been >>blocked and >>ii) packets where there has never been a request for their flow to be >>admitted, but they happen to be using a PCN-compatible DSCP and an >>ECN-capable codepoint. >> >>For case (i) it would be perfectly reasonable to drop, but re-marking >>the DSCP would also be a reasonable policy. >>For case (ii) drop would be unreasonable, because these packets just >>happen to be using a PCN codepoint outside the PCN domain, but they're >>not PCN-traffic. PCN nodes have no business interfering with non-PCN >>traffic. However they've got to do something to prevent confusion. So >>the safest action is to re-mark the DSCP. >> >>If the behaviour for (i) & (ii) are different this could be awkward, >>because it means the PCN-ingress has to remember all the flows it has >>blocked in order to treat them differently from packets that never asked >>to be admitted. How long does it remember blocked flows for? >> >>So a sensible policy would be to treat both (i) & (ii) the same to save >>having to remember blocked flows. But from a standards viewpoint, we >>should still make the distinction, because the treatment of each should >>be a policy choice, not something we should prejudge. >> >>The edge-behaviour docs are the right place to deal with case (i), but >>for the latter case both edge-behaviour docs need to refer to the new >>Section 5.1 of [3-in-1]. The logic here is that edge-behaviours deal >>with flow-related stuff, while 3-in-1 deals with individual packets. >>[3-in-1] refers to the edge-behaviours for handling packets of signalled >>flows. >> >>The split between specs here is unfortunate, but necessary. >> >> >>>>>>13. Section 5.1.3, basically editorial rearrangement of text to take >>>>>>account of the fact that the ingress node will always perform >>>>>>encapsulation. >> >>[BB] Again, there may need to be some reference to layering as an >>alternative to tunnelling. >> >>>>>>Talking about extensions to the DiffServ MIB. >>>>>> >>>>>>OLD >>>>>> >>>>>>... The required >>>>>>extensions specifically include objects for re-marking the ECN field >>>>>>at the PCN-ingress-node and an extension to the classifiers to >>>>>>include the ECN field at PCN-interior and PCN-egress-nodes. In >>>>>>addition, the MIB has to be extended to include a potential >>>>>>encapsulation action following re-classification by ingress-egress- >>>>>>aggregate. Finally, a new metering algorithm may need to be defined >>>>>>at the PCN-interior-nodes to handle excess-traffic-marking. >>>>>> >>>>>>NEW >>>>>> >>>>>>... The required >>>>>>extensions specifically include an encapsulation action following re- >>>>>>classification by ingress-egress-aggregate. In addition, the MIB >>>>>which MIB? >>>> >>>>[PTT] DiffServ MIB [RFC3289], referenced in the document. >>>ok, now I see the reference was some sentences before >>> >>>>> >>>>>>has >>>>>>to be extended to include objects for marking the ECN field in the >>>>>>outer header at the PCN-ingress-node and an extension to the >>>>>>classifiers to include the ECN field at PCN-interior and PCN-egress- >>>>>>nodes. Finally, new metering algorithms may need to be defined at >>>>>>the PCN-interior-nodes to handle threshold-marking and packet-size- >>>>>>independent excess-traffic-marking. >>>>>I do not understand why the defined marking algorithms are not >>>>>sufficient. Also packet-size-independent excess-traffic-marking is >>>>>defined (see 2.4 in RFC5670). >>>>The above passage is talking about whether the DiffServ MIB supports >>>>the defined marking algorithms, not saying that new algorithms are >>>>needed. >>>ok, understand >> >>[BB] The text is still misleading. We on the list only understand >>because you've explained on the list. Perhaps: >> >>s/Finally, new metering algorithms may need to be defined/ >>/Finally, new MIB entries for the metering algorithms may need to be >>defined/ >> >>Cheers >> >> >> >>Bob >> >> >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From karagian@cs.utwente.nl Fri Mar 23 14:48:43 2012 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 AB59521F867B for ; Fri, 23 Mar 2012 14:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogEhhthmvJ2a for ; Fri, 23 Mar 2012 14:48:43 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id B07AC21F8679 for ; Fri, 23 Mar 2012 14:48:42 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 23 Mar 2012 22:48:48 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 23 Mar 2012 22:48:40 +0100 From: To: , , , , , Thread-Topic: [PCN] [Technical Errata Reported] RFC5559 (3164) Thread-Index: AQHNCTcsZo+eEsrI5kqOKHLvy6amcZZ4aeuA Date: Fri, 23 Mar 2012 21:48:39 +0000 Message-ID: References: <20120323205327.981B9B1E002@rfc-editor.org> In-Reply-To: <20120323205327.981B9B1E002@rfc-editor.org> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] [Technical Errata Reported] RFC5559 (3164) 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: Fri, 23 Mar 2012 21:48:43 -0000 Hi Bob, Regarding the rephrased text: Police - drop or re-mark to a lower-priority behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Why should we mandate that it should be remarked to a lower-priority behavi= our aggregate? Is it acceptable to rephrase the text in the following way ("another" inste= ad of "low-priority"). In my opinion the PCN-ingress-node should be able, d= epending on a local policy, to either drop the packet or remarked it to ano= ther behaviour aggregate: Police - drop or re-mark to another behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens RFC Errata System [= rfc-editor@rfc-editor.org] Verzonden: vrijdag 23 maart 2012 21:53 Aan: philip.eardley@bt.com; wes@mti-systems.com; ietfdbh@comcast.net; sob@h= arvard.edu; slblake@petri-meat.com CC: pcn@ietf.org; rfc-editor@rfc-editor.org Onderwerp: [PCN] [Technical Errata Reported] RFC5559 (3164) The following errata report has been submitted for RFC5559, "Pre-Congestion Notification (PCN) Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5559&eid=3D3164 -------------------------------------- Type: Technical Reported by: Bob Briscoe Section: 4.2 Original Text ------------- o Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Corrected Text -------------- o Police - drop or re-mark to a lower-priority behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Notes ----- In the original text the first sentence contradicts the parenthesis. It cou= ld be interpreted to mean that dropping is the only allowed policing action= , whereas the parenthesis shows that downgrading was also considered approp= riate. Also the original text used the term 'blocking' as a different action to 'd= owngrading', whereas Section 3.6 just above this text has said '"Blocking" = means it is dropped or downgraded to a lower-priority behaviour aggregate,.= ..' Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5559 (draft-ietf-pcn-architecture-11) -------------------------------------- Title : Pre-Congestion Notification (PCN) Architecture Publication Date : June 2009 Author(s) : P. Eardley, Ed. Category : INFORMATIONAL Source : Congestion and Pre-Congestion Notification Area : Transport Stream : IETF Verifying Party : IESG _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From karagian@cs.utwente.nl Fri Mar 23 15:10:07 2012 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 D9ABF21F863E for ; Fri, 23 Mar 2012 15:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHMHldWp1gRs for ; Fri, 23 Mar 2012 15:10:07 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1331321F862F for ; Fri, 23 Mar 2012 15:10:04 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 23 Mar 2012 23:10:11 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 23 Mar 2012 23:10:03 +0100 From: To: , , , , , Thread-Topic: [PCN] [Technical Errata Reported] RFC5559 (3164) Thread-Index: AQHNCTcsZo+eEsrI5kqOKHLvy6amcZZ4aeuAgAAGZps= Date: Fri, 23 Mar 2012 22:10:02 +0000 Message-ID: References: <20120323205327.981B9B1E002@rfc-editor.org>, In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] [Technical Errata Reported] RFC5559 (3164) 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: Fri, 23 Mar 2012 22:10:08 -0000 Hi Bob, The reason of emphasizing this request is that the signaling protocol that = is used to support the PCN signaling between PCN-egree-node to PCN-ingress-= node (i.e., draft-ietf-tsvwg-rsvp-pcn-01.txt ) supports the possibility of= having more than one IEAs between the same pair of PCN edge nodes.=20 In this way a requesting individual flow has a higher chance to be admitted= to an IEA that is NOT in PCN-admission-state. This is supported in the following way:=20 When IEA supported by a PCN-ingress-node is in PCN-admission state, then ba= sed on local policy, a requesting e2e RSVP session (individual flow) should= be either rejected or mapped to another IEA that is NOT in PCN-admission-s= tate. Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens karagian@cs.utwente= .nl [karagian@cs.utwente.nl] Verzonden: vrijdag 23 maart 2012 22:48 Aan: rfc-editor@rfc-editor.org; philip.eardley@bt.com; wes@mti-systems.com;= ietfdbh@comcast.net; sob@harvard.edu; slblake@petri-meat.com CC: pcn@ietf.org Onderwerp: Re: [PCN] [Technical Errata Reported] RFC5559 (3164) Hi Bob, Regarding the rephrased text: Police - drop or re-mark to a lower-priority behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Why should we mandate that it should be remarked to a lower-priority behavi= our aggregate? Is it acceptable to rephrase the text in the following way ("another" inste= ad of "low-priority"). In my opinion the PCN-ingress-node should be able, d= epending on a local policy, to either drop the packet or remarked it to ano= ther behaviour aggregate: Police - drop or re-mark to another behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens RFC Errata System [= rfc-editor@rfc-editor.org] Verzonden: vrijdag 23 maart 2012 21:53 Aan: philip.eardley@bt.com; wes@mti-systems.com; ietfdbh@comcast.net; sob@h= arvard.edu; slblake@petri-meat.com CC: pcn@ietf.org; rfc-editor@rfc-editor.org Onderwerp: [PCN] [Technical Errata Reported] RFC5559 (3164) The following errata report has been submitted for RFC5559, "Pre-Congestion Notification (PCN) Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5559&eid=3D3164 -------------------------------------- Type: Technical Reported by: Bob Briscoe Section: 4.2 Original Text ------------- o Police - police, by dropping any packets received with a DSCP indicating PCN transport that do not belong to an admitted flow. (A prospective PCN-flow that is rejected could be blocked or admitted into a lower-priority behaviour aggregate.) Corrected Text -------------- o Police - drop or re-mark to a lower-priority behaviour aggregate i) packets received with a DSCP indicating PCN transport that do not belong to an admitted flow and ii) packets that are part of a flow that asked to be admitted as a PCN-flow but was rejected. Notes ----- In the original text the first sentence contradicts the parenthesis. It cou= ld be interpreted to mean that dropping is the only allowed policing action= , whereas the parenthesis shows that downgrading was also considered approp= riate. Also the original text used the term 'blocking' as a different action to 'd= owngrading', whereas Section 3.6 just above this text has said '"Blocking" = means it is dropped or downgraded to a lower-priority behaviour aggregate,.= ..' Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5559 (draft-ietf-pcn-architecture-11) -------------------------------------- Title : Pre-Congestion Notification (PCN) Architecture Publication Date : June 2009 Author(s) : P. Eardley, Ed. Category : INFORMATIONAL Source : Congestion and Pre-Congestion Notification Area : Transport Stream : IETF Verifying Party : IESG _______________________________________________ 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 karagian@cs.utwente.nl Fri Mar 23 22:19:13 2012 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 998AB21F844C for ; Fri, 23 Mar 2012 22:19:13 -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.418, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6E1T2pa50ix for ; Fri, 23 Mar 2012 22:19:13 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9D20421F844B for ; Fri, 23 Mar 2012 22:19:11 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 24 Mar 2012 06:19:19 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Sat, 24 Mar 2012 06:19:10 +0100 From: To: Thread-Topic: hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac0JfaQgQkUC+asmSVG/w7TiQNcc9A== Date: Sat, 24 Mar 2012 05:19:09 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C25AD1EXMBX04adutwent_" MIME-Version: 1.0 Subject: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-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: Sat, 24 Mar 2012 05:19:13 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C25AD1EXMBX04adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, >From what I can recall the edge behavior drafts could proceed with their pu= blication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will b= e standardized in tsvwg. Due to some changes that are being implemented lately the validity of two m= ain assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore. However, this is not clear to me. I hope that the validity of the following two main assumptions considered i= n draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM an= d CL edge behavior specifications: Assumption 1: More than one IEAs between same pair of PCN edge nodes should= be supported, each of them using a different PHB-ID value Why?: A requesting individual flow has a higher chance to be admitted to an= IEA that is NOT in PCN-admission-state How? When IEA supported by a PCN-ingress-node is in PCN-admission state, th= en based on local policy, requesting e2e RSVP session (individual flow) sho= uld be either rejected or mapped to another IEA that is NOT in PCN-admissio= n-state Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an ind= ividual flow without terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects a number of e2e RSVP sess= ions (individual flows) to be either terminated or reserved bandwidth of e2= e RSVP sessions (individual flows) is reduced If these assumptions are not valid anymore then we might need to do changes= in the not yet published PCN drafts! Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C25AD1EXMBX04adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

From what I can recall the edge behavior drafts could proceed with their= publication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn wil= l be standardized in tsvwg.

Due to some changes that are being implemented lately the validity of two m= ain assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore. However, this is not clear to me.
I hope that the validity of the following two main assumptions considered i= n draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM an= d CL edge behavior specifications:

Assumption 1: More than one IEAs between same pair of PCN edge nodes should= be supported, each of them using a different PHB-ID value
Why?: A requesting individual flow has a higher chance to be admitted to an= IEA that is NOT in PCN-admission-state
How? When IEA supported by a PCN-ingress-node is in PCN-admission state, th= en based on local policy, requesting e2e RSVP session (individual flow) sho= uld be either rejected or mapped to another IEA that is NOT in PCN-admissio= n-state

Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an ind= ividual flow without terminating the flow
Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion
How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then:
based on a local policy and for same IEA, selects a number of e2e RSVP sess= ions (individual flows) to be either terminated or reserved bandwidth of e2= e RSVP sessions (individual flows) is reduced

If these assumptions are not valid anymore then we might need to do changes= in the not yet published PCN drafts!

Best regards,
Georgios

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F26C25AD1EXMBX04adutwent_-- From sob@harvard.edu Sat Mar 24 03:38:50 2012 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 3ECF821F8550 for ; Sat, 24 Mar 2012 03:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaJRPkyg1bJF for ; Sat, 24 Mar 2012 03:38:48 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 68D4921F84DA for ; Sat, 24 Mar 2012 03:38:48 -0700 (PDT) Received: from exchange.university.harvard.edu (unknown [10.35.2.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id F0551E90E0; Sat, 24 Mar 2012 06:38:47 -0400 (EDT) Received: from ENTWHUBT0000001.university.harvard.edu (10.32.8.202) by ENTWEDGE0000000.university.harvard.edu (10.35.2.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 24 Mar 2012 06:37:52 -0400 Received: from ENTWEXMB0000004.university.harvard.edu ([169.254.3.128]) by ENTWHUBT0000001.university.harvard.edu ([10.32.8.202]) with mapi id 14.01.0355.002; Sat, 24 Mar 2012 06:38:27 -0400 From: "Bradner, Scott" To: RFC Errata System Thread-Topic: [Technical Errata Reported] RFC5559 (3164) Thread-Index: AQHNCao+D4iki1rBOE2QGIRN0w+uMQ== Date: Sat, 24 Mar 2012 10:38:26 +0000 Message-ID: <1AA59456-4739-48BB-8F69-B495524F402B@harvard.edu> References: <20120323205327.981B9B1E002@rfc-editor.org> In-Reply-To: <20120323205327.981B9B1E002@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.248.127.162] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [PCN] [Technical Errata Reported] RFC5559 (3164) 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, 24 Mar 2012 10:38:50 -0000 this looks correct to me and I think it should be accepted Scott On Mar 23, 2012, at 4:53 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5559, > "Pre-Congestion Notification (PCN) Architecture". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5559&eid=3D3164 >=20 > -------------------------------------- > Type: Technical > Reported by: Bob Briscoe >=20 > Section: 4.2 >=20 > Original Text > ------------- > o Police - police, by dropping any packets received with a DSCP > indicating PCN transport that do not belong to an admitted flow. > (A prospective PCN-flow that is rejected could be blocked or > admitted into a lower-priority behaviour aggregate.) >=20 >=20 > Corrected Text > -------------- > o Police - drop or re-mark to a lower-priority behaviour aggregate > i) packets received with a DSCP indicating PCN transport that do not > belong to an admitted flow and ii) packets that are part of a flow > that asked to be admitted as a PCN-flow but was rejected. >=20 >=20 > Notes > ----- > In the original text the first sentence contradicts the parenthesis. It c= ould be interpreted to mean that dropping is the only allowed policing acti= on, whereas the parenthesis shows that downgrading was also considered appr= opriate. >=20 > Also the original text used the term 'blocking' as a different action to = 'downgrading', whereas Section 3.6 just above this text has said '"Blocking= " means it is dropped or downgraded to a lower-priority behaviour aggregate= ,...' >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5559 (draft-ietf-pcn-architecture-11) > -------------------------------------- > Title : Pre-Congestion Notification (PCN) Architecture > Publication Date : June 2009 > Author(s) : P. Eardley, Ed. > Category : INFORMATIONAL > Source : Congestion and Pre-Congestion Notification > Area : Transport > Stream : IETF > Verifying Party : IESG From bob.briscoe@bt.com Sat Mar 24 03:42:20 2012 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 2464421F8673 for ; Sat, 24 Mar 2012 03:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.68 X-Spam-Level: X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brPXOUBG6cEs for ; Sat, 24 Mar 2012 03:42:19 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 266DF21F8664 for ; Sat, 24 Mar 2012 03:42:19 -0700 (PDT) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Sat, 24 Mar 2012 10:42:14 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 24 Mar 2012 10:42:16 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.247.3; Sat, 24 Mar 2012 10:42:15 +0000 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 1332585743543; Sat, 24 Mar 2012 10:42:23 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.192.205]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q2OAgCjX002850; Sat, 24 Mar 2012 10:42:12 GMT Message-ID: <201203241042.q2OAgCjX002850@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 24 Mar 2012 10:42:11 +0000 To: From: Bob Briscoe In-Reply-To: References: <4F6A2736.8040403@gmail.com> <4F6A44C3.20506@informatik.uni-tuebingen.de> <4F6A4C7B.8050607@gmail.com> <4F6A69B8.6010601@informatik.uni-tuebingen.de> <201203222258.q2MMwQfX029549@bagheera.jungle.bt.co.uk> <4F6C5FD7.1000804@gmail.com> <201203232006.q2NK67VD000671@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org, "Scott O. Bradner" Subject: Re: [PCN] lets try again - a chair asking this time X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 10:42:20 -0000 Georgios, Indeed. I would have rather said *another* BA, not a *lower* BA. However, that would have changed rather than just clarified what RFC5559 originally said. Then it would probably not be allowed as an erratum and would instead require an update to the architecture RFC. Ie., the proposed wording is not ideal, but it's expedient. I'd rather not risk the delay that would result if the erratum were rejected. Cheers Bob BTW, I've changed the subject line to the thread I think this was intended to be part of - you had replied to one thread but talked about another. At 21:44 23/03/2012, karagian@cs.utwente.nl wrote: >From: >To: , >CC: >Subject: RE: [PCN] Explanation of changes in the PCN edge behaviour drafts >Thread-Topic: [PCN] Explanation of changes in the PCN edge behaviour drafts >Thread-Index: AQHNCTBy2u6oElcMeEuLAQY5k35KpJZ4aG96 >Date: Fri, 23 Mar 2012 21:44:44 +0000 >Message-ID: >References: <4F6A2736.8040403@gmail.com> > <4F6A44C3.20506@informatik.uni-tuebingen.de> > <4F6A4C7B.8050607@gmail.com> > <4F6A69B8.6010601@informatik.uni-tuebingen.de> > <201203222258.q2MMwQfX029549@bagheera.jungle.bt.co.uk> > ><4F6C5FD7.1000804@gmail.com>,<201203232006.q2NK67VD000671@bagheera.jungle.bt.co.uk> >In-Reply-To: <201203232006.q2NK67VD000671@bagheera.jungle.bt.co.uk> > >Hi Bob, > >Regarding the rephrased text: >Police - drop or re-mark to a lower-priority behaviour aggregate > i) packets received with a DSCP indicating PCN transport that do not > belong to an admitted flow and ii) packets that are part of a flow > that asked to be admitted as a PCN-flow but was rejected. > >Why should we emphasize the it should be remarked to a >lower-priority behaviour aggregate? > >Is it acceptable to rephrase the text in the following way (another >instead of low-priority): >Police - drop or re-mark to another behaviour aggregate > i) packets received with a DSCP indicating PCN transport that do not > belong to an admitted flow and ii) packets that are part of a flow > that asked to be admitted as a PCN-flow but was rejected. > >Best regards, >Georgios ________________________________________________________________ Bob Briscoe, BT Innovate & Design From philip.eardley@bt.com Sat Mar 24 10:09:01 2012 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 4392421F852B for ; Sat, 24 Mar 2012 10:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3gUT2VElYK7 for ; Sat, 24 Mar 2012 10:09:00 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFA721F8523 for ; Sat, 24 Mar 2012 10:08:53 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 24 Mar 2012 17:08:52 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.102]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Sat, 24 Mar 2012 17:08:51 +0000 From: To: , Date: Sat, 24 Mar 2012 17:04:24 +0000 Thread-Topic: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac0JfaQgQkUC+asmSVG/w7TiQNcc9AAYoWr+ Message-ID: <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-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: Sat, 24 Mar 2012 17:09:01 -0000 It's Quite a while since I read the edge behavior docs but I don't understa= nd these assumptions. An iea is ask the traffic between two boundary nodes,= what's the idea of several? The pcn architecture talks about admission con= trol and flow termination, flow slowing is an interesting idea but seems di= fferent to me ________________________________________ From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs.= utwente.nl [karagian@cs.utwente.nl] Sent: 24 March 2012 05:19 To: pcn@ietf.org Subject: [PCN] hope changes in PCN drafts will not affect validity assumpti= ons in draft-ietf-tsvwg-rsvp-pcn Hi all, >From what I can recall the edge behavior drafts could proceed with their pu= blication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will b= e standardized in tsvwg. Due to some changes that are being implemented lately the validity of two m= ain assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore. However, this is not clear to me. I hope that the validity of the following two main assumptions considered i= n draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM an= d CL edge behavior specifications: Assumption 1: More than one IEAs between same pair of PCN edge nodes should= be supported, each of them using a different PHB-ID value Why?: A requesting individual flow has a higher chance to be admitted to an= IEA that is NOT in PCN-admission-state How? When IEA supported by a PCN-ingress-node is in PCN-admission state, th= en based on local policy, requesting e2e RSVP session (individual flow) sho= uld be either rejected or mapped to another IEA that is NOT in PCN-admissio= n-state Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an ind= ividual flow without terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects a number of e2e RSVP sess= ions (individual flows) to be either terminated or reserved bandwidth of e2= e RSVP sessions (individual flows) is reduced If these assumptions are not valid anymore then we might need to do changes= in the not yet published PCN drafts! Best regards, Georgios From tm444@hermes.cam.ac.uk Sat Mar 24 10:15:22 2012 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 5265C21F8535 for ; Sat, 24 Mar 2012 10:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vw-Znh4g+Ff for ; Sat, 24 Mar 2012 10:15:21 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 77C9F21F852A for ; Sat, 24 Mar 2012 10:15:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dab-bhx2-nat-blade-1-56.dab.02.net ([82.132.232.188]:58724 helo=[10.92.13.240]) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1SBUYi-0001HX-Da (Exim 4.72) (return-path ); Sat, 24 Mar 2012 17:15:20 +0000 References: <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9A4BFF10-7224-4A90-878D-A93B82C965CB@cl.cam.ac.uk> X-Mailer: iPhone Mail (9B179) From: Toby Moncaster Date: Sat, 24 Mar 2012 17:15:12 +0000 To: "" Sender: "T. Moncaster" Cc: "" Subject: Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-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: Sat, 24 Mar 2012 17:15:22 -0000 I would certainly assume that, for the purposes of controlling pre-congestio= n, an iea consists of all PCN traffic between a given Ingress and egress. If that aggregate is considered as a single flow then in effect flow termina= tion of some of the constituent flows is a form of flow slowing. But PCN has= no actual mechanism for flow slowing (except the proposals for leaking the m= arks to the end systems). On 24 Mar 2012, at 17:04, wrote: > It's Quite a while since I read the edge behavior docs but I don't underst= and these assumptions. An iea is ask the traffic between two boundary nodes,= what's the idea of several? The pcn architecture talks about admission cont= rol and flow termination, flow slowing is an interesting idea but seems diff= erent to me > ________________________________________ > From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs= .utwente.nl [karagian@cs.utwente.nl] > Sent: 24 March 2012 05:19 > To: pcn@ietf.org > Subject: [PCN] hope changes in PCN drafts will not affect validity assumpt= ions in draft-ietf-tsvwg-rsvp-pcn >=20 > Hi all, >=20 >=20 >=20 > =46rom what I can recall the edge behavior drafts could proceed with their= publication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will= be standardized in tsvwg. >=20 > Due to some changes that are being implemented lately the validity of two m= ain assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore. > However, this is not clear to me. > I hope that the validity of the following two main assumptions considered i= n draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM and= CL edge behavior specifications: >=20 > Assumption 1: More than one IEAs between same pair of PCN edge nodes shoul= d be supported, each of them using a different PHB-ID value > Why?: A requesting individual flow has a higher chance to be admitted to a= n IEA that is NOT in PCN-admission-state > How? When IEA supported by a PCN-ingress-node is in PCN-admission state, t= hen based on local policy, requesting e2e RSVP session (individual flow) sho= uld be either rejected or mapped to another IEA that is NOT in PCN-admission= -state >=20 > Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an in= dividual flow without terminating the flow > Why?: flows will not be terminated unnecessary and at the same time the IE= A bandwidth is reduced to solve the severe congestion > How?: When for IEA supported by PCN-ingress-node incoming traffic needs to= be reduced then: > based on a local policy and for same IEA, selects a number of e2e RSVP ses= sions (individual flows) to be either terminated or reserved bandwidth of e2= e RSVP sessions (individual flows) is reduced >=20 > If these assumptions are not valid anymore then we might need to do change= s in the not yet published PCN drafts! >=20 > Best regards, > Georgios >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From karagian@cs.utwente.nl Sun Mar 25 02:15:49 2012 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 8B6BC21F858E for ; Sun, 25 Mar 2012 02:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9btv-k9iqR0 for ; Sun, 25 Mar 2012 02:15:48 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 50D7521F8589 for ; Sun, 25 Mar 2012 02:15:47 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sun, 25 Mar 2012 11:15:46 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Sun, 25 Mar 2012 11:15:45 +0200 From: To: , Thread-Topic: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac0JfaQgQkUC+asmSVG/w7TiQNcc9AAYoWr+ACGl1Ss= Date: Sun, 25 Mar 2012 09:15:44 +0000 Message-ID: References: , <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.202.83.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-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, 25 Mar 2012 09:15:49 -0000 Hi Phil,=20 The first assumption actuallu allows the possibility of having more than on= e PCN aware behaviour aggregates being supported between two edge nodes. I = think that this is/was not precluded from the current specs. Or I am wrong? The second assumption regarding flow slowing is new, but in my opinion was/= is not precluded from the current specs.=20 Or I am wrong? Note that the goal of flow termination, which is to reduce the bandwidth as= sociated with one PCN aware behaviour aggregate is not changed in order to = solve the congestion, i.e., it remains valid.=20 So the assumption allows the possibility of instead of terminating flows re= duce the bandwidth of some flows and achieve the same goal! Best regards ________________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: zaterdag 24 maart 2012 18:04 Aan: Karagiannis, G. (EWI); pcn@ietf.org Onderwerp: RE: [PCN] hope changes in PCN drafts will not affect validity as= sumptions in draft-ietf-tsvwg-rsvp-pcn It's Quite a while since I read the edge behavior docs but I don't understa= nd these assumptions. An iea is ask the traffic between two boundary nodes,= what's the idea of several? The pcn architecture talks about admission con= trol and flow termination, flow slowing is an interesting idea but seems di= fferent to me ________________________________________ From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs.= utwente.nl [karagian@cs.utwente.nl] Sent: 24 March 2012 05:19 To: pcn@ietf.org Subject: [PCN] hope changes in PCN drafts will not affect validity assumpti= ons in draft-ietf-tsvwg-rsvp-pcn Hi all, >From what I can recall the edge behavior drafts could proceed with their pu= blication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will b= e standardized in tsvwg. Due to some changes that are being implemented lately the validity of two m= ain assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore. However, this is not clear to me. I hope that the validity of the following two main assumptions considered i= n draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM an= d CL edge behavior specifications: Assumption 1: More than one IEAs between same pair of PCN edge nodes should= be supported, each of them using a different PHB-ID value Why?: A requesting individual flow has a higher chance to be admitted to an= IEA that is NOT in PCN-admission-state How? When IEA supported by a PCN-ingress-node is in PCN-admission state, th= en based on local policy, requesting e2e RSVP session (individual flow) sho= uld be either rejected or mapped to another IEA that is NOT in PCN-admissio= n-state Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an ind= ividual flow without terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects a number of e2e RSVP sess= ions (individual flows) to be either terminated or reserved bandwidth of e2= e RSVP sessions (individual flows) is reduced If these assumptions are not valid anymore then we might need to do changes= in the not yet published PCN drafts! Best regards, Georgios= From philip.eardley@bt.com Sun Mar 25 08:29:26 2012 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 9D52521F84D2 for ; Sun, 25 Mar 2012 08:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHqsq7dDyl0s for ; Sun, 25 Mar 2012 08:29:25 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 18FB321F84A2 for ; Sun, 25 Mar 2012 08:29:25 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 25 Mar 2012 16:29:24 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.102]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Sun, 25 Mar 2012 16:29:23 +0100 From: To: , Date: Sun, 25 Mar 2012 16:29:22 +0100 Thread-Topic: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac0JfaQgQkUC+asmSVG/w7TiQNcc9AAYoWr+ACGl1SsADH04MA== Message-ID: <9510D26531EF184D9017DF24659BB87F331DE0C412@EMV65-UKRD.domain1.systemhost.net> References: , <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net>, In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-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, 25 Mar 2012 15:29:26 -0000 surely we're trying to finish the work off, rather than opening up new func= tionality? 'not being precluded' is very different from 'will try to support'! on your first suggestion: I'm not sure what you mean by 'more than one PCN aware behaviour aggregate = between two edge nodes'. If you mean, several forwarding priorities I'd dis= agree; if you mean several DSCPs each with the same fwding priority, not su= re I understand the use case; if you mean ECMP - maybe, but I don't underst= and what solution you're thinking of (is it something in http://www.bobbris= coe.net/projects/ipe2eqos/pcn/papers/draft-briscoe-tsvwg-cl-architecture-04= .txt or some new idea?) I'm sceptical, but not sure I understand what your scenario is on your second point: we have always said that PCN is for inelastic flows. with your flow slowing= , this is changing the model. we have always said that flow termination is = highly unusual action taken in extreme cases when somethng has gone wrong -= normally, admission control, plus sensible utilisation, plus flow aggregat= ion, plus that there is lower priority traffic that can flex, should keep t= he network in a safe operating region. To me, flow slowing sounds like an o= ptimisation that isn't worthwhile.=20 So I'm pretty dubious about this one. thanks, phil ________________________________________ From: karagian@cs.utwente.nl [karagian@cs.utwente.nl] Sent: 25 March 2012 10:15 To: Eardley,PL,Philip,DUB8 R; pcn@ietf.org Subject: RE: [PCN] hope changes in PCN drafts will not affect validity assu= mptions in draft-ietf-tsvwg-rsvp-pcn Hi Phil, The first assumption actuallu allows the possibility of having more than on= e PCN aware behaviour aggregates being supported between two edge nodes. I = think that this is/was not precluded from the current specs. Or I am wrong? The second assumption regarding flow slowing is new, but in my opinion was/= is not precluded from the current specs. Or I am wrong? Note that the goal of flow termination, which is to reduce the bandwidth as= sociated with one PCN aware behaviour aggregate is not changed in order to = solve the congestion, i.e., it remains valid. So the assumption allows the possibility of instead of terminating flows re= duce the bandwidth of some flows and achieve the same goal! Best regards ________________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: zaterdag 24 maart 2012 18:04 Aan: Karagiannis, G. (EWI); pcn@ietf.org Onderwerp: RE: [PCN] hope changes in PCN drafts will not affect validity as= sumptions in draft-ietf-tsvwg-rsvp-pcn It's Quite a while since I read the edge behavior docs but I don't understa= nd these assumptions. An iea is ask the traffic between two boundary nodes,= what's the idea of several? The pcn architecture talks about admission con= trol and flow termination, flow slowing is an interesting idea but seems di= fferent to me ________________________________________ From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs.= utwente.nl [karagian@cs.utwente.nl] Sent: 24 March 2012 05:19 To: pcn@ietf.org Subject: [PCN] hope changes in PCN drafts will not affect validity assumpti= ons in draft-ietf-tsvwg-rsvp-pcn Hi all, >From what I can recall the edge behavior drafts could proceed with their pu= blication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will b= e standardized in tsvwg. Due to some changes that are being implemented lately the validity of two m= ain assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore. However, this is not clear to me. I hope that the validity of the following two main assumptions considered i= n draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM an= d CL edge behavior specifications: Assumption 1: More than one IEAs between same pair of PCN edge nodes should= be supported, each of them using a different PHB-ID value Why?: A requesting individual flow has a higher chance to be admitted to an= IEA that is NOT in PCN-admission-state How? When IEA supported by a PCN-ingress-node is in PCN-admission state, th= en based on local policy, requesting e2e RSVP session (individual flow) sho= uld be either rejected or mapped to another IEA that is NOT in PCN-admissio= n-state Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an ind= ividual flow without terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects a number of e2e RSVP sess= ions (individual flows) to be either terminated or reserved bandwidth of e2= e RSVP sessions (individual flows) is reduced If these assumptions are not valid anymore then we might need to do changes= in the not yet published PCN drafts! Best regards, Georgios= From karagian@cs.utwente.nl Sun Mar 25 14:03:53 2012 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 991A321E801A for ; Sun, 25 Mar 2012 14:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROJjuP9TOBDE for ; Sun, 25 Mar 2012 14:03:52 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAB21E800C for ; Sun, 25 Mar 2012 14:03:51 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sun, 25 Mar 2012 23:03:52 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Sun, 25 Mar 2012 23:03:49 +0200 From: To: , Thread-Topic: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn Thread-Index: Ac0JfaQgQkUC+asmSVG/w7TiQNcc9AAYoWr+ACGl1SsADH04MAAKWxL3 Date: Sun, 25 Mar 2012 21:03:49 +0000 Message-ID: References: , <9510D26531EF184D9017DF24659BB87F331DE0C40F@EMV65-UKRD.domain1.systemhost.net>, , <9510D26531EF184D9017DF24659BB87F331DE0C412@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C412@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.202.83.1] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-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, 25 Mar 2012 21:03:53 -0000 Hi Phil, Please see in line! > Van: philip.eardley@bt.com [philip.eardley@bt.com] > Verzonden: zondag 25 maart 2012 17:29 > Aan: Karagiannis, G. (EWI); pcn@ietf.org > Onderwerp: RE: [PCN] hope changes in PCN drafts will not affect validity = assumptions in draft-ietf-tsvwg-rsvp-pcn > surely we're trying to finish the work off, rather than opening up new fu= nctionality? > 'not being precluded' is very different from 'will try to support'! Georgios: Is not really a new functionality, since it combines the features= of RFC 4860 and the PCN specifications to provide the required signaling f= or PCN. > on your first suggestion: > I'm not sure what you mean by 'more than one PCN aware behaviour aggregat= e between two edge nodes'.=20 >If you mean, several forwarding priorities I'd disagree; if you mean sever= al DSCPs each with the=20 > same fwding priority, not sure I understand the use case; if you mean ECM= P - maybe, but I don't understand=20 > what solution you're thinking of (is it something in http://www.bobbrisco= e.net/projects/ipe2eqos/pcn/papers/draft-briscoe-tsvwg-cl-architecture-04.t= xt or some new idea?) > I'm sceptical, but not sure I understand what your scenario is Georgios: What I mean is that it is possible that more than one PCN aware a= ggregates can be used between two edge. If the policy at the edges does not= allow it, then only one PCN aware aggregate between the same pair of edge = nodes will be used. What I had to mention is that these two or more PCN aware aggregates will u= se the same DSCP but will have a different PHB-ID, see Section 2, RFC3140. This will mean that from the point of view of PCN all these behaviour aggre= gates that are setup at the edge nodes will use the same (one) PCN-BA. So the PCN interior nodes will not be aware of the existence of two or more= behaviour aggregates. Regarding the requested motivating scenario, different scenarios can make = use of this. The most motivating one is the scenario described in RFC4860: =93E2E reservations using different preemption priorities (as per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same PHB. Using multiple aggregate reservations for the same PHB allows enforcement of the different preemption priorities within the aggregation region. In turn, this allows more efficient management of the Diffserv resources, and in periods of resource shortage, this allows sustainment of a larger number of E2E reservations with higher preemption priorities. For example, [SIG-NESTED] discusses in detail how= =20 end-to-end RSVP reservations can be established in a nested VPN=20 environment through RSVP aggregation.=94 Please note that the PCN interior nodes are not aware of the existence of t= wo or more behaviour aggregates at the edge nodes. > on your second point: > we have always said that PCN is for inelastic flows. with your flow slowi= ng, this is changing the model. we have always=20 > said that flow termination is highly unusual action taken in extreme case= s when=20 > somethng has gone wrong - normally, admission control, plus sensible util= isation, plus=20 > flow aggregation, plus that there is lower priority traffic that can flex= , should keep the network in a safe operating=20 > region. To me, flow slowing sounds like an optimisation that isn't worthw= hile. > So I'm pretty dubious about this one. Georgios: Using RFC 4495, the reduction of the bandwidth of an individual f= low at the PCN-ingress-node can be done immediately.=20 So from the point of view of the delay in decreasing the total amount of ba= ndwidth for an aggregate, can be observed that: o) the situation where a PCN-ingress-node reduces the bandwidth of a 100kb/= s flow to 50kb/s (belonging to one aggregate) is the same as the situation = that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows be= long to the same aggregate. In other words, the time it takes to terminate a flow is equal (under certa= in bounds) to the time it takes to reduce the bandwidth of a flow. Best regards, Georgios ________________________________________ From: karagian@cs.utwente.nl [karagian@cs.utwente.nl] Sent: 25 March 2012 10:15 To: Eardley,PL,Philip,DUB8 R; pcn@ietf.org Subject: RE: [PCN] hope changes in PCN drafts will not affect validity assu= mptions in draft-ietf-tsvwg-rsvp-pcn Hi Phil, The first assumption actuallu allows the possibility of having more than on= e PCN aware behaviour aggregates being supported between two edge nodes. I = think that this is/was not precluded from the current specs. Or I am wrong? The second assumption regarding flow slowing is new, but in my opinion was/= is not precluded from the current specs. Or I am wrong? Note that the goal of flow termination, which is to reduce the bandwidth as= sociated with one PCN aware behaviour aggregate is not changed in order to = solve the congestion, i.e., it remains valid. So the assumption allows the possibility of instead of terminating flows re= duce the bandwidth of some flows and achieve the same goal! Best regards ________________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: zaterdag 24 maart 2012 18:04 Aan: Karagiannis, G. (EWI); pcn@ietf.org Onderwerp: RE: [PCN] hope changes in PCN drafts will not affect validity as= sumptions in draft-ietf-tsvwg-rsvp-pcn It's Quite a while since I read the edge behavior docs but I don't understa= nd these assumptions. An iea is ask the traffic between two boundary nodes,= what's the idea of several? The pcn architecture talks about admission con= trol and flow termination, flow slowing is an interesting idea but seems di= fferent to me ________________________________________ From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs.= utwente.nl [karagian@cs.utwente.nl] Sent: 24 March 2012 05:19 To: pcn@ietf.org Subject: [PCN] hope changes in PCN drafts will not affect validity assumpti= ons in draft-ietf-tsvwg-rsvp-pcn Hi all, >From what I can recall the edge behavior drafts could proceed with their pu= blication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will b= e standardized in tsvwg. Due to some changes that are being implemented lately the validity of two m= ain assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore. However, this is not clear to me. I hope that the validity of the following two main assumptions considered i= n draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM an= d CL edge behavior specifications: Assumption 1: More than one IEAs between same pair of PCN edge nodes should= be supported, each of them using a different PHB-ID value Why?: A requesting individual flow has a higher chance to be admitted to an= IEA that is NOT in PCN-admission-state How? When IEA supported by a PCN-ingress-node is in PCN-admission state, th= en based on local policy, requesting e2e RSVP session (individual flow) sho= uld be either rejected or mapped to another IEA that is NOT in PCN-admissio= n-state Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an ind= ividual flow without terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects a number of e2e RSVP sess= ions (individual flows) to be either terminated or reserved bandwidth of e2= e RSVP sessions (individual flows) is reduced If these assumptions are not valid anymore then we might need to do changes= in the not yet published PCN drafts! Best regards, Georgios= From karagian@cs.utwente.nl Sun Mar 25 15:30:23 2012 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 2831A21E8032 for ; Sun, 25 Mar 2012 15:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uw0VsIbugw1Z for ; Sun, 25 Mar 2012 15:30:21 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD2D21E8029 for ; Sun, 25 Mar 2012 15:30:19 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 26 Mar 2012 00:30:20 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Mon, 26 Mar 2012 00:30:18 +0200 From: To: Thread-Topic: dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) Thread-Index: AQHNCtRROgmgTspi7EGWYEs7DMvJYg== Date: Sun, 25 Mar 2012 22:30:17 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.202.83.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) 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, 25 Mar 2012 22:30:23 -0000 Hi all, In order to satisfy the comments received up to now I am willing to provide= the following changes in the draft-ietf-tsvwg-rsvp-pcn. Proposed change:=20 Each ingress-egress pair supports only one ingress-egress aggregate. This i= s identical to what any PCN specification specifies. The Aggregator (ingress), and DeAggregator (egress) however, can support mo= re than one RSVP generic aagregated reservation state belonging to the same= PHB, see RFC4860. The RSVP generic aggregated resevation states that are m= aintained between the same pair of ingress-egress will use the PCN-BA, whic= h is actually using the same PHB as these RSVP generic aggregated states. This means that all these RSVP generic aggregated reservation states will u= se the same PCN admission control procedure, since they will use the same P= CN-BA in the PCN domain. Note that the definition that is given for IEA in draft-ietf-tsvwg-rsvp-pcn= -01.txt needs to be modifed to satisfy the above. Moreover, the last rule = given in Section 3.1 that is associated with the admission control procedur= e needs to be modified to address the fact that all the RSVP generic aggreg= ated resevation states will use the same PCN admission control procedure.=20 So assumption 1, listed in a previous email does not need to be supported a= nymore! What is still remaining is the need of having assumption 2 supported: PCN-ingress-node should be able to reduce bandwidth of an individual flow w= ithout terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects using the features provid= ed by RFC 4860 a number of inelastic e2e RSVP sessions (individual flows) t= o be either terminated or reserved bandwidth of the inelastic e2e RSVP sess= ions (individual flows) is reduced. Note that due to the above changes, the specification provided in Section 3= .11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow termination needs to= be modified. In particular, it is needed to specify that for the situation= that the Aggregator/ingress needs to terminate an amount of traffic associ= ated tone PCN IEA, it must be able to know: (1) which RSVP generic aggregat= ed resevation states (associated with this PCN IEA) will be selected and (2= ) which individual flows belonging to these selected sates will either be = terminated or their bandwidth will be reduced. Note that using RFC 4495, the reduction of the bandwidth of an individual f= low at the PCN-ingress-node can be done immediately. So from the point of view of the delay in decreasing the total amount of ba= ndwidth for an PCN IEA, can be observed that: o) the situation where a PCN-ingress-node reduces the bandwidth of a 100kb/= s flow to 50kb/s (belonging to one aggregate) is the same as the situation = that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows be= long to the same aggregate. In other words, the time it takes to terminate a flow is equal (under certa= in bounds) to the time it takes to reduce the bandwidth of a flow. =20 Best regards, Georgios= From slblake@petri-meat.com Mon Mar 26 06:53:02 2012 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 C266D21F85CC for ; Mon, 26 Mar 2012 06:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.045 X-Spam-Level: X-Spam-Status: No, score=-100.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmtZv5sOCO1a for ; Mon, 26 Mar 2012 06:53:02 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8E61D21E80A6 for ; Mon, 26 Mar 2012 06:52:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To:Subject:Message-ID:X-Sender:User-Agent; b=0ajUsUtyWzAQpwSHnmrbZ4df7D6hUmRPir/ynsI1eBL3vQsD2/7uYP7R3jGBIm0Nz+prTKq1i5HyLxGm6UpHDCd/gOHFA7bYp7+3Qe1KCsdKoG0jt2xTX41I+IllQKcm; Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1SCALr-0002tK-BY; Mon, 26 Mar 2012 09:52:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 26 Mar 2012 09:52:51 -0400 From: Steven Blake To: Message-ID: <6bd6f108293e024c5aac20ac39ae160f@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: Roundcube Webmail/0.6 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] Minute taker and jabber scribe for PCN meeting 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, 26 Mar 2012 13:53:02 -0000 Hi, Looking for volunteers to take minutes or watch the jabber room at the PCN meeting on Wednesday. Thanks, // Steve From philip.eardley@bt.com Mon Mar 26 07:13:17 2012 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 8EB6721F8782 for ; Mon, 26 Mar 2012 07:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwTZpEUMf-xh for ; Mon, 26 Mar 2012 07:13:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 68BDE21F8781 for ; Mon, 26 Mar 2012 07:13:16 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 26 Mar 2012 15:13:10 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.102]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Mon, 26 Mar 2012 15:13:09 +0100 From: To: , Date: Mon, 26 Mar 2012 15:13:08 +0100 Thread-Topic: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) Thread-Index: AQHNCtRROgmgTspi7EGWYEs7DMvJYpZ8lnFp Message-ID: <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net> References: In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) 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, 26 Mar 2012 14:13:17 -0000 Assumption 1 thanks for this. note you don't need to change the definition of IEA - just use the definiti= on it already has (in PCN architecture) Assumption 2 please can you point me the right bit of 4860 - about reducing the reserved= bandwidth of individual rsvp sessions. couldnt find it immediately. whilst mathematically reducing one 100kb/s flow to 50kb/s is equal to termi= nating one of two 50kb/s flows - however, it requires the PCN decision node= to understand that the current 100kb/s inelstic flow has another state whe= re it can operate as a 50kb/s inelsatic flow. it seems to me this requires = significantly more complexity (state at decision point, decision making pro= cess, possibly signalling etc).=20 Again: termination is supposed to be a 'quick and dirty' function when some= thing has gone wrong. Anyway, having slept on our chat at the social, I suggest a way forward is = the following. The draft should define signalling for the scope of PCN, as it's been assum= ed so far, ie don't mention these two assumptions. This enables PCN to be f= inished. These two extra assumptions are things that should be invisible to PCN - it= 's just fine-grained information hiding within the policy and decision func= tions. For instance, we have never talked about a policy on how the decisio= n point should decide which flows to terminate (just how much it needs to t= erminate) - it could choose randomly, it could choose the most recently est= ablished, it could choose the customers who are least important etc. I thin= k your 'flow slowing' is just another piece of policy that PCN doesn't need= to talk about. (You could actually say the same thing about assumption 1) in passing, note that PCN is about PCN-flows. RFC5559 defines:- o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node admits (or terminates); the unit could be a single microflow (as defined in [RFC2474]) or some identifiable collection of microflows. since your draft needs to cover the relationship of the e2e signalling & PC= N, you need to explain the relationship between the e2e rsvp flows and pcn-= flows. i suggest you pick the easiest case, which i presume is a 1:1 mappin= g. anyway, going back to my original comments - you can delete the one about many-to-one mapping (now you're deleting assum= ption 1) but i think the others still apply. thanks phil ________________________________________ From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs.= utwente.nl [karagian@cs.utwente.nl] Sent: 25 March 2012 23:30 To: pcn@ietf.org Subject: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (= assumption 2 needed) Hi all, In order to satisfy the comments received up to now I am willing to provide= the following changes in the draft-ietf-tsvwg-rsvp-pcn. Proposed change: Each ingress-egress pair supports only one ingress-egress aggregate. This i= s identical to what any PCN specification specifies. The Aggregator (ingress), and DeAggregator (egress) however, can support mo= re than one RSVP generic aagregated reservation state belonging to the same= PHB, see RFC4860. The RSVP generic aggregated resevation states that are m= aintained between the same pair of ingress-egress will use the PCN-BA, whic= h is actually using the same PHB as these RSVP generic aggregated states. This means that all these RSVP generic aggregated reservation states will u= se the same PCN admission control procedure, since they will use the same P= CN-BA in the PCN domain. Note that the definition that is given for IEA in draft-ietf-tsvwg-rsvp-pcn= -01.txt needs to be modifed to satisfy the above. Moreover, the last rule = given in Section 3.1 that is associated with the admission control procedur= e needs to be modified to address the fact that all the RSVP generic aggreg= ated resevation states will use the same PCN admission control procedure. So assumption 1, listed in a previous email does not need to be supported a= nymore! What is still remaining is the need of having assumption 2 supported: PCN-ingress-node should be able to reduce bandwidth of an individual flow w= ithout terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects using the features provid= ed by RFC 4860 a number of inelastic e2e RSVP sessions (individual flows) t= o be either terminated or reserved bandwidth of the inelastic e2e RSVP sess= ions (individual flows) is reduced. Note that due to the above changes, the specification provided in Section 3= .11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow termination needs to= be modified. In particular, it is needed to specify that for the situation= that the Aggregator/ingress needs to terminate an amount of traffic associ= ated tone PCN IEA, it must be able to know: (1) which RSVP generic aggregat= ed resevation states (associated with this PCN IEA) will be selected and (2= ) which individual flows belonging to these selected sates will either be = terminated or their bandwidth will be reduced. Note that using RFC 4495, the reduction of the bandwidth of an individual f= low at the PCN-ingress-node can be done immediately. So from the point of view of the delay in decreasing the total amount of ba= ndwidth for an PCN IEA, can be observed that: o) the situation where a PCN-ingress-node reduces the bandwidth of a 100kb/= s flow to 50kb/s (belonging to one aggregate) is the same as the situation = that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows be= long to the same aggregate. In other words, the time it takes to terminate a flow is equal (under certa= in bounds) to the time it takes to reduce the bandwidth of a flow. Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From tm444@hermes.cam.ac.uk Mon Mar 26 07:26:51 2012 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 A836621E80A5 for ; Mon, 26 Mar 2012 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDu86iPHotgU for ; Mon, 26 Mar 2012 07:26:50 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6261F21E80A3 for ; Mon, 26 Mar 2012 07:26:50 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:63006) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1SCAsi-0007oZ-Z7 (Exim 4.72) (return-path ); Mon, 26 Mar 2012 15:26:48 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Toby Moncaster In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net> Date: Mon, 26 Mar 2012 15:26:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46B08E2E-E8E2-474F-8917-B4006E5F25C5@cl.cam.ac.uk> References: <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1257) Sender: "T. Moncaster" Cc: pcn@ietf.org Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) 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, 26 Mar 2012 14:26:51 -0000 I think the two most important points to remember are: 1) The IESG wants to close the PCN working group (and I for one think = that seems sensible) 2) This signalling document is meant to be one of the core building = blocks that can be bolted together to create a PCN-based admission = system. As such it should be written with as few assumptions as = possible, and certainly should not be adding new concepts that were = never in the original PCN charter.=20 more inline On 26 Mar 2012, at 15:13, wrote: > Assumption 1 > thanks for this. > note you don't need to change the definition of IEA - just use the = definition it already has (in PCN architecture) >=20 > Assumption 2 > please can you point me the right bit of 4860 - about reducing the = reserved bandwidth of individual rsvp sessions. couldnt find it = immediately. > whilst mathematically reducing one 100kb/s flow to 50kb/s is equal to = terminating one of two 50kb/s flows - however, it requires the PCN = decision node to understand that the current 100kb/s inelstic flow has = another state where it can operate as a 50kb/s inelsatic flow. it seems = to me this requires significantly more complexity (state at decision = point, decision making process, possibly signalling etc).=20 > Again: termination is supposed to be a 'quick and dirty' function when = something has gone wrong. And all the documents have made that clear throughout (see the default = abstract/intro text that is in nearly all the other documents now). >=20 > Anyway, having slept on our chat at the social, I suggest a way = forward is the following. > The draft should define signalling for the scope of PCN, as it's been = assumed so far, ie don't mention these two assumptions. This enables PCN = to be finished. > These two extra assumptions are things that should be invisible to PCN = - it's just fine-grained information hiding within the policy and = decision functions. For instance, we have never talked about a policy on = how the decision point should decide which flows to terminate (just how = much it needs to terminate) - it could choose randomly, it could choose = the most recently established, it could choose the customers who are = least important etc. I think your 'flow slowing' is just another piece = of policy that PCN doesn't need to talk about. +1 > (You could actually say the same thing about assumption 1) >=20 > in passing, note that PCN is about PCN-flows. RFC5559 defines:- > o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node > admits (or terminates); the unit could be a single microflow (as > defined in [RFC2474]) or some identifiable collection of > microflows. >=20 > since your draft needs to cover the relationship of the e2e signalling = & PCN, you need to explain the relationship between the e2e rsvp flows = and pcn-flows. i suggest you pick the easiest case, which i presume is a = 1:1 mapping. If you DO feel there is a need for more cases then that should go in as = a (very short) appendix.=20 And remember, so long as this document is crafted correctly (using 2119 = language carefully) it can include your assumptions without ever needing = to state them. Then if you are keen to have some future extension that = looks at flow-slowing you could put that in as an individual draft to = TSWWG once PCN is closed.=20 Toby >=20 > anyway, going back to my original comments - > you can delete the one about many-to-one mapping (now you're deleting = assumption 1) > but i think the others still apply. >=20 > thanks > phil >=20 > ________________________________________ > From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of = karagian@cs.utwente.nl [karagian@cs.utwente.nl] > Sent: 25 March 2012 23:30 > To: pcn@ietf.org > Subject: [PCN] dropping assumption 1 for = draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) >=20 > Hi all, >=20 > In order to satisfy the comments received up to now I am willing to = provide the following changes in the draft-ietf-tsvwg-rsvp-pcn. >=20 > Proposed change: > Each ingress-egress pair supports only one ingress-egress aggregate. = This is identical to what any PCN specification specifies. >=20 > The Aggregator (ingress), and DeAggregator (egress) however, can = support more than one RSVP generic aagregated reservation state = belonging to the same PHB, see RFC4860. The RSVP generic aggregated = resevation states that are maintained between the same pair of = ingress-egress will use the PCN-BA, which is actually using the same PHB = as these RSVP generic aggregated states. >=20 > This means that all these RSVP generic aggregated reservation states = will use the same PCN admission control procedure, since they will use = the same PCN-BA in the PCN domain. >=20 > Note that the definition that is given for IEA in = draft-ietf-tsvwg-rsvp-pcn-01.txt needs to be modifed to satisfy the = above. Moreover, the last rule given in Section 3.1 that is associated = with the admission control procedure needs to be modified to address the = fact that all the RSVP generic aggregated resevation states will use the = same PCN admission control procedure. > So assumption 1, listed in a previous email does not need to be = supported anymore! >=20 > What is still remaining is the need of having assumption 2 supported: >=20 > PCN-ingress-node should be able to reduce bandwidth of an individual = flow without terminating the flow >=20 > Why?: flows will not be terminated unnecessary and at the same time = the IEA bandwidth is reduced to solve the severe congestion > How?: When for IEA supported by PCN-ingress-node incoming traffic = needs to be reduced then: > based on a local policy and for same IEA, selects using the features = provided by RFC 4860 a number of inelastic e2e RSVP sessions (individual = flows) to be either terminated or reserved bandwidth of the inelastic = e2e RSVP sessions (individual flows) is reduced. >=20 > Note that due to the above changes, the specification provided in = Section 3.11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow = termination needs to be modified. In particular, it is needed to specify = that for the situation that the Aggregator/ingress needs to terminate an = amount of traffic associated tone PCN IEA, it must be able to know: (1) = which RSVP generic aggregated resevation states (associated with this = PCN IEA) will be selected and (2) which individual flows belonging to = these selected sates will either be terminated or their bandwidth will = be reduced. >=20 > Note that using RFC 4495, the reduction of the bandwidth of an = individual flow at the PCN-ingress-node can be done immediately. > So from the point of view of the delay in decreasing the total amount = of bandwidth for an PCN IEA, can be observed that: > o) the situation where a PCN-ingress-node reduces the bandwidth of a = 100kb/s flow to 50kb/s (belonging to one aggregate) is the same as the = situation that a PCN-ingress-node terminates one 50kb/s flow when two = 50kb/s flows belong to the same aggregate. > In other words, the time it takes to terminate a flow is equal (under = certain bounds) to the time it takes to reduce the bandwidth of a flow. >=20 >=20 > Best regards, > Georgios > _______________________________________________ > 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 karagian@cs.utwente.nl Mon Mar 26 07:48:46 2012 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 5DB9C21E8097 for ; Mon, 26 Mar 2012 07:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi7FnW3oKJo4 for ; Mon, 26 Mar 2012 07:48:45 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8877C21E80B1 for ; Mon, 26 Mar 2012 07:48:44 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 26 Mar 2012 16:48:47 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Mon, 26 Mar 2012 16:48:43 +0200 From: To: , Thread-Topic: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) Thread-Index: AQHNCtRROgmgTspi7EGWYEs7DMvJYpZ8lnFpgAAKBc4= Date: Mon, 26 Mar 2012 14:48:42 +0000 Message-ID: References: , <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.202.83.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) 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, 26 Mar 2012 14:48:46 -0000 Hi Phil, Thanks for the comments! Please see in line! > Van: philip.eardley@bt.com [philip.eardley@bt.com] > Verzonden: maandag 26 maart 2012 16:13 > Aan: Karagiannis, G. (EWI); pcn@ietf.org > Onderwerp: RE: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-= 01.txt (assumption 2 needed) > Assumption 1 > thanks for this. > note you don't need to change the definition of IEA - just use the defini= tion=20 > it already has (in PCN architecture) Georgios: Okay, thanks I will do that! > Assumption 2 > please can you point me the right bit of 4860 - about reducing the reserv= ed=20 > bandwidth of individual rsvp sessions. couldnt find it immediately. > whilst mathematically reducing one 100kb/s flow to 50kb/s is equal to=20 > terminating one of two 50kb/s flows - however, it requires the PCN=20 > decision node to understand that the current 100kb/s inelstic flow has=20 > another state where it can operate as a 50kb/s inelsatic flow. it seems=20 > to me this requires significantly more complexity (state at decision poin= t,=20 > decision making process, possibly signalling etc). > Again: termination is supposed to be a 'quick and dirty' function when=20 > something has gone wrong. Georgios: RFC 4860 uses RFC 4495 to do the reduction of bandwidth. The Aggr= egator is already informed before hand about how much bandwidth should be r= educed from certain individual flows. So the Aggregator can reduce the band= width of these flows at the moment that an amount of bandwidth needs to be = reduced from the IEA. This is similar to the situation that a flow needs to= be terminated and the Aggregator reduces the complete allocated bandwidth = of that flow. > Anyway, having slept on our chat at the social, I suggest a way forward i= s the following. > The draft should define signalling for the scope of PCN, as it's been ass= umed so far,=20 > ie don't mention these two assumptions. This enables PCN to be finished. > These two extra assumptions are things that should be invisible to=20 > PCN - it's just fine-grained information hiding within the policy=20 > and decision functions. For instance, we have never talked about a policy= =20 > on how the decision point should decide which flows to terminate=20 > (just how much it needs to terminate) - it could choose randomly, it coul= d=20 > choose the most recently established, it could choose the customers who a= re=20 > least important etc. I think your 'flow slowing' is just another piece of= policy=20 > that PCN doesn't need to talk about. (You could actually say the same thi= ng=20 > about assumption 1) Georgios: Okay, great!=20 So your suggestion is to describe in the draft the situation that the sever= e congestion is solved by terminating flows. As an addition to that, the d= raft will emphasize that in some situations different policies can be used = to solve the severe congestion, where instead of terminating the complete b= andwidth allocated to one or more flows and by using the mechanisms specifi= ed by RFC4680 and RFC 4495, only a percentage of the bandwidth allocated to= one or more flows will be reduced. > in passing, note that PCN is about PCN-flows. RFC5559 defines:- > o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node > admits (or terminates); the unit could be a single microflow (as > defined in [RFC2474]) or some identifiable collection of > microflows. > since your draft needs to cover the relationship of the e2e signalling & = PCN,=20 > you need to explain the relationship between the e2e rsvp flows and pcn-f= lows.=20 > i suggest you pick the easiest case, which i presume is a 1:1 mapping. > anyway, going back to my original comments - > you can delete the one about many-to-one mapping (now you're deleting ass= umption 1) > but i think the others still apply. Georgios: The mapping of e2e rsvp flows to pcn-flows is a one-to-one mappin= g.=20 However the mapping of the RSVP generic aggregated reservation states to th= e PCN IEA is a many-to-one mapping. > thanks > phil ________________________________________ From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@cs.= utwente.nl [karagian@cs.utwente.nl] Sent: 25 March 2012 23:30 To: pcn@ietf.org Subject: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (= assumption 2 needed) Hi all, In order to satisfy the comments received up to now I am willing to provide= the following changes in the draft-ietf-tsvwg-rsvp-pcn. Proposed change: Each ingress-egress pair supports only one ingress-egress aggregate. This i= s identical to what any PCN specification specifies. The Aggregator (ingress), and DeAggregator (egress) however, can support mo= re than one RSVP generic aagregated reservation state belonging to the same= PHB, see RFC4860. The RSVP generic aggregated resevation states that are m= aintained between the same pair of ingress-egress will use the PCN-BA, whic= h is actually using the same PHB as these RSVP generic aggregated states. This means that all these RSVP generic aggregated reservation states will u= se the same PCN admission control procedure, since they will use the same P= CN-BA in the PCN domain. Note that the definition that is given for IEA in draft-ietf-tsvwg-rsvp-pcn= -01.txt needs to be modifed to satisfy the above. Moreover, the last rule = given in Section 3.1 that is associated with the admission control procedur= e needs to be modified to address the fact that all the RSVP generic aggreg= ated resevation states will use the same PCN admission control procedure. So assumption 1, listed in a previous email does not need to be supported a= nymore! What is still remaining is the need of having assumption 2 supported: PCN-ingress-node should be able to reduce bandwidth of an individual flow w= ithout terminating the flow Why?: flows will not be terminated unnecessary and at the same time the IEA= bandwidth is reduced to solve the severe congestion How?: When for IEA supported by PCN-ingress-node incoming traffic needs to = be reduced then: based on a local policy and for same IEA, selects using the features provid= ed by RFC 4860 a number of inelastic e2e RSVP sessions (individual flows) t= o be either terminated or reserved bandwidth of the inelastic e2e RSVP sess= ions (individual flows) is reduced. Note that due to the above changes, the specification provided in Section 3= .11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow termination needs to= be modified. In particular, it is needed to specify that for the situation= that the Aggregator/ingress needs to terminate an amount of traffic associ= ated tone PCN IEA, it must be able to know: (1) which RSVP generic aggregat= ed resevation states (associated with this PCN IEA) will be selected and (2= ) which individual flows belonging to these selected sates will either be = terminated or their bandwidth will be reduced. Note that using RFC 4495, the reduction of the bandwidth of an individual f= low at the PCN-ingress-node can be done immediately. So from the point of view of the delay in decreasing the total amount of ba= ndwidth for an PCN IEA, can be observed that: o) the situation where a PCN-ingress-node reduces the bandwidth of a 100kb/= s flow to 50kb/s (belonging to one aggregate) is the same as the situation = that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows be= long to the same aggregate. In other words, the time it takes to terminate a flow is equal (under certa= in bounds) to the time it takes to reduce the bandwidth of a flow. Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From philip.eardley@bt.com Tue Mar 27 00:39:08 2012 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 6980F21F8781 for ; Tue, 27 Mar 2012 00:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm-+RO5Wh4BS for ; Tue, 27 Mar 2012 00:39:05 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 340D421F87AA for ; Tue, 27 Mar 2012 00:39:04 -0700 (PDT) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Mar 2012 08:39:04 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.102]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Tue, 27 Mar 2012 08:39:02 +0100 From: To: Date: Tue, 27 Mar 2012 08:36:22 +0100 Thread-Topic: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) Thread-Index: Ac0LXIM85BDK8RYfRZGcGcF5cczEiAAj8sCY Message-ID: <9510D26531EF184D9017DF24659BB87F331DE0C41C@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net>, <46B08E2E-E8E2-474F-8917-B4006E5F25C5@cl.cam.ac.uk> In-Reply-To: <46B08E2E-E8E2-474F-8917-B4006E5F25C5@cl.cam.ac.uk> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) 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, 27 Mar 2012 07:39:08 -0000 Georgios on your assumption 2 about slowing a flow rather than terminating it. you said that the necessary functionality is already in rfc4495 its abstract says: In such cases, when the entire bandwidth allocated to a reservation is not required, the reservation need not be torn down. The solution described in this document allows endpoints to negotiate a new (lower) bandwidth that falls at or below the specified new bandwidth maximum allocated by the network.=20 this is not the same function. this is about negotiating a new lower bandwi= dth. the functionality you need is for the PCN decision point to understand= in advance that there is a lower rate(s) to which the flow could be reduce= d if necessary (and both rates are inelastic) phil ________________________________________ From: T. Moncaster [tm444@hermes.cam.ac.uk] On Behalf Of Toby Moncaster [to= by.moncaster@cl.cam.ac.uk] Sent: 26 March 2012 15:26 To: Eardley,PL,Philip,DUB8 R Cc: karagian@cs.utwente.nl; pcn@ietf.org Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.t= xt (assumption 2 needed) I think the two most important points to remember are: 1) The IESG wants to close the PCN working group (and I for one think that = seems sensible) 2) This signalling document is meant to be one of the core building blocks = that can be bolted together to create a PCN-based admission system. As such= it should be written with as few assumptions as possible, and certainly sh= ould not be adding new concepts that were never in the original PCN charter= . more inline On 26 Mar 2012, at 15:13, wrote: > Assumption 1 > thanks for this. > note you don't need to change the definition of IEA - just use the defini= tion it already has (in PCN architecture) > > Assumption 2 > please can you point me the right bit of 4860 - about reducing the reserv= ed bandwidth of individual rsvp sessions. couldnt find it immediately. > whilst mathematically reducing one 100kb/s flow to 50kb/s is equal to ter= minating one of two 50kb/s flows - however, it requires the PCN decision no= de to understand that the current 100kb/s inelstic flow has another state w= here it can operate as a 50kb/s inelsatic flow. it seems to me this require= s significantly more complexity (state at decision point, decision making p= rocess, possibly signalling etc). > Again: termination is supposed to be a 'quick and dirty' function when so= mething has gone wrong. And all the documents have made that clear throughout (see the default abst= ract/intro text that is in nearly all the other documents now). > > Anyway, having slept on our chat at the social, I suggest a way forward i= s the following. > The draft should define signalling for the scope of PCN, as it's been ass= umed so far, ie don't mention these two assumptions. This enables PCN to be= finished. > These two extra assumptions are things that should be invisible to PCN - = it's just fine-grained information hiding within the policy and decision fu= nctions. For instance, we have never talked about a policy on how the decis= ion point should decide which flows to terminate (just how much it needs to= terminate) - it could choose randomly, it could choose the most recently e= stablished, it could choose the customers who are least important etc. I th= ink your 'flow slowing' is just another piece of policy that PCN doesn't ne= ed to talk about. +1 > (You could actually say the same thing about assumption 1) > > in passing, note that PCN is about PCN-flows. RFC5559 defines:- > o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node > admits (or terminates); the unit could be a single microflow (as > defined in [RFC2474]) or some identifiable collection of > microflows. > > since your draft needs to cover the relationship of the e2e signalling & = PCN, you need to explain the relationship between the e2e rsvp flows and pc= n-flows. i suggest you pick the easiest case, which i presume is a 1:1 mapp= ing. If you DO feel there is a need for more cases then that should go in as a (= very short) appendix. And remember, so long as this document is crafted correctly (using 2119 lan= guage carefully) it can include your assumptions without ever needing to st= ate them. Then if you are keen to have some future extension that looks at = flow-slowing you could put that in as an individual draft to TSWWG once PCN= is closed. Toby > > anyway, going back to my original comments - > you can delete the one about many-to-one mapping (now you're deleting ass= umption 1) > but i think the others still apply. > > thanks > phil > > ________________________________________ > From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@c= s.utwente.nl [karagian@cs.utwente.nl] > Sent: 25 March 2012 23:30 > To: pcn@ietf.org > Subject: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt= (assumption 2 needed) > > Hi all, > > In order to satisfy the comments received up to now I am willing to provi= de the following changes in the draft-ietf-tsvwg-rsvp-pcn. > > Proposed change: > Each ingress-egress pair supports only one ingress-egress aggregate. This= is identical to what any PCN specification specifies. > > The Aggregator (ingress), and DeAggregator (egress) however, can support = more than one RSVP generic aagregated reservation state belonging to the sa= me PHB, see RFC4860. The RSVP generic aggregated resevation states that are= maintained between the same pair of ingress-egress will use the PCN-BA, wh= ich is actually using the same PHB as these RSVP generic aggregated states. > > This means that all these RSVP generic aggregated reservation states will= use the same PCN admission control procedure, since they will use the same= PCN-BA in the PCN domain. > > Note that the definition that is given for IEA in draft-ietf-tsvwg-rsvp-p= cn-01.txt needs to be modifed to satisfy the above. Moreover, the last rul= e given in Section 3.1 that is associated with the admission control proced= ure needs to be modified to address the fact that all the RSVP generic aggr= egated resevation states will use the same PCN admission control procedure. > So assumption 1, listed in a previous email does not need to be supported= anymore! > > What is still remaining is the need of having assumption 2 supported: > > PCN-ingress-node should be able to reduce bandwidth of an individual flow= without terminating the flow > > Why?: flows will not be terminated unnecessary and at the same time the I= EA bandwidth is reduced to solve the severe congestion > How?: When for IEA supported by PCN-ingress-node incoming traffic needs t= o be reduced then: > based on a local policy and for same IEA, selects using the features prov= ided by RFC 4860 a number of inelastic e2e RSVP sessions (individual flows)= to be either terminated or reserved bandwidth of the inelastic e2e RSVP se= ssions (individual flows) is reduced. > > Note that due to the above changes, the specification provided in Section= 3.11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow termination needs = to be modified. In particular, it is needed to specify that for the situati= on that the Aggregator/ingress needs to terminate an amount of traffic asso= ciated tone PCN IEA, it must be able to know: (1) which RSVP generic aggreg= ated resevation states (associated with this PCN IEA) will be selected and = (2) which individual flows belonging to these selected sates will either b= e terminated or their bandwidth will be reduced. > > Note that using RFC 4495, the reduction of the bandwidth of an individual= flow at the PCN-ingress-node can be done immediately. > So from the point of view of the delay in decreasing the total amount of = bandwidth for an PCN IEA, can be observed that: > o) the situation where a PCN-ingress-node reduces the bandwidth of a 100k= b/s flow to 50kb/s (belonging to one aggregate) is the same as the situatio= n that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows = belong to the same aggregate. > In other words, the time it takes to terminate a flow is equal (under cer= tain bounds) to the time it takes to reduce the bandwidth of a flow. > > > Best regards, > Georgios > _______________________________________________ > 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 Tue Mar 27 00:52:57 2012 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 8F83221F87B0; Tue, 27 Mar 2012 00:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.452 X-Spam-Level: X-Spam-Status: No, score=-103.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYb3VpXZl9cr; Tue, 27 Mar 2012 00:52:57 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id B084621F87AD; Tue, 27 Mar 2012 00:52:56 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Mar 2012 08:52:57 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.102]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 27 Mar 2012 08:52:55 +0100 From: To: , , Date: Tue, 27 Mar 2012 08:52:54 +0100 Thread-Topic: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 Thread-Index: AQHNC+6d9MhH5pYYBkKeQn1PQISJ4g== Message-ID: <9510D26531EF184D9017DF24659BB87F331DE0C41E@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PCN] comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 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, 27 Mar 2012 07:52:57 -0000 the question I was trying to raise at the mike earlier is this:- at the moment the draft is written as an extension to generic aggregated rs= vp. Is it possible to write an extension that works as a PCN extension for = either /both aggregated rsvp or generic aggregated rsvp? that would widen i= ts applicability.=20 (Unless in practice only generic aggregated is used and aggregated rsvp isn= 't used??) may well be that this is a stupid suggestion! thanks phil= From karagian@cs.utwente.nl Tue Mar 27 08:13:44 2012 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 66DFA21F88D7 for ; Tue, 27 Mar 2012 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.044 X-Spam-Level: X-Spam-Status: No, score=0.044 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31i0ebeqBbng for ; Tue, 27 Mar 2012 08:13:43 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA3821F88B0 for ; Tue, 27 Mar 2012 08:13:35 -0700 (PDT) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 27 Mar 2012 17:13:40 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Tue, 27 Mar 2012 17:13:34 +0200 From: To: , Thread-Topic: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) Thread-Index: AQHNCtRROgmgTspi7EGWYEs7DMvJYpZ8lnFp///rUwCAAR+pAIAAn0Vw Date: Tue, 27 Mar 2012 15:13:33 +0000 Message-ID: References: <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net>, <46B08E2E-E8E2-474F-8917-B4006E5F25C5@cl.cam.ac.uk>, <9510D26531EF184D9017DF24659BB87F331DE0C41C@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C41C@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.202.83.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) 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, 27 Mar 2012 15:13:44 -0000 Hi Phil, Section 2 of RFC 4495 explains that during the re-reservation request perio= d of time no packets will traverse the "affected"" aggregate (which contai= ns the individual flows whose bandwidth needs to be reduced), until it is r= eestablished. So during that time no packets (belonging to the individual f= lows whose bandwidth needs to be reduced) will traverse the PCN domain unti= l it is reestablished. See the text copied from Section2 of RFC 4495. --// -- This specification makes it possible for the ResvErr message to indicate that 20 units are still available for a reservation to remain up (the interface's 100 units maximum minus Flow 2's 80 units). The reservation initiating node (router or end-system) for Flow 1 has the opportunity to renegotiate (via call signaling) for acceptable parameters within the existing and available bandwidth for the flow (for example, it may decide to change to using a codec such as G.729) --//-- During the re-reservation request period of time no packets will traverse the aggregate until it is reestablished. - reduces the chances that the reestablishment of the aggregate will reserve an inefficient amount of bandwidth, causing the likely preemption of more individual flows at the aggregator than would be necessary had the aggregator had more information (that RSVP does not provide at this time) -//=3D=3D Best regards, Georgios ________________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: dinsdag 27 maart 2012 9:36 Aan: toby.moncaster@cl.cam.ac.uk CC: Karagiannis, G. (EWI); pcn@ietf.org Onderwerp: RE: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01= .txt (assumption 2 needed) Georgios on your assumption 2 about slowing a flow rather than terminating it. you said that the necessary functionality is already in rfc4495 its abstract says: In such cases, when the entire bandwidth allocated to a reservation is not required, the reservation need not be torn down. The solution described in this document allows endpoints to negotiate a new (lower) bandwidth that falls at or below the specified new bandwidth maximum allocated by the network. this is not the same function. this is about negotiating a new lower bandwi= dth. the functionality you need is for the PCN decision point to understand= in advance that there is a lower rate(s) to which the flow could be reduce= d if necessary (and both rates are inelastic) phil ________________________________________ From: T. Moncaster [tm444@hermes.cam.ac.uk] On Behalf Of Toby Moncaster [to= by.moncaster@cl.cam.ac.uk] Sent: 26 March 2012 15:26 To: Eardley,PL,Philip,DUB8 R Cc: karagian@cs.utwente.nl; pcn@ietf.org Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.t= xt (assumption 2 needed) I think the two most important points to remember are: 1) The IESG wants to close the PCN working group (and I for one think that = seems sensible) 2) This signalling document is meant to be one of the core building blocks = that can be bolted together to create a PCN-based admission system. As such= it should be written with as few assumptions as possible, and certainly sh= ould not be adding new concepts that were never in the original PCN charter= . more inline On 26 Mar 2012, at 15:13, wrote: > Assumption 1 > thanks for this. > note you don't need to change the definition of IEA - just use the defini= tion it already has (in PCN architecture) > > Assumption 2 > please can you point me the right bit of 4860 - about reducing the reserv= ed bandwidth of individual rsvp sessions. couldnt find it immediately. > whilst mathematically reducing one 100kb/s flow to 50kb/s is equal to ter= minating one of two 50kb/s flows - however, it requires the PCN decision no= de to understand that the current 100kb/s inelstic flow has another state w= here it can operate as a 50kb/s inelsatic flow. it seems to me this require= s significantly more complexity (state at decision point, decision making p= rocess, possibly signalling etc). > Again: termination is supposed to be a 'quick and dirty' function when so= mething has gone wrong. And all the documents have made that clear throughout (see the default abst= ract/intro text that is in nearly all the other documents now). > > Anyway, having slept on our chat at the social, I suggest a way forward i= s the following. > The draft should define signalling for the scope of PCN, as it's been ass= umed so far, ie don't mention these two assumptions. This enables PCN to be= finished. > These two extra assumptions are things that should be invisible to PCN - = it's just fine-grained information hiding within the policy and decision fu= nctions. For instance, we have never talked about a policy on how the decis= ion point should decide which flows to terminate (just how much it needs to= terminate) - it could choose randomly, it could choose the most recently e= stablished, it could choose the customers who are least important etc. I th= ink your 'flow slowing' is just another piece of policy that PCN doesn't ne= ed to talk about. +1 > (You could actually say the same thing about assumption 1) > > in passing, note that PCN is about PCN-flows. RFC5559 defines:- > o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node > admits (or terminates); the unit could be a single microflow (as > defined in [RFC2474]) or some identifiable collection of > microflows. > > since your draft needs to cover the relationship of the e2e signalling & = PCN, you need to explain the relationship between the e2e rsvp flows and pc= n-flows. i suggest you pick the easiest case, which i presume is a 1:1 mapp= ing. If you DO feel there is a need for more cases then that should go in as a (= very short) appendix. And remember, so long as this document is crafted correctly (using 2119 lan= guage carefully) it can include your assumptions without ever needing to st= ate them. Then if you are keen to have some future extension that looks at = flow-slowing you could put that in as an individual draft to TSWWG once PCN= is closed. Toby > > anyway, going back to my original comments - > you can delete the one about many-to-one mapping (now you're deleting ass= umption 1) > but i think the others still apply. > > thanks > phil > > ________________________________________ > From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@c= s.utwente.nl [karagian@cs.utwente.nl] > Sent: 25 March 2012 23:30 > To: pcn@ietf.org > Subject: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt= (assumption 2 needed) > > Hi all, > > In order to satisfy the comments received up to now I am willing to provi= de the following changes in the draft-ietf-tsvwg-rsvp-pcn. > > Proposed change: > Each ingress-egress pair supports only one ingress-egress aggregate. This= is identical to what any PCN specification specifies. > > The Aggregator (ingress), and DeAggregator (egress) however, can support = more than one RSVP generic aagregated reservation state belonging to the sa= me PHB, see RFC4860. The RSVP generic aggregated resevation states that are= maintained between the same pair of ingress-egress will use the PCN-BA, wh= ich is actually using the same PHB as these RSVP generic aggregated states. > > This means that all these RSVP generic aggregated reservation states will= use the same PCN admission control procedure, since they will use the same= PCN-BA in the PCN domain. > > Note that the definition that is given for IEA in draft-ietf-tsvwg-rsvp-p= cn-01.txt needs to be modifed to satisfy the above. Moreover, the last rul= e given in Section 3.1 that is associated with the admission control proced= ure needs to be modified to address the fact that all the RSVP generic aggr= egated resevation states will use the same PCN admission control procedure. > So assumption 1, listed in a previous email does not need to be supported= anymore! > > What is still remaining is the need of having assumption 2 supported: > > PCN-ingress-node should be able to reduce bandwidth of an individual flow= without terminating the flow > > Why?: flows will not be terminated unnecessary and at the same time the I= EA bandwidth is reduced to solve the severe congestion > How?: When for IEA supported by PCN-ingress-node incoming traffic needs t= o be reduced then: > based on a local policy and for same IEA, selects using the features prov= ided by RFC 4860 a number of inelastic e2e RSVP sessions (individual flows)= to be either terminated or reserved bandwidth of the inelastic e2e RSVP se= ssions (individual flows) is reduced. > > Note that due to the above changes, the specification provided in Section= 3.11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow termination needs = to be modified. In particular, it is needed to specify that for the situati= on that the Aggregator/ingress needs to terminate an amount of traffic asso= ciated tone PCN IEA, it must be able to know: (1) which RSVP generic aggreg= ated resevation states (associated with this PCN IEA) will be selected and = (2) which individual flows belonging to these selected sates will either b= e terminated or their bandwidth will be reduced. > > Note that using RFC 4495, the reduction of the bandwidth of an individual= flow at the PCN-ingress-node can be done immediately. > So from the point of view of the delay in decreasing the total amount of = bandwidth for an PCN IEA, can be observed that: > o) the situation where a PCN-ingress-node reduces the bandwidth of a 100k= b/s flow to 50kb/s (belonging to one aggregate) is the same as the situatio= n that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows = belong to the same aggregate. > In other words, the time it takes to terminate a flow is equal (under cer= tain bounds) to the time it takes to reduce the bandwidth of a flow. > > > Best regards, > Georgios > _______________________________________________ > 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 karagian@cs.utwente.nl Tue Mar 27 08:27:58 2012 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 0837021E80A6; Tue, 27 Mar 2012 08:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.252 X-Spam-Level: X-Spam-Status: No, score=-0.252 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu-U19J4i8uT; Tue, 27 Mar 2012 08:27:56 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id DA23621E8083; Tue, 27 Mar 2012 08:27:55 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 27 Mar 2012 17:28:01 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Tue, 27 Mar 2012 17:27:54 +0200 From: To: , , Thread-Topic: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 Thread-Index: AQHNC+6d9MhH5pYYBkKeQn1PQISJ4pZ+QMi0 Date: Tue, 27 Mar 2012 15:27:53 +0000 Message-ID: References: <9510D26531EF184D9017DF24659BB87F331DE0C41E@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C41E@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.202.83.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 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, 27 Mar 2012 15:27:58 -0000 Hi Phil, This is a good question! The answer is the following: By using RFC4860 you could actually deploy both scenarios: 1) Use RFC4860 and configure it to only support only one to one mapping bet= ween one RSVP generic aggregated state to one PCN IEA (so only one RSVP agg= regated state is using one PHB). In this case exactly the same functionalit= y is achieved as when using the Aggregated RSVP (RFC3175). This is the basi= c functionality that RFC4860 can provide which is the functionality support= ed by RFC3175. 2) Use RFC4860 and configure it to support more than one to one mapping bet= ween more than one RSVP generic aggregated state to one PCN IEA (so more th= an one RSVP aggregated states are using one PHB). . In this way the additio= nal features of RFC4860, including bandwidth reduction of the individual fl= ows, can be supported. Best regards, Georgios _______ _________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: dinsdag 27 maart 2012 9:52 Aan: Karagiannis, G. (EWI); pcn@ietf.org; tsvwg@ietf.org Onderwerp: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 the question I was trying to raise at the mike earlier is this:- at the moment the draft is written as an extension to generic aggregated rs= vp. Is it possible to write an extension that works as a PCN extension for = either /both aggregated rsvp or generic aggregated rsvp? that would widen i= ts applicability. (Unless in practice only generic aggregated is used and aggregated rsvp isn= 't used??) may well be that this is a stupid suggestion! thanks phil= From philip.eardley@bt.com Tue Mar 27 08:55:26 2012 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 A8D8721E825F; Tue, 27 Mar 2012 08:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYUEkhL62ERF; Tue, 27 Mar 2012 08:55:26 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3251A21E8250; Tue, 27 Mar 2012 08:55:19 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Mar 2012 16:55:18 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.102]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Tue, 27 Mar 2012 16:55:17 +0100 From: To: , , Date: Tue, 27 Mar 2012 16:52:06 +0100 Thread-Topic: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 Thread-Index: AQHNC+6d9MhH5pYYBkKeQn1PQISJ4pZ+QMi0gAAKef0= Message-ID: <9510D26531EF184D9017DF24659BB87F331DE0C423@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F331DE0C41E@EMV65-UKRD.domain1.systemhost.net>, In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 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, 27 Mar 2012 15:55:27 -0000 your point 1) says that rfc4860 can operate in a basic mode where it provid= es the same as 3175. actually my question was whether you can define a PCN extension that can be= applied to both 3175 and 4860. that would increase the applicability. ________________________________________ From: karagian@cs.utwente.nl [karagian@cs.utwente.nl] Sent: 27 March 2012 16:27 To: Eardley,PL,Philip,DUB8 R; pcn@ietf.org; tsvwg@ietf.org Subject: RE: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 Hi Phil, This is a good question! The answer is the following: By using RFC4860 you could actually deploy both scenarios: 1) Use RFC4860 and configure it to only support only one to one mapping bet= ween one RSVP generic aggregated state to one PCN IEA (so only one RSVP agg= regated state is using one PHB). In this case exactly the same functionalit= y is achieved as when using the Aggregated RSVP (RFC3175). This is the basi= c functionality that RFC4860 can provide which is the functionality support= ed by RFC3175. 2) Use RFC4860 and configure it to support more than one to one mapping bet= ween more than one RSVP generic aggregated state to one PCN IEA (so more th= an one RSVP aggregated states are using one PHB). . In this way the additio= nal features of RFC4860, including bandwidth reduction of the individual fl= ows, can be supported. Best regards, Georgios _______ _________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: dinsdag 27 maart 2012 9:52 Aan: Karagiannis, G. (EWI); pcn@ietf.org; tsvwg@ietf.org Onderwerp: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 the question I was trying to raise at the mike earlier is this:- at the moment the draft is written as an extension to generic aggregated rs= vp. Is it possible to write an extension that works as a PCN extension for = either /both aggregated rsvp or generic aggregated rsvp? that would widen i= ts applicability. (Unless in practice only generic aggregated is used and aggregated rsvp isn= 't used??) may well be that this is a stupid suggestion! thanks phil= From karagian@cs.utwente.nl Tue Mar 27 09:20:46 2012 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 ED78021F89C7; Tue, 27 Mar 2012 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.031 X-Spam-Level: X-Spam-Status: No, score=0.031 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaC2-q6NWKe2; Tue, 27 Mar 2012 09:20:46 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 011BF21F89BB; Tue, 27 Mar 2012 09:20:45 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 27 Mar 2012 18:20:51 +0200 Received: from EXMBX04.ad.utwente.nl ([169.254.4.113]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Tue, 27 Mar 2012 18:20:44 +0200 From: To: , , Thread-Topic: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 Thread-Index: AQHNC+6d9MhH5pYYBkKeQn1PQISJ4pZ+QMi0gAAKef2AAATEMg== Date: Tue, 27 Mar 2012 16:20:43 +0000 Message-ID: References: <9510D26531EF184D9017DF24659BB87F331DE0C41E@EMV65-UKRD.domain1.systemhost.net>, , <9510D26531EF184D9017DF24659BB87F331DE0C423@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F331DE0C423@EMV65-UKRD.domain1.systemhost.net> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.202.83.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 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, 27 Mar 2012 16:20:47 -0000 Hi Phil, I am not sure, but I expect that in this case the specification of the PCN = extension will become somehow complicated, since it will have to include a = clear description of when some features are using RFC3175 and when the same= features are using RFC4860. I would like to continue using as the basis fo= r this PCN extension, the RFC4860. If this is work is completed and if the= re is a need, we could discuss then what the next steps will be! Best regards, Georgios ________________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: dinsdag 27 maart 2012 17:52 Aan: Karagiannis, G. (EWI); pcn@ietf.org; tsvwg@ietf.org Onderwerp: RE: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 your point 1) says that rfc4860 can operate in a basic mode where it provid= es the same as 3175. actually my question was whether you can define a PCN extension that can be= applied to both 3175 and 4860. that would increase the applicability. ________________________________________ From: karagian@cs.utwente.nl [karagian@cs.utwente.nl] Sent: 27 March 2012 16:27 To: Eardley,PL,Philip,DUB8 R; pcn@ietf.org; tsvwg@ietf.org Subject: RE: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 Hi Phil, This is a good question! The answer is the following: By using RFC4860 you could actually deploy both scenarios: 1) Use RFC4860 and configure it to only support only one to one mapping bet= ween one RSVP generic aggregated state to one PCN IEA (so only one RSVP agg= regated state is using one PHB). In this case exactly the same functionalit= y is achieved as when using the Aggregated RSVP (RFC3175). This is the basi= c functionality that RFC4860 can provide which is the functionality support= ed by RFC3175. 2) Use RFC4860 and configure it to support more than one to one mapping bet= ween more than one RSVP generic aggregated state to one PCN IEA (so more th= an one RSVP aggregated states are using one PHB). . In this way the additio= nal features of RFC4860, including bandwidth reduction of the individual fl= ows, can be supported. Best regards, Georgios _______ _________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: dinsdag 27 maart 2012 9:52 Aan: Karagiannis, G. (EWI); pcn@ietf.org; tsvwg@ietf.org Onderwerp: comment at mike on draft-ietf-tsvwg-rsvp-pcn-01 the question I was trying to raise at the mike earlier is this:- at the moment the draft is written as an extension to generic aggregated rs= vp. Is it possible to write an extension that works as a PCN extension for = either /both aggregated rsvp or generic aggregated rsvp? that would widen i= ts applicability. (Unless in practice only generic aggregated is used and aggregated rsvp isn= 't used??) may well be that this is a stupid suggestion! thanks phil= From philip.eardley@bt.com Wed Mar 28 00:55:47 2012 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 55A3621F8925; Wed, 28 Mar 2012 00:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.155 X-Spam-Level: X-Spam-Status: No, score=-103.155 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 386eZJjWFA+q; Wed, 28 Mar 2012 00:55:45 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 2725F21F8923; Wed, 28 Mar 2012 00:55:45 -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.213.0; Wed, 28 Mar 2012 08:55:43 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.102]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Wed, 28 Mar 2012 08:55:43 +0100 From: To: , Date: Wed, 28 Mar 2012 08:55:43 +0100 Thread-Topic: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) Thread-Index: AQHNCtRROgmgTspi7EGWYEs7DMvJYpZ8lnFp///rUwCAAR+pAIAAn0VwgAAU0BU= Message-ID: <9510D26531EF184D9017DF24659BB87F331DE0C424@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F331DE0C417@EMV65-UKRD.domain1.systemhost.net>, <46B08E2E-E8E2-474F-8917-B4006E5F25C5@cl.cam.ac.uk>, <9510D26531EF184D9017DF24659BB87F331DE0C41C@EMV65-UKRD.domain1.systemhost.net>, In-Reply-To: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org, tsvwg@ietf.org Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed) 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, 28 Mar 2012 07:55:47 -0000 [adding tsvwg mailing list] ok, so RFC4495 says that during re-reservation request period no packets tr= averse the aggregate until it is re-established.=20 to me, from a PCN perspective, this sounds like the PCN-flow has been termi= nated and then there is admission control for a new request best wishes, phil ________________________________________ From: karagian@cs.utwente.nl [karagian@cs.utwente.nl] Sent: 27 March 2012 16:13 To: Eardley,PL,Philip,DUB8 R; toby.moncaster@cl.cam.ac.uk Cc: pcn@ietf.org Subject: RE: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.t= xt (assumption 2 needed) Hi Phil, Section 2 of RFC 4495 explains that during the re-reservation request perio= d of time no packets will traverse the "affected"" aggregate (which contai= ns the individual flows whose bandwidth needs to be reduced), until it is r= eestablished. So during that time no packets (belonging to the individual f= lows whose bandwidth needs to be reduced) will traverse the PCN domain unti= l it is reestablished. See the text copied from Section2 of RFC 4495. --// -- This specification makes it possible for the ResvErr message to indicate that 20 units are still available for a reservation to remain up (the interface's 100 units maximum minus Flow 2's 80 units). The reservation initiating node (router or end-system) for Flow 1 has the opportunity to renegotiate (via call signaling) for acceptable parameters within the existing and available bandwidth for the flow (for example, it may decide to change to using a codec such as G.729) --//-- During the re-reservation request period of time no packets will traverse the aggregate until it is reestablished. - reduces the chances that the reestablishment of the aggregate will reserve an inefficient amount of bandwidth, causing the likely preemption of more individual flows at the aggregator than would be necessary had the aggregator had more information (that RSVP does not provide at this time) -//=3D=3D Best regards, Georgios ________________________________________ Van: philip.eardley@bt.com [philip.eardley@bt.com] Verzonden: dinsdag 27 maart 2012 9:36 Aan: toby.moncaster@cl.cam.ac.uk CC: Karagiannis, G. (EWI); pcn@ietf.org Onderwerp: RE: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01= .txt (assumption 2 needed) Georgios on your assumption 2 about slowing a flow rather than terminating it. you said that the necessary functionality is already in rfc4495 its abstract says: In such cases, when the entire bandwidth allocated to a reservation is not required, the reservation need not be torn down. The solution described in this document allows endpoints to negotiate a new (lower) bandwidth that falls at or below the specified new bandwidth maximum allocated by the network. this is not the same function. this is about negotiating a new lower bandwi= dth. the functionality you need is for the PCN decision point to understand= in advance that there is a lower rate(s) to which the flow could be reduce= d if necessary (and both rates are inelastic) phil ________________________________________ From: T. Moncaster [tm444@hermes.cam.ac.uk] On Behalf Of Toby Moncaster [to= by.moncaster@cl.cam.ac.uk] Sent: 26 March 2012 15:26 To: Eardley,PL,Philip,DUB8 R Cc: karagian@cs.utwente.nl; pcn@ietf.org Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.t= xt (assumption 2 needed) I think the two most important points to remember are: 1) The IESG wants to close the PCN working group (and I for one think that = seems sensible) 2) This signalling document is meant to be one of the core building blocks = that can be bolted together to create a PCN-based admission system. As such= it should be written with as few assumptions as possible, and certainly sh= ould not be adding new concepts that were never in the original PCN charter= . more inline On 26 Mar 2012, at 15:13, wrote: > Assumption 1 > thanks for this. > note you don't need to change the definition of IEA - just use the defini= tion it already has (in PCN architecture) > > Assumption 2 > please can you point me the right bit of 4860 - about reducing the reserv= ed bandwidth of individual rsvp sessions. couldnt find it immediately. > whilst mathematically reducing one 100kb/s flow to 50kb/s is equal to ter= minating one of two 50kb/s flows - however, it requires the PCN decision no= de to understand that the current 100kb/s inelstic flow has another state w= here it can operate as a 50kb/s inelsatic flow. it seems to me this require= s significantly more complexity (state at decision point, decision making p= rocess, possibly signalling etc). > Again: termination is supposed to be a 'quick and dirty' function when so= mething has gone wrong. And all the documents have made that clear throughout (see the default abst= ract/intro text that is in nearly all the other documents now). > > Anyway, having slept on our chat at the social, I suggest a way forward i= s the following. > The draft should define signalling for the scope of PCN, as it's been ass= umed so far, ie don't mention these two assumptions. This enables PCN to be= finished. > These two extra assumptions are things that should be invisible to PCN - = it's just fine-grained information hiding within the policy and decision fu= nctions. For instance, we have never talked about a policy on how the decis= ion point should decide which flows to terminate (just how much it needs to= terminate) - it could choose randomly, it could choose the most recently e= stablished, it could choose the customers who are least important etc. I th= ink your 'flow slowing' is just another piece of policy that PCN doesn't ne= ed to talk about. +1 > (You could actually say the same thing about assumption 1) > > in passing, note that PCN is about PCN-flows. RFC5559 defines:- > o PCN-flow: the unit of PCN-traffic that the PCN-boundary-node > admits (or terminates); the unit could be a single microflow (as > defined in [RFC2474]) or some identifiable collection of > microflows. > > since your draft needs to cover the relationship of the e2e signalling & = PCN, you need to explain the relationship between the e2e rsvp flows and pc= n-flows. i suggest you pick the easiest case, which i presume is a 1:1 mapp= ing. If you DO feel there is a need for more cases then that should go in as a (= very short) appendix. And remember, so long as this document is crafted correctly (using 2119 lan= guage carefully) it can include your assumptions without ever needing to st= ate them. Then if you are keen to have some future extension that looks at = flow-slowing you could put that in as an individual draft to TSWWG once PCN= is closed. Toby > > anyway, going back to my original comments - > you can delete the one about many-to-one mapping (now you're deleting ass= umption 1) > but i think the others still apply. > > thanks > phil > > ________________________________________ > From: pcn-bounces@ietf.org [pcn-bounces@ietf.org] On Behalf Of karagian@c= s.utwente.nl [karagian@cs.utwente.nl] > Sent: 25 March 2012 23:30 > To: pcn@ietf.org > Subject: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt= (assumption 2 needed) > > Hi all, > > In order to satisfy the comments received up to now I am willing to provi= de the following changes in the draft-ietf-tsvwg-rsvp-pcn. > > Proposed change: > Each ingress-egress pair supports only one ingress-egress aggregate. This= is identical to what any PCN specification specifies. > > The Aggregator (ingress), and DeAggregator (egress) however, can support = more than one RSVP generic aagregated reservation state belonging to the sa= me PHB, see RFC4860. The RSVP generic aggregated resevation states that are= maintained between the same pair of ingress-egress will use the PCN-BA, wh= ich is actually using the same PHB as these RSVP generic aggregated states. > > This means that all these RSVP generic aggregated reservation states will= use the same PCN admission control procedure, since they will use the same= PCN-BA in the PCN domain. > > Note that the definition that is given for IEA in draft-ietf-tsvwg-rsvp-p= cn-01.txt needs to be modifed to satisfy the above. Moreover, the last rul= e given in Section 3.1 that is associated with the admission control proced= ure needs to be modified to address the fact that all the RSVP generic aggr= egated resevation states will use the same PCN admission control procedure. > So assumption 1, listed in a previous email does not need to be supported= anymore! > > What is still remaining is the need of having assumption 2 supported: > > PCN-ingress-node should be able to reduce bandwidth of an individual flow= without terminating the flow > > Why?: flows will not be terminated unnecessary and at the same time the I= EA bandwidth is reduced to solve the severe congestion > How?: When for IEA supported by PCN-ingress-node incoming traffic needs t= o be reduced then: > based on a local policy and for same IEA, selects using the features prov= ided by RFC 4860 a number of inelastic e2e RSVP sessions (individual flows)= to be either terminated or reserved bandwidth of the inelastic e2e RSVP se= ssions (individual flows) is reduced. > > Note that due to the above changes, the specification provided in Section= 3.11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow termination needs = to be modified. In particular, it is needed to specify that for the situati= on that the Aggregator/ingress needs to terminate an amount of traffic asso= ciated tone PCN IEA, it must be able to know: (1) which RSVP generic aggreg= ated resevation states (associated with this PCN IEA) will be selected and = (2) which individual flows belonging to these selected sates will either b= e terminated or their bandwidth will be reduced. > > Note that using RFC 4495, the reduction of the bandwidth of an individual= flow at the PCN-ingress-node can be done immediately. > So from the point of view of the delay in decreasing the total amount of = bandwidth for an PCN IEA, can be observed that: > o) the situation where a PCN-ingress-node reduces the bandwidth of a 100k= b/s flow to 50kb/s (belonging to one aggregate) is the same as the situatio= n that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows = belong to the same aggregate. > In other words, the time it takes to terminate a flow is equal (under cer= tain bounds) to the time it takes to reduce the bandwidth of a flow. > > > Best regards, > Georgios > _______________________________________________ > 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=