From tom.taylor.stds@gmail.com Thu Jan 5 08:03: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 DFE7D21F85CC for ; Thu, 5 Jan 2012 08:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 foIRHOKVGFMI for ; Thu, 5 Jan 2012 08:03:05 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C03721F857A for ; Thu, 5 Jan 2012 08:03:05 -0800 (PST) Received: by yhjj72 with SMTP id j72so210501yhj.31 for ; Thu, 05 Jan 2012 08:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Fsq5a4ZcKLrqIr+45tzjPm0I8/ucT7tKpKXbHILTqAw=; b=mql8NLD+jSMNMbCjrUYwBZBCPw+7Mfmryi7J3CA08cvAtiOEntot7foFh/D9NmGYdk 6hLbpgeupFjE7ftl2ftfLG9cgSSqDUOttAb082qWdBjC2DXj1Y358uF8Fi+yGWm1c5s6 iqZnIzSeY6x7BqY+fILOJhzumeabHshjQIyjg= Received: by 10.236.175.198 with SMTP id z46mr2376193yhl.31.1325779384983; Thu, 05 Jan 2012 08:03:04 -0800 (PST) Received: from [192.168.2.17] (bas4-ottawa10-1088918650.dsl.bell.ca. [64.231.148.122]) by mx.google.com with ESMTPS id n24sm82355586yhj.13.2012.01.05.08.03.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 Jan 2012 08:03:04 -0800 (PST) Message-ID: <4F05C9B6.3060700@gmail.com> Date: Thu, 05 Jan 2012 11:03:02 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] Classification of packets by ingress-egress-aggregate 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, 05 Jan 2012 16:03:06 -0000 As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has maintained that in the absence of tunneling or the use of the aggregate RSVP method for determining ingress-egress-aggregate classifiers, routing data are inadequate for the purpose. He points out the case where an upstream domain uses ECMP, so that the same microflow could enter the PCN domain through multiple ingress nodes and the egress node wouldn't be able to tell where it came from. It appears, then, that the edge behaviour drafts will have to restrict their applicability to the cases where PCN paqackets are tunneled or where the aggregate RSVP method is used to create classifiers. (Even in the latter case, I'm not sure how Joel's upstream ECMP case is countered.) Does anyone have a better idea here? Tom Taylor From tm444@hermes.cam.ac.uk Thu Jan 5 08:30: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 BA35B21F8778 for ; Thu, 5 Jan 2012 08:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 WKBblS9mecjd for ; Thu, 5 Jan 2012 08:30:45 -0800 (PST) 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 2A66321F877D for ; Thu, 5 Jan 2012 08:30:45 -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]:64059) 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 1RiqDC-0000hL-Yr (Exim 4.72) (return-path ); Thu, 05 Jan 2012 16:30:42 +0000 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Toby Moncaster In-Reply-To: <4F05C9B6.3060700@gmail.com> Date: Thu, 5 Jan 2012 16:30:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> References: <4F05C9B6.3060700@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1251.1) Sender: "T. Moncaster" X-Mailman-Approved-At: Thu, 05 Jan 2012 08:35:03 -0800 Cc: pcn Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate 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, 05 Jan 2012 16:30:45 -0000 I think we should put it the other way round. In networks that are using = ECMP then PCN traffic has to be tunnelled or use suitable RSVP. That = sort of matches with what it says in RFC5559 about tunnelling. I'm no expert, but presumably RSVP must be able to cope with ECMP = somehow? Otherwise the RESV message wouldn't be sure to return down the = same route that the PATH message took? Toby On 5 Jan 2012, at 16:03, Tom Taylor wrote: > As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has = maintained that in the absence of tunneling or the use of the aggregate = RSVP method for determining ingress-egress-aggregate classifiers, = routing data are inadequate for the purpose. He points out the case = where an upstream domain uses ECMP, so that the same microflow could = enter the PCN domain through multiple ingress nodes and the egress node = wouldn't be able to tell where it came from. >=20 > It appears, then, that the edge behaviour drafts will have to restrict = their applicability to the cases where PCN paqackets are tunneled or = where the aggregate RSVP method is used to create classifiers. (Even in = the latter case, I'm not sure how Joel's upstream ECMP case is = countered.) >=20 > Does anyone have a better idea here? >=20 > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From slblake@petri-meat.com Thu Jan 5 08:39: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 E392121F8805 for ; Thu, 5 Jan 2012 08:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 ENoSV4M+HrSj for ; Thu, 5 Jan 2012 08:39:22 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9FE21F8804 for ; Thu, 5 Jan 2012 08:39:22 -0800 (PST) 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:In-Reply-To:References:Message-ID:X-Sender:User-Agent; b=2FmKgNMJYVt3I4rr+K5uJiQtM2SCe0wNkSTyZ5w2dybRym0XpmsmtZXS7XmCa110jz9hrreGfCFzIFUS6qaUrZYmbYE2ODMZNEDnFqHRAhgia/u756v8ATShZ40asOJI; Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1RiqLW-0005uN-IM; Thu, 05 Jan 2012 11:39:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Jan 2012 12:39:18 -0400 From: Steven Blake To: In-Reply-To: <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> References: <4F05C9B6.3060700@gmail.com> <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> Message-ID: <7bb88e681187139268d978336065d7f0@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: Re: [PCN] Classification of packets by ingress-egress-aggregate 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, 05 Jan 2012 16:39:23 -0000 On 05.01.2012 12:30, Toby Moncaster wrote: > I think we should put it the other way round. In networks that are > using ECMP then PCN traffic has to be tunnelled or use suitable RSVP. > That sort of matches with what it says in RFC5559 about tunnelling. I thought we had all reached this conclusion about 3 years ago... > I'm no expert, but presumably RSVP must be able to cope with ECMP > somehow? Otherwise the RESV message wouldn't be sure to return down > the same route that the PATH message took? My recollection is that in classic RSVP, RESV messages are forwarded upstream based on intermediate node PATH state, not via normal forwarding. But in a PCN network we would only be interested in some form of aggregated RSVP, where PATH/RESV state is only installed on the domain boundaries (otherwise PCN would be kind of pointless). Regards, // Steve From jmpolk@cisco.com Thu Jan 5 12:32: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 E78B421F88C8 for ; Thu, 5 Jan 2012 12:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 qHr-WF33CL2d for ; Thu, 5 Jan 2012 12:32:05 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 5A93421F888D for ; Thu, 5 Jan 2012 12:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1110; q=dns/txt; s=iport; t=1325795525; x=1327005125; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=zVjXN6F0gefIlHdbc9FQoLC3toYL4g/4v4EFUz9Ebbc=; b=hUzuv7x5LB9J0VQVp5aMzt0fKG7VXDzKxvkk49n5nACoSvCB9xen0QAG kicaTGmL0lWoULukgiZSM3Yqx3huNtwHdSpwAfPgvLR/77GDJ+tnww1l3 tnw+b+sQd6fNuaeM0FQDH6N4cBkcLJGOnvh8eFFcavAsA31vo9F5ZAlW1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAHwIBk+rRDoI/2dsb2JhbABCggWqeYEFgXIBAQEEAQEBDwElAjEDGwcEDgoeEBkOMAYBEiKHYJgBAZ4fBIwRBIg5nyE X-IronPort-AV: E=Sophos;i="4.71,464,1320624000"; d="scan'208";a="24025854" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 05 Jan 2012 20:32:03 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q05KW2Vn022642; Thu, 5 Jan 2012 20:32:03 GMT Message-Id: <201201052032.q05KW2Vn022642@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jan 2012 14:32:03 -0600 To: Steven Blake , From: "James M. Polk" In-Reply-To: <7bb88e681187139268d978336065d7f0@petri-meat.com> References: <4F05C9B6.3060700@gmail.com> <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> <7bb88e681187139268d978336065d7f0@petri-meat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate 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, 05 Jan 2012 20:32:06 -0000 At 10:39 AM 1/5/2012, Steven Blake wrote: >On 05.01.2012 12:30, Toby Moncaster wrote: > >>I think we should put it the other way round. In networks that are >>using ECMP then PCN traffic has to be tunnelled or use suitable RSVP. >>That sort of matches with what it says in RFC5559 about tunnelling. > >I thought we had all reached this conclusion about 3 years ago... > >>I'm no expert, but presumably RSVP must be able to cope with ECMP >>somehow? Otherwise the RESV message wouldn't be sure to return down >>the same route that the PATH message took? > >My recollection is that in classic RSVP, RESV messages are forwarded >upstream based on intermediate node PATH state, not via normal forwarding. the above is a fact. James >But in a PCN network we would only be interested in some form of >aggregated RSVP, where PATH/RESV state is only installed on the >domain boundaries (otherwise PCN would be kind of pointless). > > >Regards, > >// Steve >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Fri Jan 6 00:14: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 8F6D511E80B3 for ; Fri, 6 Jan 2012 00:14:05 -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 3F8VLBfiK1yG for ; Fri, 6 Jan 2012 00:14:05 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id BAA8011E8096 for ; Fri, 6 Jan 2012 00:14:04 -0800 (PST) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 06 Jan 2012 09:13:42 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.229]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 6 Jan 2012 09:13:42 +0100 From: To: Date: Fri, 6 Jan 2012 09:13:40 +0100 Thread-Topic: [PCN] Classification of packets by ingress-egress-aggregate Thread-Index: AczLw4uP9P31at1xROmIWQ8pcdEQwAAhb2tQ Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13130967ED@HE111648.emea1.cds.t-internal.com> References: <4F05C9B6.3060700@gmail.com> In-Reply-To: <4F05C9B6.3060700@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] Classification of packets by ingress-egress-aggregate 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, 06 Jan 2012 08:14:05 -0000 Hi Tom, some kind of tunnel which is avoiding ECMP routing is the only solution coming to my mind. L2TPv3 or Ethernet PWs (without Flow Aware Transport) are some potential solutions. We had statements saying that the WG doesn't deal with the issue in earlier drafts. That's not good, it's honest however. RSVP tunnels didn't support ECMP some years ago. But statements on carrier class RSVP features should be made from someone who knows the current deployments. A fair question to answer may be, whether ECMP routing is a commodity. If the reply is "yes", PCN based admission control only makes sense if it is able to deal with ECMP. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: Thursday, January 05, 2012 5:03 PM To: pcn Subject: [PCN] Classification of packets by ingress-egress-aggregate As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has maintained that in the absence of tunneling or the use of the aggregate RSVP method for determining ingress-egress-aggregate classifiers, routing data are inadequate for the purpose. He points out the case where an upstream domain uses ECMP, so that the same microflow could enter the PCN domain through multiple ingress nodes and the egress node wouldn't be able to tell where it came from. It appears, then, that the edge behaviour drafts will have to restrict their applicability to the cases where PCN paqackets are tunneled or where the aggregate RSVP method is used to create classifiers. (Even in the latter case, I'm not sure how Joel's upstream ECMP case is countered.) Does anyone have a better idea here? Tom Taylor _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From tom.taylor.stds@gmail.com Fri Jan 6 08:07: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 85DD021F88B8 for ; Fri, 6 Jan 2012 08:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6SXfjiBuHJCt for ; Fri, 6 Jan 2012 08:07:15 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C2D1121F8826 for ; Fri, 6 Jan 2012 08:07:15 -0800 (PST) Received: by qcsf15 with SMTP id f15so1114973qcs.31 for ; Fri, 06 Jan 2012 08:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=436tTGDFpfKTlogkzqKbFO7HL/FHEZEKK54cZkHZFvQ=; b=e0aybIv63ezbKY0WOg1++R+8DF3LmC9S25ssFlH8MQuTty41V8xh9uGaRicB4Ec4V4 6rbRQ7hpjy/HWd5WZ7boEGl1L+5taG0orYZfc8In1RzNzegrqPRASsDFJYjwBR+hagOa tnZioUNAojveu0EKK97xqCgtBiZl+ASQGxT5s= Received: by 10.229.105.195 with SMTP id u3mr2347420qco.118.1325866035310; Fri, 06 Jan 2012 08:07:15 -0800 (PST) Received: from [192.168.2.17] (bas4-ottawa10-1088918650.dsl.bell.ca. [64.231.148.122]) by mx.google.com with ESMTPS id t4sm44508084qal.17.2012.01.06.08.07.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 08:07:14 -0800 (PST) Message-ID: <4F071C32.3000702@gmail.com> Date: Fri, 06 Jan 2012 11:07:14 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <4F05C9B6.3060700@gmail.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13130967ED@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13130967ED@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] Classification of packets by ingress-egress-aggregate 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, 06 Jan 2012 16:07:16 -0000 On your final point: Joel said that ECMP is a standard part of the operator's toolkit these days, so we do have a problem. I could see rethinking the theory of PCN to allow for ECMP, but it means taking a long step backwards in the process. On 06/01/2012 3:13 AM, Ruediger.Geib@telekom.de wrote: > Hi Tom, > > some kind of tunnel which is avoiding ECMP routing is the only > solution coming to my mind. L2TPv3 or Ethernet PWs (without > Flow Aware Transport) are some potential solutions. > > We had statements saying that the WG doesn't deal with the issue > in earlier drafts. That's not good, it's honest however. > > RSVP tunnels didn't support ECMP some years ago. But statements > on carrier class RSVP features should be made from someone who > knows the current deployments. > > A fair question to answer may be, whether ECMP routing is a > commodity. If the reply is "yes", PCN based admission control > only makes sense if it is able to deal with ECMP. > > Regards, > > Ruediger > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Taylor > Sent: Thursday, January 05, 2012 5:03 PM > To: pcn > Subject: [PCN] Classification of packets by ingress-egress-aggregate > > As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has > maintained that in the absence of tunneling or the use of the aggregate > RSVP method for determining ingress-egress-aggregate classifiers, > routing data are inadequate for the purpose. He points out the case > where an upstream domain uses ECMP, so that the same microflow could > enter the PCN domain through multiple ingress nodes and the egress node > wouldn't be able to tell where it came from. > > It appears, then, that the edge behaviour drafts will have to restrict > their applicability to the cases where PCN paqackets are tunneled or > where the aggregate RSVP method is used to create classifiers. (Even in > the latter case, I'm not sure how Joel's upstream ECMP case is countered.) > > Does anyone have a better idea here? > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From karagian@cs.utwente.nl Fri Jan 6 09:57: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 DF30F21F897F for ; Fri, 6 Jan 2012 09:57:55 -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 Z2lX7SpnWznZ for ; Fri, 6 Jan 2012 09:57:55 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id E51D521F87C9 for ; Fri, 6 Jan 2012 09:57:54 -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.323.3; Fri, 6 Jan 2012 18:57:56 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.33]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0323.003; Fri, 6 Jan 2012 18:57:52 +0100 From: To: , Thread-Topic: [PCN] Classification of packets by ingress-egress-aggregate Thread-Index: AQHMy8OKFJn4vXD54UuKbr7EyCEXwpX95nKAgAG4xi0= Date: Fri, 6 Jan 2012 17:57:51 +0000 Message-ID: References: <4F05C9B6.3060700@gmail.com>, <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> In-Reply-To: <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.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] Classification of packets by ingress-egress-aggregate 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, 06 Jan 2012 17:57:56 -0000 Dear all I agree with Toby. Some solutions are listed in the below draft (Section 5= .1): http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture-04=20 I think that the solution that will work in PCN is tunelling.=20 In particualr, in networks that are using ECMP then PCN traffic need to be = tunnelled. In this case the destination address (and so on) seen by the EC= MP algorithm is that of the PCN-egress-node, so all flows follow the same = path.=20 Effectively ECMP is turned off. As a compromise, to try to retain some of t= he benefits of ECMP, there could be several tunnels, each following a diffe= rent ECMP path, with flows randomly assigned to different tunnels. =20 Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Toby Moncaster [tob= y.moncaster@cl.cam.ac.uk] Verzonden: donderdag 5 januari 2012 17:30 Aan: Tom Taylor CC: pcn Onderwerp: Re: [PCN] Classification of packets by ingress-egress-aggregate I think we should put it the other way round. In networks that are using EC= MP then PCN traffic has to be tunnelled or use suitable RSVP. That sort of = matches with what it says in RFC5559 about tunnelling. I'm no expert, but presumably RSVP must be able to cope with ECMP somehow? = Otherwise the RESV message wouldn't be sure to return down the same route t= hat the PATH message took? Toby On 5 Jan 2012, at 16:03, Tom Taylor wrote: > As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has mai= ntained that in the absence of tunneling or the use of the aggregate RSVP m= ethod for determining ingress-egress-aggregate classifiers, routing data ar= e inadequate for the purpose. He points out the case where an upstream doma= in uses ECMP, so that the same microflow could enter the PCN domain through= multiple ingress nodes and the egress node wouldn't be able to tell where = it came from. > > It appears, then, that the edge behaviour drafts will have to restrict th= eir applicability to the cases where PCN paqackets are tunneled or where th= e aggregate RSVP method is used to create classifiers. (Even in the latter = case, I'm not sure how Joel's upstream ECMP case is countered.) > > Does anyone have a better idea here? > > Tom Taylor > _______________________________________________ > 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 Mon Jan 9 23: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 BB83E21F87B3 for ; Mon, 9 Jan 2012 23:48:37 -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 O8pZCsqj5cjo for ; Mon, 9 Jan 2012 23:48:37 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id BB44B21F87FA for ; Mon, 9 Jan 2012 23:48:36 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jan 2012 08:48:34 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.229]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 10 Jan 2012 08:48:33 +0100 From: To: Date: Tue, 10 Jan 2012 08:48:32 +0100 Thread-Topic: [PCN] Classification of packets by ingress-egress-aggregate Thread-Index: AQHMy8OKFJn4vXD54UuKbr7EyCEXwpX95nKAgAG4xi2ABHbHYA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13131D63AE@HE111648.emea1.cds.t-internal.com> References: <4F05C9B6.3060700@gmail.com>, <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> 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] Classification of packets by ingress-egress-aggregate 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, 10 Jan 2012 07:48:37 -0000 Hi Georgios, a statement that tunnels avoiding flow based ECMP routing is the way to go, I agree. I suggest to formulate it that way, as there are tunnels which still support flow based ECMP routing (like IP over LDP based MPLS or Flow aware Transport). We shouldn't mention multiple tunnels as a solution enabling ECMP usage with PCN, if this results in an expectation that we have to provide details how that works. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of karag= ian@cs.utwente.nl Sent: Friday, January 06, 2012 6:58 PM To: toby.moncaster@cl.cam.ac.uk; tom.taylor.stds@gmail.com Cc: pcn@ietf.org Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate Dear all I agree with Toby. Some solutions are listed in the below draft (Section 5= .1): http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture-04 I think that the solution that will work in PCN is tunelling. In particualr, in networks that are using ECMP then PCN traffic need to be = tunnelled. In this case the destination address (and so on) seen by the EC= MP algorithm is that of the PCN-egress-node, so all flows follow the same = path. Effectively ECMP is turned off. As a compromise, to try to retain some of t= he benefits of ECMP, there could be several tunnels, each following a diffe= rent ECMP path, with flows randomly assigned to different tunnels. Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Toby Moncaster [tob= y.moncaster@cl.cam.ac.uk] Verzonden: donderdag 5 januari 2012 17:30 Aan: Tom Taylor CC: pcn Onderwerp: Re: [PCN] Classification of packets by ingress-egress-aggregate I think we should put it the other way round. In networks that are using EC= MP then PCN traffic has to be tunnelled or use suitable RSVP. That sort of = matches with what it says in RFC5559 about tunnelling. I'm no expert, but presumably RSVP must be able to cope with ECMP somehow? = Otherwise the RESV message wouldn't be sure to return down the same route t= hat the PATH message took? Toby On 5 Jan 2012, at 16:03, Tom Taylor wrote: > As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has mai= ntained that in the absence of tunneling or the use of the aggregate RSVP m= ethod for determining ingress-egress-aggregate classifiers, routing data ar= e inadequate for the purpose. He points out the case where an upstream doma= in uses ECMP, so that the same microflow could enter the PCN domain through= multiple ingress nodes and the egress node wouldn't be able to tell where = it came from. > > It appears, then, that the edge behaviour drafts will have to restrict th= eir applicability to the cases where PCN paqackets are tunneled or where th= e aggregate RSVP method is used to create classifiers. (Even in the latter = case, I'm not sure how Joel's upstream ECMP case is countered.) > > Does anyone have a better idea here? > > Tom Taylor > _______________________________________________ > 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 menth@informatik.uni-tuebingen.de Tue Jan 10 02:16: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 12E8621F86A0 for ; Tue, 10 Jan 2012 02:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZiA31nWTlek for ; Tue, 10 Jan 2012 02:16:46 -0800 (PST) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id D330721F8692 for ; Tue, 10 Jan 2012 02:16:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 34DCC532B; Tue, 10 Jan 2012 11:16:37 +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 EHbXa8s6dlFA; Tue, 10 Jan 2012 11:16:32 +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 AC5FD52DE; Tue, 10 Jan 2012 11:16:32 +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 85F27356FA4A; Tue, 10 Jan 2012 11:16:32 +0100 (CET) Message-ID: <4F0C1002.5010104@informatik.uni-tuebingen.de> Date: Tue, 10 Jan 2012 11:16:34 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: karagian@cs.utwente.nl References: <4F05C9B6.3060700@gmail.com>, <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> <580BEA5E3B99744AB1F5BFF5E9A3C67D13131D63AE@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13131D63AE@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] Classification of packets by ingress-egress-aggregate 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, 10 Jan 2012 10:16:47 -0000 Hi Georgios, the use of the existing PCN variant work from a functional point of view as suggested by Ruediger. However, the defined PCN-based admission control mechanism may be inefficient in ECMP networks as early blocking is possible. -> Section IV.7 in [MeLe12] M. Menth and F. Lehrieder: Performance of PCN-Based Admission Control under Challenging Conditions, accepted for IEEE/ACM Transactions on Networking, 2012 http://atlas2.informatik.uni-tuebingen.de/menth/papers/Menth08-Sub-8.pdf This hint should be added as a caveat. Regards, Michael Am 10.01.2012 08:48, schrieb Ruediger.Geib@telekom.de: > Hi Georgios, > > a statement that tunnels avoiding flow based ECMP routing > is the way to go, I agree. I suggest to formulate it > that way, as there are tunnels which still support flow > based ECMP routing (like IP over LDP based MPLS or > Flow aware Transport). > > We shouldn't mention multiple tunnels as a solution > enabling ECMP usage with PCN, if this results in an > expectation that we have to provide details how that > works. > > Regards, > > Ruediger > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of karagian@cs.utwente.nl > Sent: Friday, January 06, 2012 6:58 PM > To: toby.moncaster@cl.cam.ac.uk; tom.taylor.stds@gmail.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate > > Dear all > > I agree with Toby. Some solutions are listed in the below draft (Section 5.1): > http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture-04 > > I think that the solution that will work in PCN is tunelling. > In particualr, in networks that are using ECMP then PCN traffic need to be tunnelled. In this case the destination address (and so on) seen by the ECMP algorithm is that of the PCN-egress-node, so all flows follow the same path. > Effectively ECMP is turned off. As a compromise, to try to retain some of the benefits of ECMP, there could be several tunnels, each following a different ECMP path, with flows randomly assigned to different tunnels. > > Best regards, > Georgios > > ________________________________________ > Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Toby Moncaster [toby.moncaster@cl.cam.ac.uk] > Verzonden: donderdag 5 januari 2012 17:30 > Aan: Tom Taylor > CC: pcn > Onderwerp: Re: [PCN] Classification of packets by ingress-egress-aggregate > > I think we should put it the other way round. In networks that are using ECMP then PCN traffic has to be tunnelled or use suitable RSVP. That sort of matches with what it says in RFC5559 about tunnelling. > > I'm no expert, but presumably RSVP must be able to cope with ECMP somehow? Otherwise the RESV message wouldn't be sure to return down the same route that the PATH message took? > > Toby > > On 5 Jan 2012, at 16:03, Tom Taylor wrote: > >> As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has maintained that in the absence of tunneling or the use of the aggregate RSVP method for determining ingress-egress-aggregate classifiers, routing data are inadequate for the purpose. He points out the case where an upstream domain uses ECMP, so that the same microflow could enter the PCN domain through multiple ingress nodes and the egress node wouldn't be able to tell where it came from. >> >> It appears, then, that the edge behaviour drafts will have to restrict their applicability to the cases where PCN paqackets are tunneled or where the aggregate RSVP method is used to create classifiers. (Even in the latter case, I'm not sure how Joel's upstream ECMP case is countered.) >> >> Does anyone have a better idea here? >> >> Tom Taylor >> _______________________________________________ >> 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 -- 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 Tue Jan 10 02:57: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 74BA221F847A for ; Tue, 10 Jan 2012 02:57:58 -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 YuGE-Ow9tAej for ; Tue, 10 Jan 2012 02:57:57 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3198721F8499 for ; Tue, 10 Jan 2012 02:57:57 -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.218.12; Tue, 10 Jan 2012 11:57:57 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.33]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0323.003; Tue, 10 Jan 2012 11:57:53 +0100 From: To: Thread-Topic: [PCN] Classification of packets by ingress-egress-aggregate Thread-Index: AQHMy8OKFJn4vXD54UuKbr7EyCEXwpX95nKAgAG4xi2ABHbHYIABQ5IAgAAb/RA= Date: Tue, 10 Jan 2012 10:57:51 +0000 Message-ID: References: <4F05C9B6.3060700@gmail.com>, <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> <580BEA5E3B99744AB1F5BFF5E9A3C67D13131D63AE@HE111648.emea1.cds.t-internal.com> <4F0C1002.5010104@informatik.uni-tuebingen.de> In-Reply-To: <4F0C1002.5010104@informatik.uni-tuebingen.de> 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 Cc: pcn@ietf.org Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate 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, 10 Jan 2012 10:57:58 -0000 Hi Michael, Agree, thank you very much!=20 Can you please provide the text that we should include in the draft? Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] > Sent: dinsdag 10 januari 2012 11:17 > To: Karagiannis, G. (Georgios) > Cc: Ruediger.Geib@telekom.de; pcn@ietf.org > Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate >=20 > Hi Georgios, >=20 > the use of the existing PCN variant work from a functional point of view = as > suggested by Ruediger. However, the defined PCN-based admission control > mechanism may be inefficient in ECMP networks as early blocking is possib= le. >=20 > -> Section IV.7 in [MeLe12] M. Menth and F. Lehrieder: Performance of > PCN-Based Admission Control under Challenging Conditions, accepted for > IEEE/ACM Transactions on Networking, 2012 http://atlas2.informatik.uni- > tuebingen.de/menth/papers/Menth08-Sub-8.pdf >=20 > This hint should be added as a caveat. >=20 > Regards, >=20 > Michael >=20 >=20 > Am 10.01.2012 08:48, schrieb Ruediger.Geib@telekom.de: > > Hi Georgios, > > > > a statement that tunnels avoiding flow based ECMP routing is the way > > to go, I agree. I suggest to formulate it that way, as there are > > tunnels which still support flow based ECMP routing (like IP over LDP > > based MPLS or Flow aware Transport). > > > > We shouldn't mention multiple tunnels as a solution enabling ECMP > > usage with PCN, if this results in an expectation that we have to > > provide details how that works. > > > > Regards, > > > > Ruediger > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > > karagian@cs.utwente.nl > > Sent: Friday, January 06, 2012 6:58 PM > > To: toby.moncaster@cl.cam.ac.uk; tom.taylor.stds@gmail.com > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Classification of packets by > > ingress-egress-aggregate > > > > Dear all > > > > I agree with Toby. Some solutions are listed in the below draft (Secti= on > 5.1): > > http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture-04 > > > > I think that the solution that will work in PCN is tunelling. > > In particualr, in networks that are using ECMP then PCN traffic need to= be > tunnelled. In this case the destination address (and so on) seen by the = ECMP > algorithm is that of the PCN-egress-node, so all flows follow the same p= ath. > > Effectively ECMP is turned off. As a compromise, to try to retain some = of > the benefits of ECMP, there could be several tunnels, each following a > different ECMP path, with flows randomly assigned to different tunnels. > > > > Best regards, > > Georgios > > > > ________________________________________ > > Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Toby > Moncaster > > [toby.moncaster@cl.cam.ac.uk] > > Verzonden: donderdag 5 januari 2012 17:30 > > Aan: Tom Taylor > > CC: pcn > > Onderwerp: Re: [PCN] Classification of packets by > > ingress-egress-aggregate > > > > I think we should put it the other way round. In networks that are usin= g > ECMP then PCN traffic has to be tunnelled or use suitable RSVP. That sort= of > matches with what it says in RFC5559 about tunnelling. > > > > I'm no expert, but presumably RSVP must be able to cope with ECMP > somehow? Otherwise the RESV message wouldn't be sure to return down > the same route that the PATH message took? > > > > Toby > > > > On 5 Jan 2012, at 16:03, Tom Taylor wrote: > > > >> As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has > maintained that in the absence of tunneling or the use of the aggregate R= SVP > method for determining ingress-egress-aggregate classifiers, routing data= are > inadequate for the purpose. He points out the case where an upstream > domain uses ECMP, so that the same microflow could enter the PCN domain > through multiple ingress nodes and the egress node wouldn't be able to te= ll > where it came from. > >> > >> It appears, then, that the edge behaviour drafts will have to > >> restrict their applicability to the cases where PCN paqackets are > >> tunneled or where the aggregate RSVP method is used to create > >> classifiers. (Even in the latter case, I'm not sure how Joel's > >> upstream ECMP case is countered.) > >> > >> Does anyone have a better idea here? > >> > >> Tom Taylor > >> _______________________________________________ > >> 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 >=20 > -- > Prof. Dr. habil. Michael Menth > University of Tuebingen > Faculty of Science > Department of Computer Science > Chair of Communication Networks > Sand 13, 72076 Tuebingen, Germany > phone: (+49)-7071/29-70505 > fax: (+49)-7071/29-5220 > mailto:menth@uni-tuebingen.de > http://kn.inf.uni-tuebingen.de From menth@informatik.uni-tuebingen.de Tue Jan 10 04:40: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 32C4C21F85F8 for ; Tue, 10 Jan 2012 04:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[AWL=0.000, 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 dtpBw1qwAXZt for ; Tue, 10 Jan 2012 04:40:50 -0800 (PST) Received: from mx3.informatik.uni-tuebingen.de (mx3.Informatik.Uni-Tuebingen.De [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id DBD2621F8516 for ; Tue, 10 Jan 2012 04:40:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4CF21532B; Tue, 10 Jan 2012 13:40:44 +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 zQ8rEXM7TBIX; Tue, 10 Jan 2012 13:40:38 +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 A971852DE; Tue, 10 Jan 2012 13:40:38 +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 7ECC83573481; Tue, 10 Jan 2012 13:40:38 +0100 (CET) Message-ID: <4F0C31C8.1070806@informatik.uni-tuebingen.de> Date: Tue, 10 Jan 2012 13:40:40 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: karagian@cs.utwente.nl References: <4F05C9B6.3060700@gmail.com>, <22DC2CBD-A585-4FEC-AD2B-39F7C064F55B@cl.cam.ac.uk> <580BEA5E3B99744AB1F5BFF5E9A3C67D13131D63AE@HE111648.emea1.cds.t-internal.com> <4F0C1002.5010104@informatik.uni-tuebingen.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate 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, 10 Jan 2012 12:40:51 -0000 Hi Georgios, here is the requested text. "The use of CL/SM's PCN-based admission control in networks with flow-based ECMP routing raises performance concerns. If one of multiple potential paths of an ingress-egress aggregate is pre-congested, admission control possibly blocks all further flows for this ingress-egress aggregate even though these flows are forwared over non-pre-congested paths. As a consequence, the defined PCN-based admission control mechanism may be inefficient as early blocking is possible [Section IV.7 in MeLe12]." [MeLe12] M. Menth and F. Lehrieder: Performance of PCN-Based Admission Control under Challenging Conditions, accepted for IEEE/ACM Transactions on Networking, 2012 [MeLe12] is already cited in CL and SM in different context, so the reference is already available. Regards, Michael Am 10.01.2012 11:57, schrieb karagian@cs.utwente.nl: > Hi Michael, > > Agree, thank you very much! > Can you please provide the text that we should include in the draft? > > Best regards, > Georgios > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-tuebingen.de] >> Sent: dinsdag 10 januari 2012 11:17 >> To: Karagiannis, G. (Georgios) >> Cc: Ruediger.Geib@telekom.de; pcn@ietf.org >> Subject: Re: [PCN] Classification of packets by ingress-egress-aggregate >> >> Hi Georgios, >> >> the use of the existing PCN variant work from a functional point of view as >> suggested by Ruediger. However, the defined PCN-based admission control >> mechanism may be inefficient in ECMP networks as early blocking is possible. >> >> -> Section IV.7 in [MeLe12] M. Menth and F. Lehrieder: Performance of >> PCN-Based Admission Control under Challenging Conditions, accepted for >> IEEE/ACM Transactions on Networking, 2012 http://atlas2.informatik.uni- >> tuebingen.de/menth/papers/Menth08-Sub-8.pdf >> >> This hint should be added as a caveat. >> >> Regards, >> >> Michael >> >> >> Am 10.01.2012 08:48, schrieb Ruediger.Geib@telekom.de: >>> Hi Georgios, >>> >>> a statement that tunnels avoiding flow based ECMP routing is the way >>> to go, I agree. I suggest to formulate it that way, as there are >>> tunnels which still support flow based ECMP routing (like IP over LDP >>> based MPLS or Flow aware Transport). >>> >>> We shouldn't mention multiple tunnels as a solution enabling ECMP >>> usage with PCN, if this results in an expectation that we have to >>> provide details how that works. >>> >>> Regards, >>> >>> Ruediger >>> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>> karagian@cs.utwente.nl >>> Sent: Friday, January 06, 2012 6:58 PM >>> To: toby.moncaster@cl.cam.ac.uk; tom.taylor.stds@gmail.com >>> Cc: pcn@ietf.org >>> Subject: Re: [PCN] Classification of packets by >>> ingress-egress-aggregate >>> >>> Dear all >>> >>> I agree with Toby. Some solutions are listed in the below draft (Section >> 5.1): >>> http://tools.ietf.org/html/draft-briscoe-tsvwg-cl-architecture-04 >>> >>> I think that the solution that will work in PCN is tunelling. >>> In particualr, in networks that are using ECMP then PCN traffic need to be >> tunnelled. In this case the destination address (and so on) seen by the ECMP >> algorithm is that of the PCN-egress-node, so all flows follow the same path. >>> Effectively ECMP is turned off. As a compromise, to try to retain some of >> the benefits of ECMP, there could be several tunnels, each following a >> different ECMP path, with flows randomly assigned to different tunnels. >>> Best regards, >>> Georgios >>> >>> ________________________________________ >>> Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens Toby >> Moncaster >>> [toby.moncaster@cl.cam.ac.uk] >>> Verzonden: donderdag 5 januari 2012 17:30 >>> Aan: Tom Taylor >>> CC: pcn >>> Onderwerp: Re: [PCN] Classification of packets by >>> ingress-egress-aggregate >>> >>> I think we should put it the other way round. In networks that are using >> ECMP then PCN traffic has to be tunnelled or use suitable RSVP. That sort of >> matches with what it says in RFC5559 about tunnelling. >>> I'm no expert, but presumably RSVP must be able to cope with ECMP >> somehow? Otherwise the RESV message wouldn't be sure to return down >> the same route that the PATH message took? >>> Toby >>> >>> On 5 Jan 2012, at 16:03, Tom Taylor wrote: >>> >>>> As GEN-Art reviewer for the SM edge behaviour draft, Joel Halpern has >> maintained that in the absence of tunneling or the use of the aggregate RSVP >> method for determining ingress-egress-aggregate classifiers, routing data are >> inadequate for the purpose. He points out the case where an upstream >> domain uses ECMP, so that the same microflow could enter the PCN domain >> through multiple ingress nodes and the egress node wouldn't be able to tell >> where it came from. >>>> It appears, then, that the edge behaviour drafts will have to >>>> restrict their applicability to the cases where PCN paqackets are >>>> tunneled or where the aggregate RSVP method is used to create >>>> classifiers. (Even in the latter case, I'm not sure how Joel's >>>> upstream ECMP case is countered.) >>>> >>>> Does anyone have a better idea here? >>>> >>>> Tom Taylor >>>> _______________________________________________ >>>> 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 >> -- >> 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 -- 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 internet-drafts@ietf.org Sun Jan 15 15:47: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 DF82F21F84FB; Sun, 15 Jan 2012 15:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 vf4m7MBpaPVn; Sun, 15 Jan 2012 15:47:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C357421F8470; Sun, 15 Jan 2012 15:46:48 -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: 3.64p1 Message-ID: <20120115234648.1188.8799.idtracker@ietfa.amsl.com> Date: Sun, 15 Jan 2012 15:46:48 -0800 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 23:47:06 -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-07.txt Pages : 18 Date : 2012-01-15 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-07.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-07.txt From karagian@cs.utwente.nl Sun Jan 15 15:53:09 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 D6F5C21F8508; Sun, 15 Jan 2012 15:53:09 -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 cigb77vGDQ7Y; Sun, 15 Jan 2012 15:53:09 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id EE0AD21F84FF; Sun, 15 Jan 2012 15:53:08 -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.323.3; Mon, 16 Jan 2012 00:53:10 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.33]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0323.003; Mon, 16 Jan 2012 00:53:07 +0100 From: To: , Thread-Topic: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-07.txt Thread-Index: AQHM0+AQW4koXCqbH0aSnCW1Wm5glpYOGKMn Date: Sun, 15 Jan 2012 23:53:07 +0000 Message-ID: References: <20120115234648.1188.8799.idtracker@ietfa.amsl.com> In-Reply-To: <20120115234648.1188.8799.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-pcn-encoding-comparison-07.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 23:53:10 -0000 Hi all, Michael and I have worked out the comments from the tsv-dir review (from P= asi) for draft-ietf-pcn-encoding-comparison-06. The new version of the draft has just been submitted! Pasi thank you very much for the comments! Best regards, Georgios ________________________________________ Van: pcn-bounces@ietf.org [pcn-bounces@ietf.org] namens internet-drafts@iet= f.org [internet-drafts@ietf.org] Verzonden: maandag 16 januari 2012 0:46 Aan: i-d-announce@ietf.org CC: pcn@ietf.org Onderwerp: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-07.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-07.txt Pages : 18 Date : 2012-01-15 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-07.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-07.tx= t _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From karagian@cs.utwente.nl Mon Jan 16 06:00: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 DF4BD21F85F4 for ; Mon, 16 Jan 2012 06:00:36 -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 IeNLRzN365Ug for ; Mon, 16 Jan 2012 06:00:36 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id F39B121F85D1 for ; Mon, 16 Jan 2012 06:00:35 -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.323.3; Mon, 16 Jan 2012 15:00:37 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.33]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0323.003; Mon, 16 Jan 2012 15:00:33 +0100 From: To: Thread-Topic: AD Review: draft-ietf-pcn-signaling-requirements-07 Thread-Index: AczBnSRm+rvNJWrgRDGmr1XLonvoxQSuXg6g Date: Mon, 16 Jan 2012 14:00:33 +0000 Message-ID: References: <96A7580CC96642F39F8B7B86B1EFF425@davidPC> In-Reply-To: <96A7580CC96642F39F8B7B86B1EFF425@davidPC> 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 Cc: pcn@ietf.org, pcn-chairs@tools.ietf.org, draft-ietf-pcn-signaling-requirements@tools.ietf.org Subject: Re: [PCN] AD Review: draft-ietf-pcn-signaling-requirements-07 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, 16 Jan 2012 14:00:37 -0000 Hi David, Thanks for the comments! Regarding the following concern: > "Shouldn't the signaling from PDP to PEP be included in these requirement= s? > Reporting the information to a non-colocated Decision Point doesn't do mu= ch > if there is no signaling protocol from the Decision Point to the Enforcem= ent > Point. > I think there should be some discussion in the document of how > deployments are expected to handle this (e.g. operational > considerations) if the PCN WG considers it not in-scope." We would like to include the following text, which has been proposed by Tom= .=20 "A complete system description for a PCN domain with centralized Decision P= oint includes the signalling from Decision Point to the PCN-ingress-nodes t= o control flow admission and termination. However, this is a known problem = whose solutions were given by, for example, RFC 3084 or RFC 5431. It lies outside the scope of the present document." Please inform us if the above text satisfies your concern? Best regards, Georgios > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net] > Sent: vrijdag 23 december 2011 19:03 > To: pcn-chairs@tools.ietf.org; draft-ietf-pcn-signaling- > requirements@tools.ietf.org > Subject: AD Review: draft-ietf-pcn-signaling-requirements-07 >=20 > AD Review: draft-ietf-pcn-signaling-requirements-07 >=20 > I have reviewed this draft. > I found it well-written as an Information model, and I am satisfied it is= ready > for IETF Last Call, as far as it goes. >=20 > I do have one concern, which I will submit to you as a Last Call > comment: > "Shouldn't the signaling from PDP to PEP be included in these requirement= s? > Reporting the information to a non-colocated Decision Point doesn't do mu= ch > if there is no signaling protocol from the Decision Point to the Enforcem= ent > Point. > I think there should be some discussion in the document of how > deployments are expected to handle this (e.g. operational > considerations) if the PCN WG considers it not in-scope." >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) From slblake@petri-meat.com Wed Jan 18 22:18: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 104F111E8088 for ; Wed, 18 Jan 2012 22:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.327 X-Spam-Level: X-Spam-Status: No, score=-100.327 tagged_above=-999 required=5 tests=[AWL=0.413, 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 DGxYk4jFLDRa for ; Wed, 18 Jan 2012 22:18:41 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7487A11E8072 for ; Wed, 18 Jan 2012 22:18:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Date:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=fV3tqC9sHTtjTSABTPXQDkjMXyGZkgRfbpPzxBmkeAFRNYeVaIYYsP+PcoP6Nm/tgMI4HQWWsIK/VKMN0yuBObx0+41ekbnp/4DdubOJ6SCo3V3PqceCFpeoMg5RaVQq; Received: from cpe-174-097-234-146.nc.res.rr.com ([174.97.234.146]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1RnlKZ-0002dX-Ew for pcn@ietf.org; Thu, 19 Jan 2012 01:18:39 -0500 From: Steven Blake To: pcn Date: Thu, 19 Jan 2012 01:18:40 -0500 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1326953921.5194.17.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: [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: Thu, 19 Jan 2012 06:18:42 -0000 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. Regards, // Steve From menth@informatik.uni-tuebingen.de Thu Jan 19 03:50: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 C086221F8535 for ; Thu, 19 Jan 2012 03:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 FLFlfXAaIeRY for ; Thu, 19 Jan 2012 03:50:09 -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 AA37221F85BB for ; Thu, 19 Jan 2012 03:50:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 392C35330; Thu, 19 Jan 2012 12:49:57 +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 5i-wOHjuBI4B; Thu, 19 Jan 2012 12:49:52 +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 5E41E5276; Thu, 19 Jan 2012 12:49:52 +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 753751715198; Thu, 19 Jan 2012 12:49:52 +0100 (CET) Message-ID: <4F180360.1000601@informatik.uni-tuebingen.de> Date: Thu, 19 Jan 2012 12:49:52 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Steven Blake References: <1326953921.5194.17.camel@tachyon> In-Reply-To: <1326953921.5194.17.camel@tachyon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 19 Jan 2012 11:50:10 -0000 Hi Steve, I will be in Paris and I think it's good to have such a meeting to sort out issues face-to-face. As PCN seems problematic with multipath routing and multipath routing seems widely deployed, I'd like to discuss again about a solution that most probably works well in the presence of multipath routing, at least with RSVP end-to-end signalling. If that is of interest, this may be carried out in tsvwg, for instance. It might also be good to talk about some signalling issues. Kind regards, Michael Am 19.01.2012 07:18, schrieb Steven Blake: > 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. > > > Regards, > > // Steve > > _______________________________________________ > 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 Thu Jan 19 08:45: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 E798721F8603 for ; Thu, 19 Jan 2012 08:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 uaN2X27rIak6 for ; Thu, 19 Jan 2012 08:45:40 -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 5FF3821F85FF for ; Thu, 19 Jan 2012 08:45:40 -0800 (PST) Received: by yenm3 with SMTP id m3so92246yen.31 for ; Thu, 19 Jan 2012 08:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=2IIRn0nfmxzsj8BhperbSQF5oLQSGud0P+AOppaTiNM=; b=GFYJPJnshzgIdoWg9EYbEqpfJxBWffXeNbA3IwwL2A0XQd3ZEQKzZVW4LtRpBeB+HD sVPG6cs82bPuWJY+Vc6ANvE4nf4QW4aSEwV1sXhMLFFpsp+PaXsNBayX+CwsAphDDU+A ydPa8w33jgCLnEkfXCj+fZfoDJiDIaa1oOvCE= Received: by 10.236.153.42 with SMTP id e30mr40910259yhk.10.1326991540044; Thu, 19 Jan 2012 08:45:40 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-170-82.tor.primus.ca. [173.206.170.82]) by mx.google.com with ESMTPS id i50sm49844889yhk.11.2012.01.19.08.45.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 08:45:39 -0800 (PST) Message-ID: <4F1848B2.2000002@gmail.com> Date: Thu, 19 Jan 2012 11:45:38 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120119-1, 19/01/2012), Outbound message X-Antivirus-Status: Clean Subject: [PCN] Requirement for microflow identifiers 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, 19 Jan 2012 16:45:41 -0000 We have received IESG comments on section 2.1 of the PCN signalling requirements draft, which talks about flow identifiers. Leaving aside the question of whether that section should be discussing potential solutions, I have a more fundamental question: Would the combination of multi-path routing and the use of flow termination ever be encountered in a non-IP network? If not, (micro)flow identifiers will be needed only in the case of IP networks. The edge behaviour and signalling requirements drafts would have to be modified accordingly. Tom Taylor From Richard.Lee.FTC@FMR.COM Thu Jan 19 09:47: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 F394021F854B for ; Thu, 19 Jan 2012 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 iX7zltudrY1V for ; Thu, 19 Jan 2012 09:47:34 -0800 (PST) Received: from maillnx-us311.fmr.com (maillnx-us311.fmr.com [192.223.178.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7B621F8548 for ; Thu, 19 Jan 2012 09:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; i=Richard.Lee.FTC@fmr.com; l=981; q=dns/txt; s=2009-03-17; t=1326995254; x=1358531254; h=x-tm-imss-message-id:from:to:date:subject:thread-topic: thread-index:message-id:references:in-reply-to: accept-language:content-language:x-ms-has-attach: x-ms-tnef-correlator:acceptlanguage:content-type: content-transfer-encoding:mime-version:x-filenames; z=X-TM-IMSS-Message-ID:<3873c4870004b256@msgrtpiv04vwin.fm r.com>|From:=20"Lee,=20Richard=20FTC"=20|To:=20Tom=20Taylor=20 ,=20pcn=20|Date:=20Thu,=2019=20Jan=202012 =2012:47:27=20-0500|Subject:=20RE:=20[PCN]=20Requirement =20for=20microflow=20identifiers|Thread-Topic:=20[PCN]=20 Requirement=20for=20microflow=20identifiers|Thread-Index: =20AczWyda0L3cPP/knTeSrJDqdgS09EQACF6xQ|Message-ID:=20<3B 4DBB0890AD6642BEAB7B3470FC18F9960E888DE7@MSGRTPCCRE2WIN.D MN1.FMR.COM>|References:=20<4F1848B2.2000002@gmail.com> |In-Reply-To:=20<4F1848B2.2000002@gmail.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-filenames:=20None; bh=kfAAsPeIbbXOodQzvgodPz/VkZXKTb8I1KvC6Lcp1FI=; b=ut7jlPNsBI8eMeWmNtHcsaQgnq2x3eORlJnRZY+nHNkdi2T0dtkuj4V/ IgtQn4FPWa5tT5h+dzo879o7gCxM4maAWojXIXWvZGfgegq+MCE38izkk LBmvCLd8gWw4WhgIQXOmWYUSM/VILLF5gUzGmngPyaIp/A+wYO6EqLlr7 4=; X-filenames: None Received: from msgmrosm02win.dmn1.fmr.com ([10.37.25.48]) by maillnx-us311.fmr.com with SMTP; 19 Jan 2012 12:47:32 -0500 Received: from msgrtpiv04vwin.DMN1.FMR.COM (10.93.70.46) by MSGMROSM02WIN.dmn1.fmr.com (Sigaba Gateway v4.1) with ESMTP id 156853197; Thu, 19 Jan 2012 12:47:31 -0500 X-TM-IMSS-Message-ID: <3873c4870004b256@msgrtpiv04vwin.fmr.com> Received: from msgrtphc04win.DMN1.FMR.COM ([10.95.12.184]) by msgrtpiv04vwin.fmr.com ([10.93.70.46]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 RC4-MD5 (128/128)) id 3873c4870004b256 ; Thu, 19 Jan 2012 12:47:31 -0500 Received: from MSGRTPCCRE2WIN.DMN1.FMR.COM ([10.95.11.32]) by msgrtphc04win.DMN1.FMR.COM ([10.95.12.184]) with mapi; Thu, 19 Jan 2012 12:47:31 -0500 From: "Lee, Richard FTC" To: Tom Taylor , pcn Date: Thu, 19 Jan 2012 12:47:27 -0500 Thread-Topic: [PCN] Requirement for microflow identifiers Thread-Index: AczWyda0L3cPP/knTeSrJDqdgS09EQACF6xQ Message-ID: <3B4DBB0890AD6642BEAB7B3470FC18F9960E888DE7@MSGRTPCCRE2WIN.DMN1.FMR.COM> References: <4F1848B2.2000002@gmail.com> In-Reply-To: <4F1848B2.2000002@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PCN] Requirement for microflow identifiers 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, 19 Jan 2012 17:47:35 -0000 What about MPLS, GMPLS & optical networks=20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: Thursday, January 19, 2012 11:46 AM To: pcn Subject: [PCN] Requirement for microflow identifiers We have received IESG comments on section 2.1 of the PCN signalling=20 requirements draft, which talks about flow identifiers. Leaving aside=20 the question of whether that section should be discussing potential=20 solutions, I have a more fundamental question: Would the combination of multi-path routing and the use of flow=20 termination ever be encountered in a non-IP network? If not, (micro)flow identifiers will be needed only in the case of IP=20 networks. The edge behaviour and signalling requirements drafts would=20 have to be modified accordingly. Tom Taylor _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From tom.taylor.stds@gmail.com Thu Jan 19 10:05: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 EC79C21F86C3 for ; Thu, 19 Jan 2012 10:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 p+TtvPxfAriN for ; Thu, 19 Jan 2012 10:05:32 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE33B21F86B7 for ; Thu, 19 Jan 2012 10:05:31 -0800 (PST) Received: by ghrr16 with SMTP id r16so170221ghr.31 for ; Thu, 19 Jan 2012 10:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=V+mK5V4SDaGUvM8fCcp77od4mdGm/Lm6MOXaBNSKQRg=; b=SQXy8I46WyDi1vuO0o+r/xLv7fBwNx8L2DlaH5w7iKwTiMXSgEmbOdCP5VcXWbv6qC sehmSx0gH8PF37aQ9ehMeICEzgUTiYZQNY2BndMlGuSolXCOmKgd12KZ2urRxZRQwixm IaNenq1rQqE5hkHWvaqk7bu1/aI7ljR05GJ+8= Received: by 10.100.246.30 with SMTP id t30mr12397789anh.20.1326996331091; Thu, 19 Jan 2012 10:05:31 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-170-82.tor.primus.ca. [173.206.170.82]) by mx.google.com with ESMTPS id b4sm226379and.18.2012.01.19.10.05.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 10:05:30 -0800 (PST) Message-ID: <4F185B69.6000404@gmail.com> Date: Thu, 19 Jan 2012 13:05:29 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Lee, Richard FTC" References: <4F1848B2.2000002@gmail.com> <3B4DBB0890AD6642BEAB7B3470FC18F9960E888DE7@MSGRTPCCRE2WIN.DMN1.FMR.COM> In-Reply-To: <3B4DBB0890AD6642BEAB7B3470FC18F9960E888DE7@MSGRTPCCRE2WIN.DMN1.FMR.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120119-1, 19/01/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn Subject: Re: [PCN] Requirement for microflow identifiers 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, 19 Jan 2012 18:05:33 -0000 Exactly. I've already received confirmation that ECMP is used in MPLS networks, but would flow termination ever be used in any of the networks you listed? On 19/01/2012 12:47 PM, Lee, Richard FTC wrote: > What about MPLS, GMPLS& optical networks > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Taylor > Sent: Thursday, January 19, 2012 11:46 AM > To: pcn > Subject: [PCN] Requirement for microflow identifiers > > We have received IESG comments on section 2.1 of the PCN signalling > requirements draft, which talks about flow identifiers. Leaving aside > the question of whether that section should be discussing potential > solutions, I have a more fundamental question: > > Would the combination of multi-path routing and the use of flow > termination ever be encountered in a non-IP network? > > If not, (micro)flow identifiers will be needed only in the case of IP > networks. The edge behaviour and signalling requirements drafts would > have to be modified accordingly. > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From menth@informatik.uni-tuebingen.de Thu Jan 19 12:57:31 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 4AF9E21F8591 for ; Thu, 19 Jan 2012 12:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReikJpqpZeh4 for ; Thu, 19 Jan 2012 12:57:30 -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 5CFFD21F857D for ; Thu, 19 Jan 2012 12:57:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id AE07052C9; Thu, 19 Jan 2012 21:57:23 +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 qeKSNHaugZCv; Thu, 19 Jan 2012 21:57:16 +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 55A0F5276; Thu, 19 Jan 2012 21:57:16 +0100 (MET) Received: from [192.168.1.101] (HSI-KBW-149-172-225-56.hsi13.kabel-badenwuerttemberg.de [149.172.225.56]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0B2AE17173DE; Thu, 19 Jan 2012 21:57:15 +0100 (CET) Message-ID: <4F1883AB.3070406@informatik.uni-tuebingen.de> Date: Thu, 19 Jan 2012 21:57:15 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tom Taylor References: <4F1848B2.2000002@gmail.com> In-Reply-To: <4F1848B2.2000002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Requirement for microflow identifiers 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, 19 Jan 2012 20:57:31 -0000 Hi Tom, I do not see any reason why flow termination is generally not attractive for use with MPLS tunnels. Regards, Michael Am 19.01.2012 17:45, schrieb Tom Taylor: > We have received IESG comments on section 2.1 of the PCN signalling > requirements draft, which talks about flow identifiers. Leaving aside > the question of whether that section should be discussing potential > solutions, I have a more fundamental question: > > Would the combination of multi-path routing and the use of flow > termination ever be encountered in a non-IP network? > > If not, (micro)flow identifiers will be needed only in the case of IP > networks. The edge behaviour and signalling requirements drafts would > have to be modified accordingly. > > Tom Taylor > _______________________________________________ > 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 Fri Jan 20 06:09:39 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 D70C821F859B for ; Fri, 20 Jan 2012 06:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 aXNdSZbx2j9d for ; Fri, 20 Jan 2012 06:09:39 -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 533CA21F859F for ; Fri, 20 Jan 2012 06:09:39 -0800 (PST) Received: by yenm3 with SMTP id m3so282958yen.31 for ; Fri, 20 Jan 2012 06:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=cqHJB/cA4xF1JNnXDHf6i/a1E/AIkitC7bIsWX707jM=; b=OCK5BNoIOWbTlegaJEXDHUE1jPX3WtmBw0OGbabxQbxdWXA+Dyl1mlI2gIO1Qmexir cxbFRAgPgAysYe+6OweytTCq4/spzRpgLoNsqciY25J5Gcpv0Y0S6gtVO/fX/Y3k/drO rkUK54isRVKECecJ7L6Rgfce5vRR6NOU7zTy8= Received: by 10.236.128.205 with SMTP id f53mr2674755yhi.111.1327068578965; Fri, 20 Jan 2012 06:09:38 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-126-26.tor.primus.ca. [207.112.126.26]) by mx.google.com with ESMTPS id a7sm8427553ana.5.2012.01.20.06.09.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 06:09:38 -0800 (PST) Message-ID: <4F19759F.7000601@gmail.com> Date: Fri, 20 Jan 2012 09:09:35 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 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 120120-0, 20/01/2012), Outbound message X-Antivirus-Status: Clean Subject: [PCN] Two conclusions from discussion of "discusses" 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, 20 Jan 2012 14:09:40 -0000 1) I have been convinced by mail received off-line that flow termination is also potentially applicable to non-IP transports. So no changes to existing requirements in that respect. 2) Second point is a new one, and I need the agreement of the WG and AD to make this change. The edge behaviour documents currently say that if report suppression is being used, the CLE calculated by the egress node is included in the report sent to the Decision Point. If report suppression is not being used, the egress node does not calculate CLE and does not include it in the report. My reason for doing things this way in the first place was to save one end from having to redo a calculation already done at the other end. Effectively, the Decision Point has to be aware that report suppression is in use (unavoidable, so no problem), and decides to take CLE from incoming reports or calculate it depending on whether that condition holds or does not. It would be cleaner to always require the Decision Point to calculate the CLE, in that it simplifies CLE logic and reduces the amount of information being carried in signalling. Would this change be acceptable aat this late point in the process, or should we keep what is there now? Tom Taylor From karagian@cs.utwente.nl Fri Jan 20 07:34: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 7881F21F85A1 for ; Fri, 20 Jan 2012 07:34:14 -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 lw3+xGaeg9LK for ; Fri, 20 Jan 2012 07:34:13 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6599C21F863C for ; Fri, 20 Jan 2012 07:34:13 -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, 20 Jan 2012 16:34:12 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.201]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Fri, 20 Jan 2012 16:34:12 +0100 From: To: , , Thread-Topic: [PCN] Two conclusions from discussion of "discusses" Thread-Index: AQHM130tv9W84994TUGVF2skz9m6HZYVYZyA Date: Fri, 20 Jan 2012 15:34:10 +0000 Message-ID: References: <4F19759F.7000601@gmail.com> In-Reply-To: <4F19759F.7000601@gmail.com> 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] Two conclusions from discussion of "discusses" 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, 20 Jan 2012 15:34:14 -0000 Hi Tom, Regarding your point 2) I agree to change the edge behaviour drafts=20 and draft-ietf-pcn-signaling-requirements to address this point. In particular, CLE will not be sent by the PCN-egress-node to the Decision = Point. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Tom Taylor > Sent: vrijdag 20 januari 2012 15:10 > To: pcn; David Harrington > Subject: [PCN] Two conclusions from discussion of "discusses" >=20 > 1) I have been convinced by mail received off-line that flow termination = is > also potentially applicable to non-IP transports. So no changes to existi= ng > requirements in that respect. >=20 > 2) Second point is a new one, and I need the agreement of the WG and AD t= o > make this change. The edge behaviour documents currently say that if repo= rt > suppression is being used, the CLE calculated by the egress node is inclu= ded > in the report sent to the Decision Point. If report suppression is not be= ing > used, the egress node does not calculate CLE and does not include it in t= he > report. My reason for doing things this way in the first place was to sav= e one > end from having to redo a calculation already done at the other end. > Effectively, the Decision Point has to be aware that report suppression i= s in > use (unavoidable, so no problem), and decides to take CLE from incoming > reports or calculate it depending on whether that condition holds or does > not. >=20 > It would be cleaner to always require the Decision Point to calculate the= CLE, > in that it simplifies CLE logic and reduces the amount of information bei= ng > carried in signalling. Would this change be acceptable aat this late poin= t in the > process, or should we keep what is there now? >=20 > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Fri Jan 20 09:16: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 42C4D21F8568 for ; Fri, 20 Jan 2012 09:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.915 X-Spam-Level: X-Spam-Status: No, score=-102.915 tagged_above=-999 required=5 tests=[AWL=0.684, 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 esuucPIXbpLi for ; Fri, 20 Jan 2012 09:16:57 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD1621F8565 for ; Fri, 20 Jan 2012 09:16:53 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 20 Jan 2012 17:16:51 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 20 Jan 2012 17:16:51 +0000 From: To: , , Date: Fri, 20 Jan 2012 17:16:49 +0000 Thread-Topic: [PCN] Two conclusions from discussion of "discusses" Thread-Index: AczXfSgPNABS5ncHQKKrnIXMZXWqZwAGeC6Q Message-ID: <9510D26531EF184D9017DF24659BB87F3316231B73@EMV65-UKRD.domain1.systemhost.net> References: <4F19759F.7000601@gmail.com> In-Reply-To: <4F19759F.7000601@gmail.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] Two conclusions from discussion of "discusses" 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, 20 Jan 2012 17:16:58 -0000 Tom, So i can answer 2) - please can you remind me why in the normal case the eg= ress node doesn't calculate CLE? This seems the obvious place to do it to m= e, i have forgotten the discussion about this. Thanks phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom T= aylor Sent: 20 January 2012 14:10 To: pcn; David Harrington Subject: [PCN] Two conclusions from discussion of "discusses" 1) I have been convinced by mail received off-line that flow termination=20 is also potentially applicable to non-IP transports. So no changes to=20 existing requirements in that respect. 2) Second point is a new one, and I need the agreement of the WG and AD=20 to make this change. The edge behaviour documents currently say that if=20 report suppression is being used, the CLE calculated by the egress node=20 is included in the report sent to the Decision Point. If report=20 suppression is not being used, the egress node does not calculate CLE=20 and does not include it in the report. My reason for doing things this=20 way in the first place was to save one end from having to redo a=20 calculation already done at the other end. Effectively, the Decision=20 Point has to be aware that report suppression is in use (unavoidable, so=20 no problem), and decides to take CLE from incoming reports or calculate=20 it depending on whether that condition holds or does not. It would be cleaner to always require the Decision Point to calculate=20 the CLE, in that it simplifies CLE logic and reduces the amount of=20 information being carried in signalling. Would this change be acceptable=20 aat this late point in the process, or should we keep what is there now? Tom Taylor _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From tom.taylor.stds@gmail.com Fri Jan 20 09:47: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 CC4C321F85F7 for ; Fri, 20 Jan 2012 09:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 o7M76zVacZzM for ; Fri, 20 Jan 2012 09:47:51 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3549221F85C5 for ; Fri, 20 Jan 2012 09:47:51 -0800 (PST) Received: by yhnn12 with SMTP id n12so429785yhn.31 for ; Fri, 20 Jan 2012 09:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=/nlZmnrh4n2thhnD7AzLUMVtjEwxRdhFkx95Cc7CV3k=; b=LtWtG7Ll8eW2eyUkaKKJtc59SibEq91Uk07d4hLDK/8Km4SQQljSBDsg+UGTKBJb5y ymPcwf7WNtR7aZtn56SJ/C5+j/orc93aavyzYyArFskcpr4f6gSBBpTdtKNbJjAeu6fL J98JyjzBLp/azKDQmDYYljbSYrFCZPV4DkjYA= Received: by 10.236.75.163 with SMTP id z23mr46862742yhd.79.1327081670828; Fri, 20 Jan 2012 09:47:50 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-126-26.tor.primus.ca. [207.112.126.26]) by mx.google.com with ESMTPS id p1sm9868706anj.17.2012.01.20.09.47.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 09:47:50 -0800 (PST) Message-ID: <4F19A8C5.4030505@gmail.com> Date: Fri, 20 Jan 2012 12:47:49 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: philip.eardley@bt.com References: <4F19759F.7000601@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231B73@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3316231B73@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120120-0, 20/01/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org Subject: Re: [PCN] Two conclusions from discussion of "discusses" 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, 20 Jan 2012 17:47:51 -0000 The egress node has no use for CLE in the normal case, so why should it bother to calculate it? On 20/01/2012 12:16 PM, philip.eardley@bt.com wrote: > Tom, > So i can answer 2) - please can you remind me why in the normal case the egress node doesn't calculate CLE? This seems the obvious place to do it to me, i have forgotten the discussion about this. > Thanks > phil > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Taylor > Sent: 20 January 2012 14:10 > To: pcn; David Harrington > Subject: [PCN] Two conclusions from discussion of "discusses" > > 1) I have been convinced by mail received off-line that flow termination > is also potentially applicable to non-IP transports. So no changes to > existing requirements in that respect. > > 2) Second point is a new one, and I need the agreement of the WG and AD > to make this change. The edge behaviour documents currently say that if > report suppression is being used, the CLE calculated by the egress node > is included in the report sent to the Decision Point. If report > suppression is not being used, the egress node does not calculate CLE > and does not include it in the report. My reason for doing things this > way in the first place was to save one end from having to redo a > calculation already done at the other end. Effectively, the Decision > Point has to be aware that report suppression is in use (unavoidable, so > no problem), and decides to take CLE from incoming reports or calculate > it depending on whether that condition holds or does not. > > It would be cleaner to always require the Decision Point to calculate > the CLE, in that it simplifies CLE logic and reduces the amount of > information being carried in signalling. Would this change be acceptable > aat this late point in the process, or should we keep what is there now? > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From philip.eardley@bt.com Fri Jan 20 10:19: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 B930C21F86BA for ; Fri, 20 Jan 2012 10:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=0.248, 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 HwSPoROJrNwy for ; Fri, 20 Jan 2012 10:19:53 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C821F86B7 for ; Fri, 20 Jan 2012 10:19:53 -0800 (PST) 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; Fri, 20 Jan 2012 18:19:46 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 20 Jan 2012 18:19:46 +0000 From: To: Date: Fri, 20 Jan 2012 18:19:44 +0000 Thread-Topic: [PCN] Two conclusions from discussion of "discusses" Thread-Index: AczXm6H7oEFR/n4PQ1a1XEepzBZTtAAAxXug Message-ID: <9510D26531EF184D9017DF24659BB87F3316231BB2@EMV65-UKRD.domain1.systemhost.net> References: <4F19759F.7000601@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231B73@EMV65-UKRD.domain1.systemhost.net> <4F19A8C5.4030505@gmail.com> In-Reply-To: <4F19A8C5.4030505@gmail.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] Two conclusions from discussion of "discusses" 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, 20 Jan 2012 18:19:54 -0000 Is it really any hassle? If the egress doesnt calculate it, then it gets ca= lculated when gets to the ingress node, and all egress nodes are ingress no= des. Also, if admission control is on the basis of a pkt (or several pkts) being= marked, ie the egress detects this and signals 'dont admit' - then if the = egress node is reporting CLE it can simply set cle to 100%. -----Original Message----- From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 Sent: 20 January 2012 17:48 To: Eardley,PL,Philip,DUB8 R Cc: pcn@ietf.org; ietfdbh@comcast.net Subject: Re: [PCN] Two conclusions from discussion of "discusses" The egress node has no use for CLE in the normal case, so why should it=20 bother to calculate it? On 20/01/2012 12:16 PM, philip.eardley@bt.com wrote: > Tom, > So i can answer 2) - please can you remind me why in the normal case the = egress node doesn't calculate CLE? This seems the obvious place to do it to= me, i have forgotten the discussion about this. > Thanks > phil > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom= Taylor > Sent: 20 January 2012 14:10 > To: pcn; David Harrington > Subject: [PCN] Two conclusions from discussion of "discusses" > > 1) I have been convinced by mail received off-line that flow termination > is also potentially applicable to non-IP transports. So no changes to > existing requirements in that respect. > > 2) Second point is a new one, and I need the agreement of the WG and AD > to make this change. The edge behaviour documents currently say that if > report suppression is being used, the CLE calculated by the egress node > is included in the report sent to the Decision Point. If report > suppression is not being used, the egress node does not calculate CLE > and does not include it in the report. My reason for doing things this > way in the first place was to save one end from having to redo a > calculation already done at the other end. Effectively, the Decision > Point has to be aware that report suppression is in use (unavoidable, so > no problem), and decides to take CLE from incoming reports or calculate > it depending on whether that condition holds or does not. > > It would be cleaner to always require the Decision Point to calculate > the CLE, in that it simplifies CLE logic and reduces the amount of > information being carried in signalling. Would this change be acceptable > aat this late point in the process, or should we keep what is there now? > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From tom.taylor.stds@gmail.com Fri Jan 20 15:58: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 9BFF021F869D for ; Fri, 20 Jan 2012 15:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 LKxL5iVdtpZ2 for ; Fri, 20 Jan 2012 15:58:01 -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 B1A1021F8659 for ; Fri, 20 Jan 2012 15:57:57 -0800 (PST) Received: by yenm3 with SMTP id m3so608969yen.31 for ; Fri, 20 Jan 2012 15:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=VNiMWq/24CF5Dx4KmD6LDlkGSuhmAsz1VRLee1YlMxY=; b=xQp0Z51aQvjGUA1qSAyNTYhWJYRyrgAVxC6yaNkvcxVTr5Ga5hasaJA04omWWRq7Md zTisCZTP8gBDCqnZyYJfoV5admDpQYr5qLMGrRZg4iiB6UlDUUYr0C/BsrTKiM7fFx00 ybgn6t6e6sFdjU0cMvpZSP03Ip6D6fb0fDXj0= Received: by 10.236.124.66 with SMTP id w42mr11559656yhh.23.1327103877373; Fri, 20 Jan 2012 15:57:57 -0800 (PST) Received: from [127.0.0.1] (dsl-207-112-126-26.tor.primus.ca. [207.112.126.26]) by mx.google.com with ESMTPS id s7sm12637020anc.4.2012.01.20.15.57.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 Jan 2012 15:57:56 -0800 (PST) Message-ID: <4F19FF83.7090806@gmail.com> Date: Fri, 20 Jan 2012 18:57:55 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: philip.eardley@bt.com References: <4F19759F.7000601@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231B73@EMV65-UKRD.domain1.systemhost.net> <4F19A8C5.4030505@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231BB2@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3316231BB2@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120120-1, 20/01/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org Subject: Re: [PCN] Two conclusions from discussion of "discusses" 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, 20 Jan 2012 23:58:02 -0000 Technically, it's the Decision Point that needs the value. The egress node does not indicate "don't admit" in either of the edge behaviours I've documented -- or did you have another edge behaviour proposal in mind? On 20/01/2012 1:19 PM, philip.eardley@bt.com wrote: > Is it really any hassle? If the egress doesnt calculate it, then it gets calculated when gets to the ingress node, and all egress nodes are ingress nodes. > > Also, if admission control is on the basis of a pkt (or several pkts) being marked, ie the egress detects this and signals 'dont admit' - then if the egress node is reporting CLE it can simply set cle to 100%. > > > > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 20 January 2012 17:48 > To: Eardley,PL,Philip,DUB8 R > Cc: pcn@ietf.org; ietfdbh@comcast.net > Subject: Re: [PCN] Two conclusions from discussion of "discusses" > > The egress node has no use for CLE in the normal case, so why should it > bother to calculate it? > > On 20/01/2012 12:16 PM, philip.eardley@bt.com wrote: >> Tom, >> So i can answer 2) - please can you remind me why in the normal case the egress node doesn't calculate CLE? This seems the obvious place to do it to me, i have forgotten the discussion about this. >> Thanks >> phil >> >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Taylor >> Sent: 20 January 2012 14:10 >> To: pcn; David Harrington >> Subject: [PCN] Two conclusions from discussion of "discusses" >> >> 1) I have been convinced by mail received off-line that flow termination >> is also potentially applicable to non-IP transports. So no changes to >> existing requirements in that respect. >> >> 2) Second point is a new one, and I need the agreement of the WG and AD >> to make this change. The edge behaviour documents currently say that if >> report suppression is being used, the CLE calculated by the egress node >> is included in the report sent to the Decision Point. If report >> suppression is not being used, the egress node does not calculate CLE >> and does not include it in the report. My reason for doing things this >> way in the first place was to save one end from having to redo a >> calculation already done at the other end. Effectively, the Decision >> Point has to be aware that report suppression is in use (unavoidable, so >> no problem), and decides to take CLE from incoming reports or calculate >> it depending on whether that condition holds or does not. >> >> It would be cleaner to always require the Decision Point to calculate >> the CLE, in that it simplifies CLE logic and reduces the amount of >> information being carried in signalling. Would this change be acceptable >> aat this late point in the process, or should we keep what is there now? >> >> Tom Taylor >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > From philip.eardley@bt.com Mon Jan 23 01:17: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 AD3BD21F8655 for ; Mon, 23 Jan 2012 01:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.822 X-Spam-Level: X-Spam-Status: No, score=-102.822 tagged_above=-999 required=5 tests=[AWL=0.177, 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 K-IzByke9UUI for ; Mon, 23 Jan 2012 01:17:30 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id C854921F8652 for ; Mon, 23 Jan 2012 01:17:29 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 23 Jan 2012 09:17:27 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.111]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 23 Jan 2012 09:17:27 +0000 From: To: Date: Mon, 23 Jan 2012 09:17:26 +0000 Thread-Topic: [PCN] Two conclusions from discussion of "discusses" Thread-Index: AczXz1Yvq4Q1dBEaRrWyjX9uOFfUzwB32ZzQ Message-ID: <9510D26531EF184D9017DF24659BB87F3316231DC2@EMV65-UKRD.domain1.systemhost.net> References: <4F19759F.7000601@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231B73@EMV65-UKRD.domain1.systemhost.net> <4F19A8C5.4030505@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231BB2@EMV65-UKRD.domain1.systemhost.net> <4F19FF83.7090806@gmail.com> In-Reply-To: <4F19FF83.7090806@gmail.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] Two conclusions from discussion of "discusses" 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, 23 Jan 2012 09:17:30 -0000 << The egress=20 node does not indicate "don't admit" in either of the edge behaviours=20 I've documented=20 >> I wasn't saying it did. Reporting CLE leaves the decision point to decide w= hether to admit or block. <<-- or did you have another edge behaviour proposal in mind? >> My 2nd para referred to an edge behaviour we once talked about, sorry for b= ringing that up. I dont see much advantage or disadvantage in the change - I dont mind eithe= r way. -----Original Message----- From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]=20 Sent: 20 January 2012 23:58 To: Eardley,PL,Philip,DUB8 R Cc: pcn@ietf.org; ietfdbh@comcast.net Subject: Re: [PCN] Two conclusions from discussion of "discusses" Technically, it's the Decision Point that needs the value. The egress=20 node does not indicate "don't admit" in either of the edge behaviours=20 I've documented -- or did you have another edge behaviour proposal in mind? On 20/01/2012 1:19 PM, philip.eardley@bt.com wrote: > Is it really any hassle? If the egress doesnt calculate it, then it gets = calculated when gets to the ingress node, and all egress nodes are ingress = nodes. > > Also, if admission control is on the basis of a pkt (or several pkts) bei= ng marked, ie the egress detects this and signals 'dont admit' - then if th= e egress node is reporting CLE it can simply set cle to 100%. > > > > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 20 January 2012 17:48 > To: Eardley,PL,Philip,DUB8 R > Cc: pcn@ietf.org; ietfdbh@comcast.net > Subject: Re: [PCN] Two conclusions from discussion of "discusses" > > The egress node has no use for CLE in the normal case, so why should it > bother to calculate it? > > On 20/01/2012 12:16 PM, philip.eardley@bt.com wrote: >> Tom, >> So i can answer 2) - please can you remind me why in the normal case the= egress node doesn't calculate CLE? This seems the obvious place to do it t= o me, i have forgotten the discussion about this. >> Thanks >> phil >> >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of To= m Taylor >> Sent: 20 January 2012 14:10 >> To: pcn; David Harrington >> Subject: [PCN] Two conclusions from discussion of "discusses" >> >> 1) I have been convinced by mail received off-line that flow termination >> is also potentially applicable to non-IP transports. So no changes to >> existing requirements in that respect. >> >> 2) Second point is a new one, and I need the agreement of the WG and AD >> to make this change. The edge behaviour documents currently say that if >> report suppression is being used, the CLE calculated by the egress node >> is included in the report sent to the Decision Point. If report >> suppression is not being used, the egress node does not calculate CLE >> and does not include it in the report. My reason for doing things this >> way in the first place was to save one end from having to redo a >> calculation already done at the other end. Effectively, the Decision >> Point has to be aware that report suppression is in use (unavoidable, so >> no problem), and decides to take CLE from incoming reports or calculate >> it depending on whether that condition holds or does not. >> >> It would be cleaner to always require the Decision Point to calculate >> the CLE, in that it simplifies CLE logic and reduces the amount of >> information being carried in signalling. Would this change be acceptable >> aat this late point in the process, or should we keep what is there now? >> >> Tom Taylor >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > From menth@informatik.uni-tuebingen.de Mon Jan 23 01:24: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 CAE3621F8604 for ; Mon, 23 Jan 2012 01:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, 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 oDSHnE+8J-nv for ; Mon, 23 Jan 2012 01:24:25 -0800 (PST) Received: from mx3.informatik.uni-tuebingen.de (mx3.informatik.uni-tuebingen.de [134.2.12.26]) by ietfa.amsl.com (Postfix) with SMTP id 9BE3B21F84CF for ; Mon, 23 Jan 2012 01:24:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3346452E4 for ; Mon, 23 Jan 2012 10:24:23 +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 wW5MNbeEuy1y for ; Mon, 23 Jan 2012 10:24:20 +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 4F5AF52D7 for ; Mon, 23 Jan 2012 10:24:20 +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 7DDF73752AFC for ; Mon, 23 Jan 2012 10:24:20 +0100 (CET) Message-ID: <4F1D2746.3030504@informatik.uni-tuebingen.de> Date: Mon, 23 Jan 2012 10:24:22 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: pcn@ietf.org References: <4F19759F.7000601@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231B73@EMV65-UKRD.domain1.systemhost.net> <4F19A8C5.4030505@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231BB2@EMV65-UKRD.domain1.systemhost.net> <4F19FF83.7090806@gmail.com> <9510D26531EF184D9017DF24659BB87F3316231DC2@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3316231DC2@EMV65-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] Two conclusions from discussion of "discusses" 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, 23 Jan 2012 09:24:25 -0000 The problem is that the descriptions in the document sets are not consistent regarding whether CLE is explicitly reported or not. The CLE value is calculated by CLE=marked traffic / overall traffic. As these quantities are reported in signalling messages, and the calculation is very simple, I am in favor of dropping the CLE to avoid reporting redundant data. Regards Michael Am 23.01.2012 10:17, schrieb philip.eardley@bt.com: > << The egress > node does not indicate "don't admit" in either of the edge behaviours > I've documented > I wasn't saying it did. Reporting CLE leaves the decision point to decide whether to admit or block. > > <<-- or did you have another edge behaviour proposal in mind? > My 2nd para referred to an edge behaviour we once talked about, sorry for bringing that up. > > > I dont see much advantage or disadvantage in the change - I dont mind either way. > > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] > Sent: 20 January 2012 23:58 > To: Eardley,PL,Philip,DUB8 R > Cc: pcn@ietf.org; ietfdbh@comcast.net > Subject: Re: [PCN] Two conclusions from discussion of "discusses" > > Technically, it's the Decision Point that needs the value. The egress > node does not indicate "don't admit" in either of the edge behaviours > I've documented -- or did you have another edge behaviour proposal in mind? > > On 20/01/2012 1:19 PM, philip.eardley@bt.com wrote: >> Is it really any hassle? If the egress doesnt calculate it, then it gets calculated when gets to the ingress node, and all egress nodes are ingress nodes. >> >> Also, if admission control is on the basis of a pkt (or several pkts) being marked, ie the egress detects this and signals 'dont admit' - then if the egress node is reporting CLE it can simply set cle to 100%. >> >> >> >> -----Original Message----- >> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com] >> Sent: 20 January 2012 17:48 >> To: Eardley,PL,Philip,DUB8 R >> Cc: pcn@ietf.org; ietfdbh@comcast.net >> Subject: Re: [PCN] Two conclusions from discussion of "discusses" >> >> The egress node has no use for CLE in the normal case, so why should it >> bother to calculate it? >> >> On 20/01/2012 12:16 PM, philip.eardley@bt.com wrote: >>> Tom, >>> So i can answer 2) - please can you remind me why in the normal case the egress node doesn't calculate CLE? This seems the obvious place to do it to me, i have forgotten the discussion about this. >>> Thanks >>> phil >>> >>> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Taylor >>> Sent: 20 January 2012 14:10 >>> To: pcn; David Harrington >>> Subject: [PCN] Two conclusions from discussion of "discusses" >>> >>> 1) I have been convinced by mail received off-line that flow termination >>> is also potentially applicable to non-IP transports. So no changes to >>> existing requirements in that respect. >>> >>> 2) Second point is a new one, and I need the agreement of the WG and AD >>> to make this change. The edge behaviour documents currently say that if >>> report suppression is being used, the CLE calculated by the egress node >>> is included in the report sent to the Decision Point. If report >>> suppression is not being used, the egress node does not calculate CLE >>> and does not include it in the report. My reason for doing things this >>> way in the first place was to save one end from having to redo a >>> calculation already done at the other end. Effectively, the Decision >>> Point has to be aware that report suppression is in use (unavoidable, so >>> no problem), and decides to take CLE from incoming reports or calculate >>> it depending on whether that condition holds or does not. >>> >>> It would be cleaner to always require the Decision Point to calculate >>> the CLE, in that it simplifies CLE logic and reduces the amount of >>> information being carried in signalling. Would this change be acceptable >>> aat this late point in the process, or should we keep what is there now? >>> >>> Tom Taylor >>> _______________________________________________ >>> 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 From karagian@cs.utwente.nl Wed Jan 25 02:56: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 E90B721F85AF for ; Wed, 25 Jan 2012 02:56:04 -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 7Yj4K7FZxtf1 for ; Wed, 25 Jan 2012 02:56:04 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id 607B821F8570 for ; Wed, 25 Jan 2012 02:56:04 -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; Wed, 25 Jan 2012 11:56:03 +0100 Received: from EXMBX06.ad.utwente.nl ([169.254.6.120]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Wed, 25 Jan 2012 11:56:02 +0100 From: To: Thread-Topic: Solicitation for comments on draft-ietf-tsvwg-rsvp-pcn-00 Thread-Index: AczbT+vAjva9XRW+RhiN2wjNTu1tjA== Date: Wed, 25 Jan 2012 10:56:01 +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: [PCN] Solicitation for comments on draft-ietf-tsvwg-rsvp-pcn-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:56:05 -0000 Hi all,=20 I am planning to resubmit the http://datatracker.ietf.org/doc/draft-ietf-ts= vwg-rsvp-pcn/ before the IETF meeting in Paris! I will very much appreciat= e if you read this draft and send your comments to the tsvwg mailing list b= efore the 15th of February 2012! Best regards, Georgios From slblake@petri-meat.com Mon Jan 30 21:36:52 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 A604511E80FD for ; Mon, 30 Jan 2012 21:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.406 X-Spam-Level: X-Spam-Status: No, score=-100.406 tagged_above=-999 required=5 tests=[AWL=-0.407, 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 HUPsjmvFcrff for ; Mon, 30 Jan 2012 21:36:52 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id C3EE921F853D for ; Mon, 30 Jan 2012 21:36:51 -0800 (PST) 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=3xh08nFpcCWFwtckQ+AEPG9G59370KM7fV9SIpuznosjGX2+kU4wqWLK5jFQznlLtVHe+BNgkDfYm8EQ2wNfR1DmLiAw3jGdYEPxIpyTfD56TYOo7nO75RrfEhHjcnw8; Received: from cpe-174-097-234-146.nc.res.rr.com ([174.97.234.146]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Rs6Of-0001Xr-OP for pcn@ietf.org; Tue, 31 Jan 2012 00:36:49 -0500 From: Steven Blake To: pcn Date: Tue, 31 Jan 2012 00:36:50 -0500 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: <1327988211.24407.5.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, 31 Jan 2012 05:36:52 -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. FYI - I requested a 1.5 hour meeting slot in Paris. We still need to discuss a meeting agenda. Regards, // Steve