From internet-drafts@ietf.org Wed Feb 8 13:08:08 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966ED11E809B; Wed, 8 Feb 2012 13:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 3QFWhAiebNgu; Wed, 8 Feb 2012 13:08:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DBD11E8080; Wed, 8 Feb 2012 13:08:04 -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: <20120208210804.1711.3159.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2012 13:08:04 -0800 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-08.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: Wed, 08 Feb 2012 21:08:08 -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-08.txt Pages : 18 Date : 2012-02-08 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-08.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-08.txt From karagian@cs.utwente.nl Wed Feb 8 13:12: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 A5BA121F858D; Wed, 8 Feb 2012 13:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[AWL=0.500, 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 lLsBTed+zzKZ; Wed, 8 Feb 2012 13:12:08 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8C21F8562; Wed, 8 Feb 2012 13:12:08 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 8 Feb 2012 22:12:10 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.100]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.01.0339.001; Wed, 8 Feb 2012 22:12:06 +0100 From: To: , Thread-Topic: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-08.txt Thread-Index: AQHM5qXJxK5lor358Uexn3NyFl9doJYzfl2r Date: Wed, 8 Feb 2012 21:12:06 +0000 Message-ID: References: <20120208210804.1711.3159.idtracker@ietfa.amsl.com> In-Reply-To: <20120208210804.1711.3159.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-08.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: Wed, 08 Feb 2012 21:12:09 -0000 Hi all, I have just submitted draft-ietf-pcn-encoding-comparison-08! The comments provided by David Harrington have been worked out! David, thanks 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: woensdag 8 februari 2012 22:08 Aan: i-d-announce@ietf.org CC: pcn@ietf.org Onderwerp: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-08.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-08.txt Pages : 18 Date : 2012-02-08 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-08.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-08.tx= t _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From internet-drafts@ietf.org Wed Feb 8 16:18:33 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A0221F8449; Wed, 8 Feb 2012 16:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 1OPzElzsUY6M; Wed, 8 Feb 2012 16:18:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE5A21F84E1; Wed, 8 Feb 2012 16:18:29 -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: <20120209001829.16788.94042.idtracker@ietfa.amsl.com> Date: Wed, 08 Feb 2012 16:18:29 -0800 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-08.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 00:18:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : Requirements for Signaling of (Pre-) Congestion Informat= ion in a DiffServ Domain Author(s) : Georgios Karagiannis Tom Taylor Kwok Ho Chan Michael Menth Philip Eardley Filename : draft-ietf-pcn-signaling-requirements-08.txt Pages : 7 Date : 2012-02-08 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, "controlled load (CL)" and "single marking (SM)". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-0= 8.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-08= .txt From karagian@cs.utwente.nl Wed Feb 8 16:32:48 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B287121F8534; Wed, 8 Feb 2012 16:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.075 X-Spam-Level: X-Spam-Status: No, score=-0.075 tagged_above=-999 required=5 tests=[AWL=0.429, 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 jYGpMKDa32YE; Wed, 8 Feb 2012 16:32:43 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 099CC21F8504; Wed, 8 Feb 2012 16:32:43 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 9 Feb 2012 01:32:46 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.100]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Thu, 9 Feb 2012 01:32:42 +0100 From: To: , , Thread-Topic: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-08.txt (all DISCUSSES and comments worked out) Thread-Index: AQHM5sJUppUyXCUzNk+i1J70dbvTCQ== Date: Thu, 9 Feb 2012 00:32:41 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [80.60.223.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-08.txt (all DISCUSSES and comments worked out) 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, 09 Feb 2012 00:32:48 -0000 Hi all, The co-authors of the draft have worked out all DISCUSSES and all received = comments in draft: draft-ietf-pcn-signaling-requirements-08.txt. This draft= has been submitted some minutes ago! The DISCUSSES and comments are worked out in the following way: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D> worked out the DISCUSS entered by Stewart Bryant in the following way: >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > "The representation of a PCN-flow identifier depends on the surrounding > environment, e.g., pure IP, MPLS, GMPLS, etc. > Examples of such PCN-flow identifier representations can be found in > [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804]. " >=20 >=20 > The above text implies that it is a simple matter to identify > and represent an MPLS flow. I do not believe this to be the case. > The authors should either specify how they propose to > represent MPLS flows (as they do for IP) or note that this > is a problem that needs to be solved. >=20 Georgios: I think that we have written something else than what we meant! What we actually written is solution oriented and should be modified, pleas= e see below: Thus section 2.1 is removed. "2.1 Specification of PCN-Flow Identifiers The representation of a PCN-flow identifier depends on the surrounding environment, e.g., pure IP, MPLS, GMPLS, etc. Examples of such PCN-flow identifier representations can be found in = [RFC2205], [RFC3175] =20 [RFC3209], [RFC3473], [RFC4804]. In pure IP networks, the identifier may consist of a subset of the following information: o source IP address; o destination IP address o protocol identifier and higher layer (port) addressing o flow label (typical for IPv6) o SPI field for IPsec encapsulated data o DSCP/TOS field Note, where a PCN-flow consists of a collection of microflows, then the PCN-flow is identified by the PCN-ingress-node's and PCN-egress- node's identifiers (typically their IP addresses), which are already part of the report." The following paragraph is introduced instead! "As described in [draft-ietf-pcn-cl-edge-behaviour], PCN reports=20 from the PCN-egress-node to the decision point may contain flow identifiers= for Individual flows within an ingress-egress-aggregate that have recently= experienced excess-marking. Hence, the PCN report messages used by the PC= N CL edge behaviour MUST be capable of carrying sequences of octet strings = constituting such identifiers." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =3D> worked out the DISCUSS and COMMENT entered by Adrian Farrel in the fol= lowing way: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > In Section 2 (and repeated in 3) >=20 > Signaling messages SHOULD have a higher priority than data packets to > deliver them quickly and to avoid that they are dropped in case of > overload. >=20 > Unless I am mistaken, there is a difference between priority and drop=20 > precedence. Georgios: Agree with the observation. This text will be changed INTO: Signaling messages SHOULD have a higher priority and a lower drop precedenc= e than PCN-packets, see [RFC5559], to deliver them quickly and to avoid tha= t they are dropped in case of overload. >=20 > Can you also clarify whether you mean all data packets, or justdata=20 > packets on the measured flow. Georgios: We meant PCN-packets, see [RFC5559]: "o PCN-traffic, PCN-packets, PCN-BA: a PCN-domain carries traffic of different Diffserv behaviour aggregates (BAs) [RFC2474]. The PCN-BA uses the PCN mechanisms to carry PCN-traffic, and the corresponding packets are PCN-packets. The same network will carry traffic of other Diffserv BAs. The PCN-BA is distinguished by a combination of the Diffserv codepoint (DSCP) and ECN fields." Fr= om [RFC5559] >=20 > --- >=20 > I have a point that is very similar to Stewart's... >=20 > The representation of a PCN-flow identifier depends on the > surrounding environment, e.g., pure IP, MPLS, GMPLS, etc. > Examples of such PCN-flow identifier representations can be found in > [RFC2205], [RFC3175] [RFC3209], [RFC3473], [RFC4804]. >=20 > I don't find any mentiong of PCN in those documents, so I think you=20 > mean "Identifiers for flows can be found in [foo]. These identifiers=20 > can be used in PCN to identify the flows that are measured and reported o= n." >=20 > Thinking about it, the wider problem may be that the discussion in 2.1=20 > is actually solution-oriented. The requirements are to be able to=20 > apply PCN to a specific set of flows, and that the flow about which=20 > PCN is being signaled should be unambiguously identified. Those requireme= nts are worth stating. > You might even say tat there is a requirement that the data packets=20 > not be encumbered by any additional fields used for flow=20 > identification, therefore all flow identifiers must utilize only fields a= lready present in the data headers. > [At this point you might aslo comment on how deep it is acceptable to=20 > look - e.g., can you look below a top MPLS label?] >=20 > But the discussion of which identifiers are suitable is surely not a=20 > matter for a requirements document. Georgios: I agree, we removed Section 2.1, see below: "2.1 Specification of PCN-Flow Identifiers The representation of a PCN-flow identifier depends on the surrounding environment, e.g., pure IP, MPLS, GMPLS, etc. Examples of such PCN-flow identifier representations can be found in = [RFC2205], [RFC3175] =20 [RFC3209], [RFC3473], [RFC4804]. In pure IP networks, the identifier may consist of a subset of the following information: o source IP address; o destination IP address o protocol identifier and higher layer (port) addressing o flow label (typical for IPv6) o SPI field for IPsec encapsulated data o DSCP/TOS field Note, where a PCN-flow consists of a collection of microflows, then the PCN-flow is identified by the PCN-ingress-node's and PCN-egress- node's identifiers (typically their IP addresses), which are already part of the report." The following paragraph is introduced instead! "As described in [draft-ietf-pcn-cl-edge-behaviour], PCN reports=20 from the PCN-egress-node to the decision point may contain flow identifiers= for Individual flows within an ingress-egress-aggregate that have recently= experienced excess-marking. Hence, the PCN report messages used by the PC= N CL edge behaviour MUST be capable of carrying sequences of octet strings = constituting such identifiers." >=20 > --- >=20 > Section 4 >=20 > [RFC5559] provides a general description of the security > considerations for PCN. This memo does not introduce additional > security considerations. >=20 > I agree with the statement about RFC 5559. But surely this=20 > requirements document places security-related requirements on the PCN sig= naling. > These should be noted in this section. Georgios: the following text is introduced instead! [RFC5559] provides a general description of the security =20 considerations for PCN. This memo relies on the security-related=20 requirements on the PCN signalling, provided in [RFC5559]. In=20 particular, the signaling between the PCN-boundary-nodes must be =20 protected from attacks. For example, the recipient needs to=20 validate that the message is indeed from the node that claims to have=20 sent it. Possible measures include digest authentication and=20 protection against replay and man-in-the-middle attacks. For the=20 generic aggregate RSVP protocol, specifically, additional protection=20 methods against security attacks are described in [RFC4860]. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > You should remove the citations from the Abstract. >=20 Georgios: Agree! The following references are removed from the abstract: [draft-ietf-pcn-cl-edge- behaviour-09],=20 [draft-ietf-pcn-sm-edge-behaviour-06]. ------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D> worked out the COMMENT entered by Stephen Farrell in the following = way: >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > I just note that 5559 which is referenced here says "The signalling betwe= en > the PCN-boundary-nodes must be protected from attacks." > So I'm counting on the eventual protocol document meeting that goal. Georgios: Please note that, we modified Section 4 in the following way: [RFC5559] provides a general description of the security =20 considerations for PCN. This memo relies on the security-related=20 requirements on the PCN signalling, provided in [RFC5559]. In=20 particular, the signaling between the PCN-boundary-nodes must be =20 protected from attacks. For example, the recipient needs to=20 validate that the message is indeed from the node that claims to have=20 sent it. Possible measures include digest authentication and=20 protection against replay and man-in-the-middle attacks. For the=20 generic aggregate RSVP protocol, specifically, additional protection=20 methods against security attacks are described in [RFC4860]. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D> worked out the comment from David Harrington=20 > "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 "Note that a complete system description for a PCN domain with=20 centralized Decision Point includes the signaling from Decision Point=20 to the PCN-ingress-nodes to control flow admission and termination.=20 However, this is a known problem whose solutions were given by,=20 for example, [RFC3084] or [RFC5431], and it lies outside the scope of=20 the present document." =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D> comments from Francis Dupont: > Van: Francis.Dupont@fdupont.fr [Francis.Dupont@fdupont.fr] > Verzonden: zaterdag 14 januari 2012 10:13 > Aan: gen-art@ietf.org > CC: draft-ietf-pcn-signaling-requirements.all@tools.ietf.org > Onderwerp: review of draft-ietf-pcn-signaling-requirements-07.txt > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-pcn-signaling-requirements-07.txt > Reviewer: Francis Dupont > Review Date: 20120106 > IETF LC End Date: 20120113 > IESG Telechat date: unknown > > Summary: Ready > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > - in the whole document: behaviour -> behavior and > signalling -> signaling > (note the spelling of collocated is dubious too) Georgios: Solved! > > - Abstract page 1: in the latter case -> in the first case Georgios: done! > > - Abstract page 1: the usage is to not refer to RFC in the Abstract Georgios: done! > > - ToC page 2: Acknowledgements -> Acknowledgments Georgios: done! > > - 2 page 3: measures- -> measures (in general the document is at > the limit of abuse of '-' character, here it is clearly a typo) Georgios: done > > - 6 page 6: Acknowledgements -> Acknowledgments Georgios: done > > - 6 page 6: I don't like the term 'generated', IMHO you can easily > find a better/nicer term. GeorgiosL done (used =3D> produced) > > - 7.2 page 7: C. Le Faucher, -> C., Le Faucheur, Georgios: the reference in removed! =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D =3D> Followed comments/suggestions provided by Tom, Michael and Phil and r= emoved the bullets from Section 2: =20 o congestion-level-estimate, which is a number between zero and=20 one. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D All: 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: donderdag 9 februari 2012 1:18 Aan: i-d-announce@ietf.org CC: pcn@ietf.org Onderwerp: [PCN] I-D Action: draft-ietf-pcn-signaling-requirements-08.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 : Requirements for Signaling of (Pre-) Congestion I= nformation in a DiffServ Domain Author(s) : Georgios Karagiannis Tom Taylor Kwok Ho Chan Michael Menth Philip Eardley Filename : draft-ietf-pcn-signaling-requirements-08.txt Pages : 7 Date : 2012-02-08 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, "controlled load (CL)" and "single marking (SM)". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-0= 8.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-signaling-requirements-08= .txt _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn= From iesg-secretary@ietf.org Thu Feb 9 14:52:06 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C2021E8069; Thu, 9 Feb 2012 14:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 VKc3RHKLCmJD; Thu, 9 Feb 2012 14:52:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E5E11E8073; Thu, 9 Feb 2012 14:52:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209225206.1511.5897.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 14:52:06 -0800 Cc: pcn@ietf.org Subject: [PCN] Last Call: (Overview of Pre-Congestion Notification Encoding) to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 22:52:06 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'Overview of Pre-Congestion Notification Encoding' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcn-encoding-comparison/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcn-encoding-comparison/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Feb 9 15:40:08 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476FF21E806E; Thu, 9 Feb 2012 15:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 61IeLPBn-NzO; Thu, 9 Feb 2012 15:40:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50711E8080; Thu, 9 Feb 2012 15:40:07 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120209234007.18655.29449.idtracker@ietfa.amsl.com> Date: Thu, 09 Feb 2012 15:40:07 -0800 Cc: pcn@ietf.org Subject: [PCN] Last Call: (Encoding 3 PCN-States in the IP header using a single DSCP) to Proposed Standard X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:40:08 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'Encoding 3 PCN-States in the IP header using a single DSCP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to decision points which then decide whether to admit or block new flow requests or to terminate some already-admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding provides for up to three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC5696. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/ No IPR declarations have been submitted directly on this I-D. From tom.taylor.stds@gmail.com Thu Feb 9 19:17:13 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8191911E809C for ; Thu, 9 Feb 2012 19:17:13 -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 yVY23QC8E9YA for ; Thu, 9 Feb 2012 19:17:13 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 37B7B11E8075 for ; Thu, 9 Feb 2012 19:17:12 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2177199pbc.31 for ; Thu, 09 Feb 2012 19:17:12 -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 :content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=Icbq2ECeCjdbiZ2neF+ZdSowie3lGmOIy6JiPs4MAQ8=; b=wzcRBfLgwRbuI+tMPQd6Mvn0gqAXRiHreRNqepkpDB/xi7oqaHJInItRIbRFKYLTc0 Eiqi8Pp6Z3jMlng2QonDbdk+j6nPc3A+l+yVv9iYh/bcZwSHT5MFko5uUrc2Tu2GbOPO ys0Nh9IXTs6ZekRcMsLqTwwNfX53L5OqplUDo= Received: by 10.68.218.202 with SMTP id pi10mr12522005pbc.16.1328843832064; Thu, 09 Feb 2012 19:17:12 -0800 (PST) Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id e10sm10564960pbv.0.2012.02.09.19.17.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 19:17:11 -0800 (PST) Message-ID: <4F348C33.4020708@gmail.com> Date: Thu, 09 Feb 2012 22:17:07 -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 120209-3, 09/02/2012), Outbound message X-Antivirus-Status: Clean Cc: 'Brian Carpenter' Subject: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 03:17:13 -0000 In Brian Carpenter's GenArt review of the CL edge behaviour draft (but applicable to SM too), he noted the occurrence of the phrase "notify management" suggested that may indicate holes in the PCN state machine. This phrase is actually used in just two places: when the Decision Point times out waiting for a report from a PCN-egress-node, and when it times out waiting for one from a PCN-ingress-node. For the PCN-egress-node case, the suggested action up to now has been to stop admitting new flows to the affected ingress-egress-aggregates. This says nothing about packets belonging to already-admitted flows. Now that we are committed to using tunneling to define our ingress-egress-aggregates, this means that if the egress node is truly unreachable, the ingress nodes will get "Destination unreachable" notifications and will need to find alternative routes. That probably involves a request to the Decision Point for the alternatives, since the choice of egress node for particular flows is affected by business considerations. As a result of this reasoning, I decided to cut the process short and have the Decision Point impose new policy immediately upon timeout. Hence the following change in text. OLD: If timer t-recvFail expires for a given PCN-egress-node, the Decision Point SHOULD notify management. A Decision Point collocated with a PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- egress-aggregate associated with the given PCN-egress-node, until it again receives a report from that node. A centralized Decision Point MAY cease to admit PCN-flows to all ingress-egress-aggregates destined to the PCN-egress-node concerned, until it again receives a report from that node. NEW: If timer t-recvFail expires for a given PCN-egress-node, the Decision Point SHOULD notify management. In addition, the Decision Point SHOULD modify policy on the PCN-ingress-nodes under its control so that arriving packets that would be classified into the affected ingress-egress-aggregates are classified into alternate ingress-egress-aggregates. The Decision Point SHOULD restore normal classification as soon as it receives a report from the delinquent PCN-egress-node. This action probably requires pre-planning and pre-configuration of acceptable alternate egress points in the Decision Point. If rerouting to an alternate egress point does occur, it carries the risk that the alternate ingress-egress-aggregates exceed their supportable rate, necessitating flow termination. For the analogous case of an unresponsive PCN-ingress-node, I can't think of any action to be taken in the PCN-domain. The upstream network will be the one to find an alternate route. Comments? Tom Taylor From menth@informatik.uni-tuebingen.de Thu Feb 9 23:34: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 7201121F8757 for ; Thu, 9 Feb 2012 23:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vmnmT7iSIXr for ; Thu, 9 Feb 2012 23:34:57 -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 2E4A721F8754 for ; Thu, 9 Feb 2012 23:34:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id B92A35330 for ; Fri, 10 Feb 2012 08:34:48 +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 cjnRxPYJUWqD for ; Fri, 10 Feb 2012 08:34:44 +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 E4D2B5244 for ; Fri, 10 Feb 2012 08:34:43 +0100 (MET) Received: from [192.168.1.100] (HSI-KBW-085-216-071-070.hsi.kabelbw.de [85.216.71.70]) by zcs-pu.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6C88B1789675 for ; Fri, 10 Feb 2012 08:34:43 +0100 (CET) Message-ID: <4F34C894.5090404@informatik.uni-tuebingen.de> Date: Fri, 10 Feb 2012 08:34:44 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: pcn@ietf.org References: <4F348C33.4020708@gmail.com> In-Reply-To: <4F348C33.4020708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 07:34:58 -0000 Hi Tom, works for me. Best wishes, Michael Am 10.02.2012 04:17, schrieb Tom Taylor: > In Brian Carpenter's GenArt review of the CL edge behaviour draft (but > applicable to SM too), he noted the occurrence of the phrase "notify > management" suggested that may indicate holes in the PCN state > machine. This phrase is actually used in just two places: when the > Decision Point times out waiting for a report from a PCN-egress-node, > and when it times out waiting for one from a PCN-ingress-node. > > For the PCN-egress-node case, the suggested action up to now has been > to stop admitting new flows to the affected ingress-egress-aggregates. > This says nothing about packets belonging to already-admitted flows. > Now that we are committed to using tunneling to define our > ingress-egress-aggregates, this means that if the egress node is truly > unreachable, the ingress nodes will get "Destination unreachable" > notifications and will need to find alternative routes. That probably > involves a request to the Decision Point for the alternatives, since > the choice of egress node for particular flows is affected by business > considerations. > > As a result of this reasoning, I decided to cut the process short and > have the Decision Point impose new policy immediately upon timeout. > Hence the following change in text. > > OLD: > > If timer t-recvFail expires for a given PCN-egress-node, the Decision > Point SHOULD notify management. A Decision Point collocated with a > PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- > egress-aggregate associated with the given PCN-egress-node, until it > again receives a report from that node. A centralized Decision Point > MAY cease to admit PCN-flows to all ingress-egress-aggregates > destined to the PCN-egress-node concerned, until it again receives a > report from that node. > > NEW: > > If timer t-recvFail expires for a given PCN-egress-node, the > Decision Point SHOULD notify management. In addition, the > Decision Point SHOULD modify policy on the PCN-ingress-nodes > under its control so that arriving packets that would be > classified into the affected ingress-egress-aggregates > are classified into alternate ingress-egress-aggregates. > The Decision Point SHOULD restore normal classification as > soon as it receives a report from the delinquent PCN-egress-node. > > This action probably requires pre-planning and pre-configuration > of acceptable alternate egress points in the Decision Point. If > rerouting to an alternate egress point does occur, it carries > the risk that the alternate ingress-egress-aggregates exceed > their supportable rate, necessitating flow termination. > > For the analogous case of an unresponsive PCN-ingress-node, I can't > think of any action to be taken in the PCN-domain. The upstream > network will be the one to find an alternate route. > > Comments? > > 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 karagian@cs.utwente.nl Fri Feb 10 01:25: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 25E3721F8730 for ; Fri, 10 Feb 2012 01:25:31 -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 8vq8cxLr+l1j for ; Fri, 10 Feb 2012 01:25:30 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3306321F8738 for ; Fri, 10 Feb 2012 01:25:28 -0800 (PST) Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 10 Feb 2012 10:25:33 +0100 Received: from EXMBX04.ad.utwente.nl ([169.254.4.100]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.01.0339.001; Fri, 10 Feb 2012 10:25:25 +0100 From: To: , Thread-Topic: [PCN] Dealing with failure to receive reports Thread-Index: AQHM56KEdeMfvHSN60mZ+HAwQ0Lte5Y1rOEAgAAvTbA= Date: Fri, 10 Feb 2012 09:25:24 +0000 Message-ID: References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> In-Reply-To: <4F34C894.5090404@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 Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 09:25:31 -0000 Hi Tom, The modification is acceptable for me too! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: vrijdag 10 februari 2012 8:35 > To: pcn@ietf.org > Subject: Re: [PCN] Dealing with failure to receive reports >=20 > Hi Tom, >=20 > works for me. >=20 > Best wishes, >=20 > Michael >=20 > Am 10.02.2012 04:17, schrieb Tom Taylor: > > In Brian Carpenter's GenArt review of the CL edge behaviour draft (but > > applicable to SM too), he noted the occurrence of the phrase "notify > > management" suggested that may indicate holes in the PCN state > > machine. This phrase is actually used in just two places: when the > > Decision Point times out waiting for a report from a PCN-egress-node, > > and when it times out waiting for one from a PCN-ingress-node. > > > > For the PCN-egress-node case, the suggested action up to now has been > > to stop admitting new flows to the affected ingress-egress-aggregates. > > This says nothing about packets belonging to already-admitted flows. > > Now that we are committed to using tunneling to define our > > ingress-egress-aggregates, this means that if the egress node is truly > > unreachable, the ingress nodes will get "Destination unreachable" > > notifications and will need to find alternative routes. That probably > > involves a request to the Decision Point for the alternatives, since > > the choice of egress node for particular flows is affected by business > > considerations. > > > > As a result of this reasoning, I decided to cut the process short and > > have the Decision Point impose new policy immediately upon timeout. > > Hence the following change in text. > > > > OLD: > > > > If timer t-recvFail expires for a given PCN-egress-node, the Decisio= n > > Point SHOULD notify management. A Decision Point collocated with a > > PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- > > egress-aggregate associated with the given PCN-egress-node, until it > > again receives a report from that node. A centralized Decision Poin= t > > MAY cease to admit PCN-flows to all ingress-egress-aggregates > > destined to the PCN-egress-node concerned, until it again receives a > > report from that node. > > > > NEW: > > > > If timer t-recvFail expires for a given PCN-egress-node, the > > Decision Point SHOULD notify management. In addition, the > > Decision Point SHOULD modify policy on the PCN-ingress-nodes > > under its control so that arriving packets that would be > > classified into the affected ingress-egress-aggregates > > are classified into alternate ingress-egress-aggregates. > > The Decision Point SHOULD restore normal classification as > > soon as it receives a report from the delinquent PCN-egress-node. > > > > This action probably requires pre-planning and pre-configuration > > of acceptable alternate egress points in the Decision Point. If > > rerouting to an alternate egress point does occur, it carries > > the risk that the alternate ingress-egress-aggregates exceed > > their supportable rate, necessitating flow termination. > > > > For the analogous case of an unresponsive PCN-ingress-node, I can't > > think of any action to be taken in the PCN-domain. The upstream > > network will be the one to find an alternate route. > > > > Comments? > > > > Tom Taylor > > > > _______________________________________________ > > 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 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From Ruediger.Geib@telekom.de Fri Feb 10 01:45: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 D688521F875C for ; Fri, 10 Feb 2012 01:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96fmkOya5hme for ; Fri, 10 Feb 2012 01:45:42 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id 87D9621F8757 for ; Fri, 10 Feb 2012 01:45:41 -0800 (PST) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 10 Feb 2012 10:43:54 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.157]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 10 Feb 2012 10:43:54 +0100 From: To: Date: Fri, 10 Feb 2012 10:43:53 +0100 Thread-Topic: [PCN] Dealing with failure to receive reports Thread-Index: AcznxoFXV7Eebu0hSBiZIriHufQGGQAB0wdw Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> In-Reply-To: <4F34C894.5090404@informatik.uni-tuebingen.de> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 09:45:43 -0000 Michael, Tom, don't we run the risk to replace a not well defined "notify management" by a not well defined "alternate ingress-egress-aggregate"? Do we have to recommend or discuss set up of an alternate IEA tunnel in at least one of our documents? Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Micha= el Menth Sent: Friday, February 10, 2012 8:35 AM To: pcn@ietf.org Subject: Re: [PCN] Dealing with failure to receive reports Hi Tom, works for me. Best wishes, Michael Am 10.02.2012 04:17, schrieb Tom Taylor: > In Brian Carpenter's GenArt review of the CL edge behaviour draft (but > applicable to SM too), he noted the occurrence of the phrase "notify > management" suggested that may indicate holes in the PCN state > machine. This phrase is actually used in just two places: when the > Decision Point times out waiting for a report from a PCN-egress-node, > and when it times out waiting for one from a PCN-ingress-node. > > For the PCN-egress-node case, the suggested action up to now has been > to stop admitting new flows to the affected ingress-egress-aggregates. > This says nothing about packets belonging to already-admitted flows. > Now that we are committed to using tunneling to define our > ingress-egress-aggregates, this means that if the egress node is truly > unreachable, the ingress nodes will get "Destination unreachable" > notifications and will need to find alternative routes. That probably > involves a request to the Decision Point for the alternatives, since > the choice of egress node for particular flows is affected by business > considerations. > > As a result of this reasoning, I decided to cut the process short and > have the Decision Point impose new policy immediately upon timeout. > Hence the following change in text. > > OLD: > > If timer t-recvFail expires for a given PCN-egress-node, the Decision > Point SHOULD notify management. A Decision Point collocated with a > PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- > egress-aggregate associated with the given PCN-egress-node, until it > again receives a report from that node. A centralized Decision Point > MAY cease to admit PCN-flows to all ingress-egress-aggregates > destined to the PCN-egress-node concerned, until it again receives a > report from that node. > > NEW: > > If timer t-recvFail expires for a given PCN-egress-node, the > Decision Point SHOULD notify management. In addition, the > Decision Point SHOULD modify policy on the PCN-ingress-nodes > under its control so that arriving packets that would be > classified into the affected ingress-egress-aggregates > are classified into alternate ingress-egress-aggregates. > The Decision Point SHOULD restore normal classification as > soon as it receives a report from the delinquent PCN-egress-node. > > This action probably requires pre-planning and pre-configuration > of acceptable alternate egress points in the Decision Point. If > rerouting to an alternate egress point does occur, it carries > the risk that the alternate ingress-egress-aggregates exceed > their supportable rate, necessitating flow termination. > > For the analogous case of an unresponsive PCN-ingress-node, I can't > think of any action to be taken in the PCN-domain. The upstream > network will be the one to find an alternate route. > > Comments? > > 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-tuebingen.de Fri Feb 10 02:10: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 662B121F84F8 for ; Fri, 10 Feb 2012 02:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 KrwXwvstvDEP for ; Fri, 10 Feb 2012 02:10:41 -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 604A921F854D for ; Fri, 10 Feb 2012 02:10:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3BE705331; Fri, 10 Feb 2012 11:10:27 +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 itqYot+haQ8I; Fri, 10 Feb 2012 11:10:23 +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 4EC385244; Fri, 10 Feb 2012 11:10:23 +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 79D0A1789FFC; Fri, 10 Feb 2012 11:10:22 +0100 (CET) Message-ID: <4F34ED0F.9070406@informatik.uni-tuebingen.de> Date: Fri, 10 Feb 2012 11:10:23 +0100 From: Michael Menth User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Ruediger.Geib@telekom.de, brian.e.carpenter@gmail.com References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: pcn@ietf.org Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 10:10:42 -0000 Hi R=FCdiger, my understanding of Tom's interpretation of Brian's "hole in the state=20 machine" is that it is not clear what happens to the admitted PCN=20 traffic when PCN edge nodes seem not to be reachable anymore. Rerouting=20 seems a valid option to me. Maybe we should know what Brian means with the "hole in the state=20 machine" in order to fix it? Brian, can you help, please? Best wishes, Michael Am 10.02.2012 10:43, schrieb Ruediger.Geib@telekom.de: > Michael, Tom, > > don't we run the risk to replace a not well defined "notify management" > by a not well defined "alternate ingress-egress-aggregate"? > > Do we have to recommend or discuss set up of an alternate IEA tunnel > in at least one of our documents? > > Regards, > > Ruediger > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of M= ichael Menth > Sent: Friday, February 10, 2012 8:35 AM > To: pcn@ietf.org > Subject: Re: [PCN] Dealing with failure to receive reports > > Hi Tom, > > works for me. > > Best wishes, > > Michael > > Am 10.02.2012 04:17, schrieb Tom Taylor: >> In Brian Carpenter's GenArt review of the CL edge behaviour draft (but >> applicable to SM too), he noted the occurrence of the phrase "notify >> management" suggested that may indicate holes in the PCN state >> machine. This phrase is actually used in just two places: when the >> Decision Point times out waiting for a report from a PCN-egress-node, >> and when it times out waiting for one from a PCN-ingress-node. >> >> For the PCN-egress-node case, the suggested action up to now has been >> to stop admitting new flows to the affected ingress-egress-aggregates. >> This says nothing about packets belonging to already-admitted flows. >> Now that we are committed to using tunneling to define our >> ingress-egress-aggregates, this means that if the egress node is truly >> unreachable, the ingress nodes will get "Destination unreachable" >> notifications and will need to find alternative routes. That probably >> involves a request to the Decision Point for the alternatives, since >> the choice of egress node for particular flows is affected by business >> considerations. >> >> As a result of this reasoning, I decided to cut the process short and >> have the Decision Point impose new policy immediately upon timeout. >> Hence the following change in text. >> >> OLD: >> >> If timer t-recvFail expires for a given PCN-egress-node, the Decis= ion >> Point SHOULD notify management. A Decision Point collocated with = a >> PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- >> egress-aggregate associated with the given PCN-egress-node, until = it >> again receives a report from that node. A centralized Decision Po= int >> MAY cease to admit PCN-flows to all ingress-egress-aggregates >> destined to the PCN-egress-node concerned, until it again receives= a >> report from that node. >> >> NEW: >> >> If timer t-recvFail expires for a given PCN-egress-node, the >> Decision Point SHOULD notify management. In addition, the >> Decision Point SHOULD modify policy on the PCN-ingress-nodes >> under its control so that arriving packets that would be >> classified into the affected ingress-egress-aggregates >> are classified into alternate ingress-egress-aggregates. >> The Decision Point SHOULD restore normal classification as >> soon as it receives a report from the delinquent PCN-egress-node. >> >> This action probably requires pre-planning and pre-configuratio= n >> of acceptable alternate egress points in the Decision Point. If >> rerouting to an alternate egress point does occur, it carries >> the risk that the alternate ingress-egress-aggregates exceed >> their supportable rate, necessitating flow termination. >> >> For the analogous case of an unresponsive PCN-ingress-node, I can't >> think of any action to be taken in the PCN-domain. The upstream >> network will be the one to find an alternate route. >> >> Comments? >> >> 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 > > _______________________________________________ > 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 tm444@hermes.cam.ac.uk Fri Feb 10 02:21: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 9E26621F864E for ; Fri, 10 Feb 2012 02:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 F9S0oySb8t14 for ; Fri, 10 Feb 2012 02:21:04 -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 ED28421F8620 for ; Fri, 10 Feb 2012 02:21:03 -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]:51656) 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 1Rvnb9-0008Qw-YO (Exim 4.72) (return-path ); Fri, 10 Feb 2012 10:20:59 +0000 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Toby Moncaster In-Reply-To: <4F34ED0F.9070406@informatik.uni-tuebingen.de> Date: Fri, 10 Feb 2012 10:21:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8A9270E1-5CEB-44E0-B738-54F97ACCF0A3@cl.cam.ac.uk> References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> <4F34ED0F.9070406@informatik.uni-tuebingen.de> To: Michael Menth X-Mailer: Apple Mail (2.1257) Sender: "T. Moncaster" Cc: pcn@ietf.org, brian.e.carpenter@gmail.com Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 10:21:05 -0000 Could we add something like this at the beginning to make it clear: If timer t-recvFail expires for a given PCN-egress node it is no longer = clear whether that node can support the already-admitted IEAs. The = precise behaviour in this case is a matter of policy but this document = recommends the following:=20 Toby On 10 Feb 2012, at 10:10, Michael Menth wrote: > Hi R=FCdiger, >=20 > my understanding of Tom's interpretation of Brian's "hole in the state = machine" is that it is not clear what happens to the admitted PCN = traffic when PCN edge nodes seem not to be reachable anymore. Rerouting = seems a valid option to me. >=20 > Maybe we should know what Brian means with the "hole in the state = machine" in order to fix it? >=20 > Brian, can you help, please? >=20 > Best wishes, >=20 > Michael >=20 > Am 10.02.2012 10:43, schrieb Ruediger.Geib@telekom.de: >> Michael, Tom, >>=20 >> don't we run the risk to replace a not well defined "notify = management" >> by a not well defined "alternate ingress-egress-aggregate"? >>=20 >> Do we have to recommend or discuss set up of an alternate IEA tunnel >> in at least one of our documents? >>=20 >> Regards, >>=20 >> Ruediger >>=20 >>=20 >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Michael Menth >> Sent: Friday, February 10, 2012 8:35 AM >> To: pcn@ietf.org >> Subject: Re: [PCN] Dealing with failure to receive reports >>=20 >> Hi Tom, >>=20 >> works for me. >>=20 >> Best wishes, >>=20 >> Michael >>=20 >> Am 10.02.2012 04:17, schrieb Tom Taylor: >>> In Brian Carpenter's GenArt review of the CL edge behaviour draft = (but >>> applicable to SM too), he noted the occurrence of the phrase "notify >>> management" suggested that may indicate holes in the PCN state >>> machine. This phrase is actually used in just two places: when the >>> Decision Point times out waiting for a report from a = PCN-egress-node, >>> and when it times out waiting for one from a PCN-ingress-node. >>>=20 >>> For the PCN-egress-node case, the suggested action up to now has = been >>> to stop admitting new flows to the affected = ingress-egress-aggregates. >>> This says nothing about packets belonging to already-admitted flows. >>> Now that we are committed to using tunneling to define our >>> ingress-egress-aggregates, this means that if the egress node is = truly >>> unreachable, the ingress nodes will get "Destination unreachable" >>> notifications and will need to find alternative routes. That = probably >>> involves a request to the Decision Point for the alternatives, since >>> the choice of egress node for particular flows is affected by = business >>> considerations. >>>=20 >>> As a result of this reasoning, I decided to cut the process short = and >>> have the Decision Point impose new policy immediately upon timeout. >>> Hence the following change in text. >>>=20 >>> OLD: >>>=20 >>> If timer t-recvFail expires for a given PCN-egress-node, the = Decision >>> Point SHOULD notify management. A Decision Point collocated with = a >>> PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- >>> egress-aggregate associated with the given PCN-egress-node, until = it >>> again receives a report from that node. A centralized Decision = Point >>> MAY cease to admit PCN-flows to all ingress-egress-aggregates >>> destined to the PCN-egress-node concerned, until it again = receives a >>> report from that node. >>>=20 >>> NEW: >>>=20 >>> If timer t-recvFail expires for a given PCN-egress-node, the >>> Decision Point SHOULD notify management. In addition, the >>> Decision Point SHOULD modify policy on the PCN-ingress-nodes >>> under its control so that arriving packets that would be >>> classified into the affected ingress-egress-aggregates >>> are classified into alternate ingress-egress-aggregates. >>> The Decision Point SHOULD restore normal classification as >>> soon as it receives a report from the delinquent PCN-egress-node. >>>=20 >>> This action probably requires pre-planning and = pre-configuration >>> of acceptable alternate egress points in the Decision Point. = If >>> rerouting to an alternate egress point does occur, it carries >>> the risk that the alternate ingress-egress-aggregates exceed >>> their supportable rate, necessitating flow termination. >>>=20 >>> For the analogous case of an unresponsive PCN-ingress-node, I can't >>> think of any action to be taken in the PCN-domain. The upstream >>> network will be the one to find an alternate route. >>>=20 >>> Comments? >>>=20 >>> Tom Taylor >>>=20 >>> _______________________________________________ >>> 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 >>=20 >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >=20 > --=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 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From tom.taylor.stds@gmail.com Fri Feb 10 08:43: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 7369221F863E for ; Fri, 10 Feb 2012 08:43: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 Zb6ELBELHUQO for ; Fri, 10 Feb 2012 08:43:38 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3835F21F8636 for ; Fri, 10 Feb 2012 08:43:38 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2684827pbc.31 for ; Fri, 10 Feb 2012 08:43:38 -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=jhsljaSwbd8762ReXWJGZbm8zPE6ziJKeE6vU/199yg=; b=sMAkhHfyyg1QjqWPWsLossL3hNTr5ApRU07eeL6s0u3YAonwUCBFJ/UC6nAB5qZO6l UwK/q4zdwLK5ssx1t67QPt8yi03ApGKH3CwiIXNOh839dIOmXzppx7HtuY5S9pbP28uw J+w9yEzGh5f+ev3XBHvD7HOL0mbvfmzxlzDYA= Received: by 10.68.219.138 with SMTP id po10mr17934953pbc.81.1328892217981; Fri, 10 Feb 2012 08:43:37 -0800 (PST) Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id g6sm607502pbq.6.2012.02.10.08.43.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 08:43:37 -0800 (PST) Message-ID: <4F354936.1090203@gmail.com> Date: Fri, 10 Feb 2012 11:43:34 -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: Ruediger.Geib@telekom.de References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120210-0, 10/02/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 16:43:39 -0000 I suppose I assumed all ingress nodes were already connected to all egress nodes, but you're right, that is not necessarily so. The whole thing is messy, because it is quite possible unreachability is already detected before the Decision Point times out and action has already been required. Of course, "SHOULD" covers the possibility that a switch to alternate egress point has already occurred. But that doesn't address your basic point. I'll add discussion of setting up alternate tunnels in the Ops and Management section. On 10/02/2012 4:43 AM, Ruediger.Geib@telekom.de wrote: > Michael, Tom, > > don't we run the risk to replace a not well defined "notify management" > by a not well defined "alternate ingress-egress-aggregate"? > > Do we have to recommend or discuss set up of an alternate IEA tunnel > in at least one of our documents? > > Regards, > > Ruediger > > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth > Sent: Friday, February 10, 2012 8:35 AM > To: pcn@ietf.org > Subject: Re: [PCN] Dealing with failure to receive reports > > Hi Tom, > > works for me. > > Best wishes, > > Michael > > Am 10.02.2012 04:17, schrieb Tom Taylor: >> In Brian Carpenter's GenArt review of the CL edge behaviour draft (but >> applicable to SM too), he noted the occurrence of the phrase "notify >> management" suggested that may indicate holes in the PCN state >> machine. This phrase is actually used in just two places: when the >> Decision Point times out waiting for a report from a PCN-egress-node, >> and when it times out waiting for one from a PCN-ingress-node. >> >> For the PCN-egress-node case, the suggested action up to now has been >> to stop admitting new flows to the affected ingress-egress-aggregates. >> This says nothing about packets belonging to already-admitted flows. >> Now that we are committed to using tunneling to define our >> ingress-egress-aggregates, this means that if the egress node is truly >> unreachable, the ingress nodes will get "Destination unreachable" >> notifications and will need to find alternative routes. That probably >> involves a request to the Decision Point for the alternatives, since >> the choice of egress node for particular flows is affected by business >> considerations. >> >> As a result of this reasoning, I decided to cut the process short and >> have the Decision Point impose new policy immediately upon timeout. >> Hence the following change in text. >> >> OLD: >> >> If timer t-recvFail expires for a given PCN-egress-node, the Decision >> Point SHOULD notify management. A Decision Point collocated with a >> PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- >> egress-aggregate associated with the given PCN-egress-node, until it >> again receives a report from that node. A centralized Decision Point >> MAY cease to admit PCN-flows to all ingress-egress-aggregates >> destined to the PCN-egress-node concerned, until it again receives a >> report from that node. >> >> NEW: >> >> If timer t-recvFail expires for a given PCN-egress-node, the >> Decision Point SHOULD notify management. In addition, the >> Decision Point SHOULD modify policy on the PCN-ingress-nodes >> under its control so that arriving packets that would be >> classified into the affected ingress-egress-aggregates >> are classified into alternate ingress-egress-aggregates. >> The Decision Point SHOULD restore normal classification as >> soon as it receives a report from the delinquent PCN-egress-node. >> >> This action probably requires pre-planning and pre-configuration >> of acceptable alternate egress points in the Decision Point. If >> rerouting to an alternate egress point does occur, it carries >> the risk that the alternate ingress-egress-aggregates exceed >> their supportable rate, necessitating flow termination. >> >> For the analogous case of an unresponsive PCN-ingress-node, I can't >> think of any action to be taken in the PCN-domain. The upstream >> network will be the one to find an alternate route. >> >> Comments? >> >> 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 > > _______________________________________________ > 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 tom.taylor.stds@gmail.com Fri Feb 10 08:45: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 963F021F86DA for ; Fri, 10 Feb 2012 08:45:10 -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 nwYlJ1bagG-P for ; Fri, 10 Feb 2012 08:45:09 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B32E821F8636 for ; Fri, 10 Feb 2012 08:45:08 -0800 (PST) Received: by dakl33 with SMTP id l33so2620100dak.31 for ; Fri, 10 Feb 2012 08:45:08 -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=oio8zlVKx5gLKN3to6kXXX3deUKcqY9q9AJwuBvK0bw=; b=QyUT4Nn7Vs03u1DMgC1dHtZN/75Otkj7LmLiX7RPQw5LZLNtExc+JWrrYSDGU+35gF lk5hVAow+hFewSpikBjGH3MBaEv4Pri96jlZpt8GpTU6aqKA5ug8rQXNowmtQy7ELGMf zw8oaNJ/RiaIFWWzo+jXQcvQD+LNLzNtfbbro= Received: by 10.68.72.138 with SMTP id d10mr16385421pbv.15.1328892308303; Fri, 10 Feb 2012 08:45:08 -0800 (PST) Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id 7sm14855484pbw.13.2012.02.10.08.45.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 08:45:07 -0800 (PST) Message-ID: <4F354992.6050507@gmail.com> Date: Fri, 10 Feb 2012 11:45:06 -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: Toby Moncaster References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> <4F34ED0F.9070406@informatik.uni-tuebingen.de> <8A9270E1-5CEB-44E0-B738-54F97ACCF0A3@cl.cam.ac.uk> In-Reply-To: <8A9270E1-5CEB-44E0-B738-54F97ACCF0A3@cl.cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120210-0, 10/02/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org, brian.e.carpenter@gmail.com Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 16:45:10 -0000 I like this. On 10/02/2012 5:21 AM, Toby Moncaster wrote: > > Could we add something like this at the beginning to make it clear: > > If timer t-recvFail expires for a given PCN-egress node it is no > longer clear whether that node can support the already-admitted IEAs. > The precise behaviour in this case is a matter of policy but this > document recommends the following: > > > Toby > > On 10 Feb 2012, at 10:10, Michael Menth wrote: > >> Hi Rüdiger, >> >> my understanding of Tom's interpretation of Brian's "hole in the >> state machine" is that it is not clear what happens to the admitted >> PCN traffic when PCN edge nodes seem not to be reachable anymore. >> Rerouting seems a valid option to me. >> >> Maybe we should know what Brian means with the "hole in the state >> machine" in order to fix it? >> >> Brian, can you help, please? >> >> Best wishes, >> >> Michael >> >> Am 10.02.2012 10:43, schrieb Ruediger.Geib@telekom.de: >>> Michael, Tom, >>> >>> don't we run the risk to replace a not well defined "notify >>> management" by a not well defined "alternate >>> ingress-egress-aggregate"? >>> >>> Do we have to recommend or discuss set up of an alternate IEA >>> tunnel in at least one of our documents? >>> >>> Regards, >>> >>> Ruediger >>> >>> >>> -----Original Message----- From: pcn-bounces@ietf.org >>> [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: >>> Friday, February 10, 2012 8:35 AM To: pcn@ietf.org Subject: Re: >>> [PCN] Dealing with failure to receive reports >>> >>> Hi Tom, >>> >>> works for me. >>> >>> Best wishes, >>> >>> Michael >>> >>> Am 10.02.2012 04:17, schrieb Tom Taylor: >>>> In Brian Carpenter's GenArt review of the CL edge behaviour >>>> draft (but applicable to SM too), he noted the occurrence of >>>> the phrase "notify management" suggested that may indicate >>>> holes in the PCN state machine. This phrase is actually used in >>>> just two places: when the Decision Point times out waiting for >>>> a report from a PCN-egress-node, and when it times out waiting >>>> for one from a PCN-ingress-node. >>>> >>>> For the PCN-egress-node case, the suggested action up to now >>>> has been to stop admitting new flows to the affected >>>> ingress-egress-aggregates. This says nothing about packets >>>> belonging to already-admitted flows. Now that we are committed >>>> to using tunneling to define our ingress-egress-aggregates, >>>> this means that if the egress node is truly unreachable, the >>>> ingress nodes will get "Destination unreachable" notifications >>>> and will need to find alternative routes. That probably >>>> involves a request to the Decision Point for the alternatives, >>>> since the choice of egress node for particular flows is >>>> affected by business considerations. >>>> >>>> As a result of this reasoning, I decided to cut the process >>>> short and have the Decision Point impose new policy immediately >>>> upon timeout. Hence the following change in text. >>>> >>>> OLD: >>>> >>>> If timer t-recvFail expires for a given PCN-egress-node, the >>>> Decision Point SHOULD notify management. A Decision Point >>>> collocated with a PCN-ingress-node SHOULD cease to admit >>>> PCN-flows to the ingress- egress-aggregate associated with the >>>> given PCN-egress-node, until it again receives a report from >>>> that node. A centralized Decision Point MAY cease to admit >>>> PCN-flows to all ingress-egress-aggregates destined to the >>>> PCN-egress-node concerned, until it again receives a report >>>> from that node. >>>> >>>> NEW: >>>> >>>> If timer t-recvFail expires for a given PCN-egress-node, the >>>> Decision Point SHOULD notify management. In addition, the >>>> Decision Point SHOULD modify policy on the PCN-ingress-nodes >>>> under its control so that arriving packets that would be >>>> classified into the affected ingress-egress-aggregates are >>>> classified into alternate ingress-egress-aggregates. The >>>> Decision Point SHOULD restore normal classification as soon as >>>> it receives a report from the delinquent PCN-egress-node. >>>> >>>> This action probably requires pre-planning and >>>> pre-configuration of acceptable alternate egress points in the >>>> Decision Point. If rerouting to an alternate egress point does >>>> occur, it carries the risk that the alternate >>>> ingress-egress-aggregates exceed their supportable rate, >>>> necessitating flow termination. >>>> >>>> For the analogous case of an unresponsive PCN-ingress-node, I >>>> can't think of any action to be taken in the PCN-domain. The >>>> upstream network will be the one to find an alternate route. >>>> >>>> Comments? >>>> >>>> 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 >>> >>> _______________________________________________ PCN mailing list >>> PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn >> >> -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty >> of Science Department of Computer Science Chair of Communication >> Networks Sand 13, 72076 Tuebingen, Germany phone: >> (+49)-7071/29-70505 fax: (+49)-7071/29-5220 >> mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de >> >> _______________________________________________ PCN mailing list >> PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn > > _______________________________________________ PCN mailing list > PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn > From tom.taylor.stds@gmail.com Fri Feb 10 08:49:46 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3951B21F86DA for ; Fri, 10 Feb 2012 08:49:46 -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 wgXomTnRFval for ; Fri, 10 Feb 2012 08:49:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 566CC21F8569 for ; Fri, 10 Feb 2012 08:48:43 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so2688388pbc.31 for ; Fri, 10 Feb 2012 08:48: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=NSvtPQeet2QF7RzzbxX1XdZyMQoxFFZ+WwfssUSbNFY=; b=u4Oph8vxmC3sJChCRE68xpcWF0IQA7b0+/pMo/4+OkGttMOv+dWPAtd0b6rvP0dJL2 f9uNdySt/kUdjmNOKDKa6Yk9YhUJN8WL+E3YmlmW7kO2OFCpRupar/qvqdkvuNXOUMg3 SYxykZRJ3QglHZH7iRecqE72u6ik867ma4m+s= Received: by 10.68.239.229 with SMTP id vv5mr17689775pbc.88.1328892520185; Fri, 10 Feb 2012 08:48:40 -0800 (PST) Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id b4sm11862528pbc.7.2012.02.10.08.48.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 08:48:39 -0800 (PST) Message-ID: <4F354A66.3050700@gmail.com> Date: Fri, 10 Feb 2012 11:48: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: Michael Menth References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> <4F34ED0F.9070406@informatik.uni-tuebingen.de> In-Reply-To: <4F34ED0F.9070406@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120210-0, 10/02/2012), Outbound message X-Antivirus-Status: Clean Cc: pcn@ietf.org, brian.e.carpenter@gmail.com Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 16:49:46 -0000 Brian can speak up on this, but it occurred to me after I sent my message that what he meant perhaps was what happened to flows that were not admitted. That's pretty basic, and I expect the architecture document discusses it, but I have to check. On 10/02/2012 5:10 AM, Michael Menth wrote: > Hi Rüdiger, > > my understanding of Tom's interpretation of Brian's "hole in the state > machine" is that it is not clear what happens to the admitted PCN > traffic when PCN edge nodes seem not to be reachable anymore. Rerouting > seems a valid option to me. > > Maybe we should know what Brian means with the "hole in the state > machine" in order to fix it? > > Brian, can you help, please? > > Best wishes, > > Michael > > Am 10.02.2012 10:43, schrieb Ruediger.Geib@telekom.de: >> Michael, Tom, >> >> don't we run the risk to replace a not well defined "notify management" >> by a not well defined "alternate ingress-egress-aggregate"? >> >> Do we have to recommend or discuss set up of an alternate IEA tunnel >> in at least one of our documents? >> >> Regards, >> >> Ruediger >> >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Michael Menth >> Sent: Friday, February 10, 2012 8:35 AM >> To: pcn@ietf.org >> Subject: Re: [PCN] Dealing with failure to receive reports >> >> Hi Tom, >> >> works for me. >> >> Best wishes, >> >> Michael >> >> Am 10.02.2012 04:17, schrieb Tom Taylor: >>> In Brian Carpenter's GenArt review of the CL edge behaviour draft (but >>> applicable to SM too), he noted the occurrence of the phrase "notify >>> management" suggested that may indicate holes in the PCN state >>> machine. This phrase is actually used in just two places: when the >>> Decision Point times out waiting for a report from a PCN-egress-node, >>> and when it times out waiting for one from a PCN-ingress-node. >>> >>> For the PCN-egress-node case, the suggested action up to now has been >>> to stop admitting new flows to the affected ingress-egress-aggregates. >>> This says nothing about packets belonging to already-admitted flows. >>> Now that we are committed to using tunneling to define our >>> ingress-egress-aggregates, this means that if the egress node is truly >>> unreachable, the ingress nodes will get "Destination unreachable" >>> notifications and will need to find alternative routes. That probably >>> involves a request to the Decision Point for the alternatives, since >>> the choice of egress node for particular flows is affected by business >>> considerations. >>> >>> As a result of this reasoning, I decided to cut the process short and >>> have the Decision Point impose new policy immediately upon timeout. >>> Hence the following change in text. >>> >>> OLD: >>> >>> If timer t-recvFail expires for a given PCN-egress-node, the Decision >>> Point SHOULD notify management. A Decision Point collocated with a >>> PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- >>> egress-aggregate associated with the given PCN-egress-node, until it >>> again receives a report from that node. A centralized Decision Point >>> MAY cease to admit PCN-flows to all ingress-egress-aggregates >>> destined to the PCN-egress-node concerned, until it again receives a >>> report from that node. >>> >>> NEW: >>> >>> If timer t-recvFail expires for a given PCN-egress-node, the >>> Decision Point SHOULD notify management. In addition, the >>> Decision Point SHOULD modify policy on the PCN-ingress-nodes >>> under its control so that arriving packets that would be >>> classified into the affected ingress-egress-aggregates >>> are classified into alternate ingress-egress-aggregates. >>> The Decision Point SHOULD restore normal classification as >>> soon as it receives a report from the delinquent PCN-egress-node. >>> >>> This action probably requires pre-planning and pre-configuration >>> of acceptable alternate egress points in the Decision Point. If >>> rerouting to an alternate egress point does occur, it carries >>> the risk that the alternate ingress-egress-aggregates exceed >>> their supportable rate, necessitating flow termination. >>> >>> For the analogous case of an unresponsive PCN-ingress-node, I can't >>> think of any action to be taken in the PCN-domain. The upstream >>> network will be the one to find an alternate route. >>> >>> Comments? >>> >>> 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 >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > From brian.e.carpenter@gmail.com Fri Feb 10 10:59:21 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C10221F880B for ; Fri, 10 Feb 2012 10:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 Dsc1OPHJYxOl for ; Fri, 10 Feb 2012 10:59:20 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3E921F8804 for ; Fri, 10 Feb 2012 10:59:19 -0800 (PST) Received: by eekc41 with SMTP id c41so1064277eek.31 for ; Fri, 10 Feb 2012 10:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oOYN2XZJgtjyYtyS31yjsqtxhVsRSUq0mgYzSCwBzLk=; b=uho5vHjfb1UqLuYY445sbc/mzFjHze4ms4p8WW3IhAxMx7JFYqJAmHaKBO1/zSmivt Vpyr1yq4e/Cm7uf08ZuqiOGvYwQPdCTK/MP863tSiRpu6wPEMHjRSrRKWeNMdiU0cGTp KRcavCNojaCc/5qq3oHIAhK4oNrMBtwiDZxWA= Received: by 10.14.39.207 with SMTP id d55mr2436698eeb.36.1328900359045; Fri, 10 Feb 2012 10:59:19 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a58sm25149166eeb.8.2012.02.10.10.59.15 (version=SSLv3 cipher=OTHER); Fri, 10 Feb 2012 10:59:18 -0800 (PST) Message-ID: <4F3568F7.7060104@gmail.com> Date: Sat, 11 Feb 2012 07:59:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tom Taylor References: <4F348C33.4020708@gmail.com> <4F34C894.5090404@informatik.uni-tuebingen.de> <580BEA5E3B99744AB1F5BFF5E9A3C67D135DC18CD5@HE111648.emea1.cds.t-internal.com> <4F34ED0F.9070406@informatik.uni-tuebingen.de> <4F354A66.3050700@gmail.com> In-Reply-To: <4F354A66.3050700@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 10 Feb 2012 12:13:22 -0800 Cc: pcn@ietf.org Subject: Re: [PCN] Dealing with failure to receive reports 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, 10 Feb 2012 18:59:21 -0000 Tom, That is part of it; the other part is what the thread that has 'notified management' does next - I suppose it discards state and terminates? In any case, saying that it's locally defined rather than standardised would be fine for me. When I make this sort of comment, I'm trying to stand in the shoes of someone writing code who has nothing but the RFC to go by. Saying that it's local policy is fine, because then the implementer gets to decide. Regards Brian Carpenter On 2012-02-11 05:48, Tom Taylor wrote: > Brian can speak up on this, but it occurred to me after I sent my > message that what he meant perhaps was what happened to flows that were= > not admitted. That's pretty basic, and I expect the architecture > document discusses it, but I have to check. >=20 > On 10/02/2012 5:10 AM, Michael Menth wrote: >> Hi R=C3=BCdiger, >> >> my understanding of Tom's interpretation of Brian's "hole in the state= >> machine" is that it is not clear what happens to the admitted PCN >> traffic when PCN edge nodes seem not to be reachable anymore. Reroutin= g >> seems a valid option to me. >> >> Maybe we should know what Brian means with the "hole in the state >> machine" in order to fix it? >> >> Brian, can you help, please? >> >> Best wishes, >> >> Michael >> >> Am 10.02.2012 10:43, schrieb Ruediger.Geib@telekom.de: >>> Michael, Tom, >>> >>> don't we run the risk to replace a not well defined "notify managemen= t" >>> by a not well defined "alternate ingress-egress-aggregate"? >>> >>> Do we have to recommend or discuss set up of an alternate IEA tunnel >>> in at least one of our documents? >>> >>> Regards, >>> >>> Ruediger >>> >>> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of= >>> Michael Menth >>> Sent: Friday, February 10, 2012 8:35 AM >>> To: pcn@ietf.org >>> Subject: Re: [PCN] Dealing with failure to receive reports >>> >>> Hi Tom, >>> >>> works for me. >>> >>> Best wishes, >>> >>> Michael >>> >>> Am 10.02.2012 04:17, schrieb Tom Taylor: >>>> In Brian Carpenter's GenArt review of the CL edge behaviour draft (b= ut >>>> applicable to SM too), he noted the occurrence of the phrase "notify= >>>> management" suggested that may indicate holes in the PCN state >>>> machine. This phrase is actually used in just two places: when the >>>> Decision Point times out waiting for a report from a PCN-egress-node= , >>>> and when it times out waiting for one from a PCN-ingress-node. >>>> >>>> For the PCN-egress-node case, the suggested action up to now has bee= n >>>> to stop admitting new flows to the affected ingress-egress-aggregate= s. >>>> This says nothing about packets belonging to already-admitted flows.= >>>> Now that we are committed to using tunneling to define our >>>> ingress-egress-aggregates, this means that if the egress node is tru= ly >>>> unreachable, the ingress nodes will get "Destination unreachable" >>>> notifications and will need to find alternative routes. That probabl= y >>>> involves a request to the Decision Point for the alternatives, since= >>>> the choice of egress node for particular flows is affected by busine= ss >>>> considerations. >>>> >>>> As a result of this reasoning, I decided to cut the process short an= d >>>> have the Decision Point impose new policy immediately upon timeout. >>>> Hence the following change in text. >>>> >>>> OLD: >>>> >>>> If timer t-recvFail expires for a given PCN-egress-node, the Decisio= n >>>> Point SHOULD notify management. A Decision Point collocated with a >>>> PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress- >>>> egress-aggregate associated with the given PCN-egress-node, until it= >>>> again receives a report from that node. A centralized Decision Point= >>>> MAY cease to admit PCN-flows to all ingress-egress-aggregates >>>> destined to the PCN-egress-node concerned, until it again receives a= >>>> report from that node. >>>> >>>> NEW: >>>> >>>> If timer t-recvFail expires for a given PCN-egress-node, the >>>> Decision Point SHOULD notify management. In addition, the >>>> Decision Point SHOULD modify policy on the PCN-ingress-nodes >>>> under its control so that arriving packets that would be >>>> classified into the affected ingress-egress-aggregates >>>> are classified into alternate ingress-egress-aggregates. >>>> The Decision Point SHOULD restore normal classification as >>>> soon as it receives a report from the delinquent PCN-egress-node. >>>> >>>> This action probably requires pre-planning and pre-configuration >>>> of acceptable alternate egress points in the Decision Point. If >>>> rerouting to an alternate egress point does occur, it carries >>>> the risk that the alternate ingress-egress-aggregates exceed >>>> their supportable rate, necessitating flow termination. >>>> >>>> For the analogous case of an unresponsive PCN-ingress-node, I can't >>>> think of any action to be taken in the PCN-domain. The upstream >>>> network will be the one to find an alternate route. >>>> >>>> Comments? >>>> >>>> Tom Taylor >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >> >=20 From iesg-secretary@ietf.org Tue Feb 21 12:12:57 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C643721F880C; Tue, 21 Feb 2012 12:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMWcq+ursPjC; Tue, 21 Feb 2012 12:12:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1BE21F8814; Tue, 21 Feb 2012 12:12:49 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120221201249.10290.40064.idtracker@ietfa.amsl.com> Date: Tue, 21 Feb 2012 12:12:49 -0800 Cc: pcn mailing list , pcn chair , RFC Editor Subject: [PCN] Document Action: 'Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain' to Informational RFC (draft-ietf-pcn-signaling-requirements-08.txt) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 20:12:57 -0000 The IESG has approved the following document: - 'Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain' (draft-ietf-pcn-signaling-requirements-08.txt) as an Informational RFC This document is the product of the Congestion and Pre-Congestion Notification Working Group. The IESG contact persons are David Harrington and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pcn-signaling-requirements/ Technical Summary PCN (RFC 5559) conveys pre-congestion information to an egress router via in-band packet marking. This document defines the requirements for signaling protocols that convey PCN feedback information from a PCN egress router to a PCN decision point, and between the decision point and a PCN ingress router (if they are not co-located). The signaling requirements apply specifically to the Single Marking [RFCXXXX] and Controlled Load PCN [RFCXXXX] edge behaviours. Working Group Summary The document was subject to thorough review by the PCN working group, and strong consensus for publication was reached. Document Quality As an Informational document, there are no implementations, but two companion documents are consistent with these signaling requirements. The document shepherd expects that there are additional requirements (e.g., congestion control) that are generic to any Internet protocol, that are not explicitly captured in this draft, but expects that as the working group begins to define (or adapt) one or more signaling protocols, that these requirements will be taken into account. There are references to draft-ietf-pcn-cl-edge-behaviour (Controlled Load) and draft-pcn-sm-edge-behaviour (Single Marking), which have also been submitted for publication. Personnel Document Shepherd: Steven Blake, PCN co-chair Responsible Area Director: David Harrington RFC Editor Note Please insert the appropriate RFC#s in any announcements and in the abstract of the document. From ietfdbh@comcast.net Wed Feb 22 04:49: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 1CBE921F87B2 for ; Wed, 22 Feb 2012 04:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.923 X-Spam-Level: X-Spam-Status: No, score=-101.923 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLcVoUDepQw9 for ; Wed, 22 Feb 2012 04:49:37 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0202121F87AD for ; Wed, 22 Feb 2012 04:49:36 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id czkC1i0031c6gX8510pdio; Wed, 22 Feb 2012 12:49:37 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta23.westchester.pa.mail.comcast.net with comcast id d0pa1i01l3Ecudz3j0pcn6; Wed, 22 Feb 2012 12:49:37 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 22 Feb 2012 07:49:33 -0500 From: David Harrington To: Message-ID: Thread-Topic: Document Action: 'Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain' to Informational RFC (draft-ietf-pcn-signaling-requirements-08.txt) In-Reply-To: <20120221201249.10290.40064.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [PCN] FW: Document Action: 'Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain' to Informational RFC (draft-ietf-pcn-signaling-requirements-08.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: Wed, 22 Feb 2012 12:49:39 -0000 Congratulations. Others on the way ;-) -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 2/21/12 3:12 PM, "The IESG" wrote: >The IESG has approved the following document: >- 'Requirements for Signaling of (Pre-) Congestion Information in a > DiffServ Domain' > (draft-ietf-pcn-signaling-requirements-08.txt) as an Informational RFC > >This document is the product of the Congestion and Pre-Congestion >Notification Working Group. > >The IESG contact persons are David Harrington and Wesley Eddy. > >A URL of this Internet Draft is: >http://datatracker.ietf.org/doc/draft-ietf-pcn-signaling-requirements/ > > > > >Technical Summary > >PCN (RFC 5559) conveys pre-congestion information to an egress >router via in-band packet marking. This document defines the >requirements for signaling protocols that convey PCN feedback >information from a PCN egress router to a PCN decision point, >and between the decision point and a PCN ingress router (if they >are not co-located). The signaling requirements apply specifically >to the Single Marking [RFCXXXX] and Controlled Load PCN >[RFCXXXX] edge behaviours. > >Working Group Summary > >The document was subject to thorough review by the PCN working >group, and strong consensus for publication was reached. > >Document Quality > >As an Informational document, there are no implementations, >but two companion documents are consistent with these signaling >requirements. > >The document shepherd expects that there are additional requirements >(e.g., congestion control) that are generic to any Internet >protocol, that are not explicitly captured in this draft, but >expects that as the working group begins to define (or adapt) >one or more signaling protocols, that these requirements will >be taken into account. > >There are references to draft-ietf-pcn-cl-edge-behaviour (Controlled >Load) and >draft-pcn-sm-edge-behaviour (Single Marking), which have also been >submitted for >publication. > >Personnel > >Document Shepherd: Steven Blake, PCN co-chair >Responsible Area Director: David Harrington > >RFC Editor Note > > Please insert the appropriate RFC#s in any announcements and in the >abstract of the document. > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From internet-drafts@ietf.org Wed Feb 22 11:53:50 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9110521E8010; Wed, 22 Feb 2012 11:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 3-lvnUO5ODCL; Wed, 22 Feb 2012 11:53:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080D121F86DE; Wed, 22 Feb 2012 11:53:35 -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.64p2 Message-ID: <20120222195335.29534.13958.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2012 11:53:35 -0800 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-cl-edge-behaviour-12.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: Wed, 22 Feb 2012 19:53:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Controlled Load (CL)= Mode of Operation Author(s) : Anna Charny Fortune Huang Georgios Karagiannis Michael Menth Tom Taylor Filename : draft-ietf-pcn-cl-edge-behaviour-12.txt Pages : 33 Date : 2012-02-22 Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-12.txt From tom.taylor.stds@gmail.com Wed Feb 22 11:54:57 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA0A21E800E; Wed, 22 Feb 2012 11:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 4ZEcfss9H-bu; Wed, 22 Feb 2012 11:54:56 -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 952A821E8010; Wed, 22 Feb 2012 11:54:51 -0800 (PST) Received: by yenm3 with SMTP id m3so299365yen.31 for ; Wed, 22 Feb 2012 11:54:51 -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=f29WNWi/gKEU9HsPx+6o3wlXumTPODmRfwjGhl5/8rI=; b=LSDKwb7pCv4sp4OSA6V2MrURPTbK33JdpW4MmBaNJr5skrFsJ+ayz69fTF98t2i38c j6b++dqTnOYw3cWSwRvULZ98QIrCL9ALpkCIydZpR7itgZtr+kU200mvBubWEff6+IkA UuADu4P4tkbfkDcXav0DXc3I5cWH9W1unGORc= Received: by 10.236.76.234 with SMTP id b70mr35071663yhe.125.1329940491184; Wed, 22 Feb 2012 11:54:51 -0800 (PST) Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id n12sm65161722yhe.10.2012.02.22.11.54.49 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 11:54:50 -0800 (PST) Message-ID: <4F454808.7000106@gmail.com> Date: Wed, 22 Feb 2012 14:54:48 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pcn , Fortune Huang , Anna Charny , Michael Menth , Georgios Karagiannis , "Joel M. Halpern" , 'Brian Carpenter' , gen-art@ietf.org, David Harrington Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120222-0, 22/02/2012), Outbound message X-Antivirus-Status: Clean Subject: [PCN] draft-ietf-pcn-cl-edge-behaviour-12.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: Wed, 22 Feb 2012 19:54:57 -0000 I have just submitted draft-ietf-pcn-cl-edge-behaviour-12.txt, incorporating responses to the Genart reviews by Joel Halpern and Brian Carpenter. Thanks to both of them for their suggestions. The set of changes to the CL edge behaviour draft is as follows: 1. Introduction =============== Added the following paragraph in response to a concern expressed by Brian. Further related text is described later. Note that the terms "block" or "terminate" actually translate to one or more of several possible courses of action, as discussed in Section 3.6 of RFC5559. The choice of which action to take for blocked or terminated flows is a matter of local policy. Deleted the following text from the RFC Editor's note, on Brian's recommendation: You may choose to delete the following paragraph and the "[CL-specific]" tags throughout this document when publishing it, since they are present primarily to aid reviewers. 3. Node Behaviours ================== Added the following paragraph at the end of the introductory text to this section: Section 5.1.2 describes how to derive the filters by means of which PCN-ingress-nodes and PCN-egress-nodes are able to classify incoming packets into ingress-egress-aggregates. 3.3.3. Decision Point Action For Missing PCN-Boundary-Node Reports ================================================================== Changed the paragraph dealing with egress node reporting timeouts: OLD If timer t-recvFail expires for a given PCN-egress-node, the Decision Point SHOULD notify management. A Decision Point collocated with a PCN-ingress-node SHOULD cease to admit PCN-flows to the ingress-egress-aggregate associated with the given PCN-egress-node, until it again receives a report from that node. A centralized Decision Point MAY cease to admit PCN-flows to all ingress-egress-aggregates destined to the PCN-egress-node concerned, until it again receives a report from that node. NEW If timer t-recvFail expires for a given PCN-egress-node, the Decision Point SHOULD notify management. A log format is defined for that purpose in Section 5.2.1.1. Other actions depend on local policy, but MAY include blocking of new flows destined for the PCN-egress-node concerned until another report is received from it. Termination of already-admitted flows is also possible, but could be triggered by the receipt of "Destination unreachable" messages at the PCN-ingress-node. 5.1.2. Specification of Node- and Link-Specific Parameters ========================================================== Replaced the first three paragraphs of this section: OLD Each PCN-ingress-node needs filters to classify incoming PCN packets according to ingress-egress-aggregate, both to satisfy Decision Point requests for sent traffic rates and, if applicable, to support encapsulation. If PCN packets are being tunneled to the PCN-egress- nodes (encapsulation), the PCN-ingress-node also needs the address of the PCN-egress-node for each ingress-egress-aggregate. Each PCN-egress-node needs filters to classify incoming PCN packets by ingress-egress-aggregate, in order to gather measurements on a per-aggregate basis. The PCN-egress-node also needs to know the address of the Decision Point to which it sends reports for each ingress-egress-aggregate. If [I-D.tsvwg-rsvp-pcn] is deployed and the Decision Points are collocated with the PCN-ingress-nodes, this information can be built up dynamically from the contents of the end-to-end RSVP signalling and does not have to be pre-configured. Otherwise the filters have to be derived from the routing tables in use in the domain, and the address of the peer at the other end of each ingress-egress-aggregate has to be tabulated for each PCN-edge-node. NEW Filters are required at both the PCN-ingress-node and the PCN-egress- node to classify incoming PCN packets by ingress-egress-aggregate. Because of the potential use of multi-path routing in domains upstream of the PCN-domain, it is impossible to do such classification reliably at the PCN-egress-node based on the packet header contents as originally received at the PCN-ingress-node. (Packets with the same header contents could enter the PCN-domain at multiple PCN-ingress-nodes.) As a result, the only way to construct such filters reliably is to tunnel the packets from the PCN-ingress- node to the PCN-egress-node. The PCN-ingress-node needs filters in order to place PCN packets into the right tunnel in the first instance, and also to satisfy requests from the Decision Point for admission rates into specific ingress- egress-aggregates. These filters select the PCN-egress-node, but not necessarily a specific path through the network to that node. As a result, they are likely to be stable even in the face of failures in the network, except when the PCN-egress-node itself becomes unreachable. The primary basis for their derivation will be routing policy given the packet's original origin and destination. Since all PCN packets will be tunneled, the PCN-ingress-node also needs to know the address of the peer PCN-egress-node associated with each filter. Operators may wish to give some thought to the provisioning of alternate egress points for some or all ingress-egress aggregates in case of failure of the PCN-egress-node. This could require the setting up of standby tunnels to these alternate egress points. Each PCN-egress-node needs filters to classify incoming PCN packets by ingress-egress-aggregate, in order to gather measurements on a per-aggregate basis. These filters are constructed on the basis of the identifier of the tunnel from which the incoming packet has emerged (e.g. the source address in the outer header if IP encapsulation is used). The PCN-egress-node also needs to know the address of the Decision Point to which it sends reports for each ingress-egress-aggregate. 5.2.1. Event Logging In the PCN Domain ======================================= Added the following paragraph: The field names (e.g., HOSTNAME, STRUCTURED-DATA) used in the following subsections are defined in [RFC5424]. From internet-drafts@ietf.org Wed Feb 22 12:43:24 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB6A21F8620; Wed, 22 Feb 2012 12:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 92oYwwS00XRH; Wed, 22 Feb 2012 12:43:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB94B21F861B; Wed, 22 Feb 2012 12:43:23 -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.64p2 Message-ID: <20120222204323.14996.38780.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2012 12:43:23 -0800 Cc: pcn@ietf.org Subject: [PCN] I-D Action: draft-ietf-pcn-sm-edge-behaviour-09.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:43:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion and Pre-Congestion Notific= ation Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Single Marking (SM) = Mode of Operation Author(s) : Anna Charny Georgios Karagiannis Michael Menth Tom Taylor Filename : draft-ietf-pcn-sm-edge-behaviour-09.txt Pages : 31 Date : 2012-02-22 Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN-boundary-node behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-09.txt From tom.taylor.stds@gmail.com Wed Feb 22 12:52:48 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB60E21F8646; Wed, 22 Feb 2012 12:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 AWmI4MR6-IKe; Wed, 22 Feb 2012 12:52:42 -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 BCC1421F8645; Wed, 22 Feb 2012 12:52:41 -0800 (PST) Received: by ghbg16 with SMTP id g16so337221ghb.31 for ; Wed, 22 Feb 2012 12:52: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=4NdT7uxsATCb6hXu58jf3v5IEv65hBtYGbZ0t+fnn6k=; b=ql4agwQMiHkYjBNgm2O+VaxqwYLOXScmz6SA1Z8GcYKtd4s9mwBT4F7tXt6M/gypvE HK27mDM0K3eJRWflEQ3+CfqSuZm0A6pXp4JZ4jyTZ0hUR5niowbAJlW//Aw4blHHuCGc 03/xl2bM+nTAgpGgT7IxcuDKwpjpigY4ucjtI= Received: by 10.236.37.132 with SMTP id y4mr36695182yha.10.1329943960827; Wed, 22 Feb 2012 12:52:40 -0800 (PST) Received: from [127.0.0.1] ([216.254.195.91]) by mx.google.com with ESMTPS id s10sm11821512anl.17.2012.02.22.12.52.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 12:52:40 -0800 (PST) Message-ID: <4F455597.2060104@gmail.com> Date: Wed, 22 Feb 2012 15:52:39 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: pcn , Anna Charny , Georgios Karagiannis , Michael Menth , "Joel M. Halpern" , 'Brian Carpenter' , David Harrington , Gen Art Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120222-0, 22/02/2012), Outbound message X-Antivirus-Status: Clean Subject: [PCN] draft-ietf-pcn-sm-edge-behaviour-09 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, 22 Feb 2012 20:52:49 -0000 I have now posted draft-ietf-pcn-sm-edge-behaviour-09 with similar changes to the CL edge behaviour draft. I forgot to mention deletion of the following bullet from Section 2: o the PCN-domain satisfies the conditions specified in [RFC5696]; I apologize to Joel and Brian that I forgot to add them to the Acknowledgements section in the CL draft. I'll fix that in AUTH48, if it ever comes. I did fix add them in the SM draft. Tom Taylor From slblake@petri-meat.com Wed Feb 22 21:28:59 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A206521E803A; Wed, 22 Feb 2012 21:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[AWL=1.600, 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 oSYAaE3wLOld; Wed, 22 Feb 2012 21:28:58 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by ietfa.amsl.com (Postfix) with ESMTP id 9434121E803B; Wed, 22 Feb 2012 21:28:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=petri-meat.com; h=Received:Subject:From:To:Cc:Date:In-Reply-To:References:Content-Type:X-Mailer:Content-Transfer-Encoding:Message-ID:Mime-Version; b=qkrE9obIEZZ8TVjvWrgGC/SGHeNCFLvHGQnG16V/I7xHjHv7UPOtpCC2Op3sYpkaQyPJRWfCJRThwkW5Kgb6eI3aCOaskLr7ZWa1d2eSDXuj/0Cxvs3nDX/SW/Le4yOg; Received: from cpe-071-065-237-221.nc.res.rr.com ([71.65.237.221]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1S0REc-00034a-Ja; Thu, 23 Feb 2012 00:28:54 -0500 From: Steven Blake To: Tom Taylor Date: Thu, 23 Feb 2012 00:28:54 -0500 In-Reply-To: <4F455597.2060104@gmail.com> References: <4F455597.2060104@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 (3.0.3-1.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1329974935.18234.3.camel@tachyon> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: Anna Charny , 'Brian Carpenter' , Michael Menth , pcn , "Joel M. Halpern" , Gen Art Subject: Re: [PCN] draft-ietf-pcn-sm-edge-behaviour-09 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, 23 Feb 2012 05:29:00 -0000 On Wed, 2012-02-22 at 15:52 -0500, Tom Taylor wrote: > I have now posted draft-ietf-pcn-sm-edge-behaviour-09 with similar > changes to the CL edge behaviour draft. I forgot to mention deletion of > the following bullet from Section 2: > > o the PCN-domain satisfies the conditions specified in [RFC5696]; > > I apologize to Joel and Brian that I forgot to add them to the > Acknowledgements section in the CL draft. I'll fix that in AUTH48, if it > ever comes. I did fix add them in the SM draft. Thanks Tom! (for this and CL). // Steve From jmh@joelhalpern.com Wed Feb 22 20:40:34 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 E05F021E8027; Wed, 22 Feb 2012 20:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 f9JlJQghXcVg; Wed, 22 Feb 2012 20:40:33 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id C30DD21E8013; Wed, 22 Feb 2012 20:40:33 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 6A469A3ED4; Wed, 22 Feb 2012 20:40:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 416AB1BD9285; Wed, 22 Feb 2012 20:40:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 062691BD8C9D; Wed, 22 Feb 2012 20:40:31 -0800 (PST) Message-ID: <4F45C340.3@joelhalpern.com> Date: Wed, 22 Feb 2012 23:40:32 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Tom Taylor References: <4F455597.2060104@gmail.com> In-Reply-To: <4F455597.2060104@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Feb 2012 21:29:33 -0800 Cc: Anna Charny , 'Brian Carpenter' , Michael Menth , pcn , Gen Art Subject: Re: [PCN] draft-ietf-pcn-sm-edge-behaviour-09 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, 23 Feb 2012 04:40:35 -0000 Thank you for your responsiveness and effectiveness in resolving these issues. Yours, Joel On 2/22/2012 3:52 PM, Tom Taylor wrote: > I have now posted draft-ietf-pcn-sm-edge-behaviour-09 with similar > changes to the CL edge behaviour draft. I forgot to mention deletion of > the following bullet from Section 2: > > o the PCN-domain satisfies the conditions specified in [RFC5696]; > > I apologize to Joel and Brian that I forgot to add them to the > Acknowledgements section in the CL draft. I'll fix that in AUTH48, if it > ever comes. I did fix add them in the SM draft. > > Tom Taylor > From brian.e.carpenter@gmail.com Thu Feb 23 11:48: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 D511B21F8888; Thu, 23 Feb 2012 11:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.506 X-Spam-Level: X-Spam-Status: No, score=-103.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 XOo3LNRE2qt5; Thu, 23 Feb 2012 11:48:39 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1594A21F8872; Thu, 23 Feb 2012 11:48:38 -0800 (PST) Received: by eaal12 with SMTP id l12so661252eaa.31 for ; Thu, 23 Feb 2012 11:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZjmEpiS3ntA5U5CLG+hIPYMW8ULzNp7Wj+X0uMlvG+s=; b=sSUvL0eVL0kxJQIWxzD4yy1sH4uKL6PgucTgsCBmc2bXegEBwn7BChgFKiBZQU38Gl WmQfs2RHget0n/dBFXKxUQhwQjKHbDOQtc5U8kFttLg6dTbQHCgk6NBnl8LM0FGGMN1S Vd9icT1sOg07XDhMWjAVN9Kc5itOxVnWve/Oc= Received: by 10.14.48.8 with SMTP id u8mr1333619eeb.37.1330026518144; Thu, 23 Feb 2012 11:48:38 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u9sm8750164eem.11.2012.02.23.11.48.31 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 11:48:37 -0800 (PST) Message-ID: <4F469809.50206@gmail.com> Date: Fri, 24 Feb 2012 08:48:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tom Taylor References: <4F454808.7000106@gmail.com> In-Reply-To: <4F454808.7000106@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Anna Charny , Michael Menth , Fortune Huang , 'Brian Carpenter' , pcn , "Joel M. Halpern" , gen-art@ietf.org Subject: Re: [PCN] [Gen-art] draft-ietf-pcn-cl-edge-behaviour-12.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 19:48:40 -0000 Thanks! That seems to fix my comments. Regards Brian Carpenter On 2012-02-23 08:54, Tom Taylor wrote: > I have just submitted draft-ietf-pcn-cl-edge-behaviour-12.txt, > incorporating responses to the Genart reviews by Joel Halpern and Brian > Carpenter. Thanks to both of them for their suggestions. The set of > changes to the CL edge behaviour draft is as follows: > > 1. Introduction > =============== > > Added the following paragraph in response to a concern expressed by > Brian. Further related text is described later. > > Note that the terms "block" or "terminate" actually translate to > one or more of several possible courses of action, as discussed > in Section 3.6 of RFC5559. The choice of which action to take > for blocked or terminated flows is a matter of local policy. > > Deleted the following text from the RFC Editor's note, on Brian's > recommendation: > > You may choose to delete the following paragraph and the > "[CL-specific]" tags throughout this document when publishing > it, since they are present primarily to aid reviewers. > > 3. Node Behaviours > ================== > > Added the following paragraph at the end of the introductory text to > this section: > > Section 5.1.2 describes how to derive the filters by means of > which PCN-ingress-nodes and PCN-egress-nodes are able to classify > incoming packets into ingress-egress-aggregates. > > 3.3.3. Decision Point Action For Missing PCN-Boundary-Node Reports > ================================================================== > > Changed the paragraph dealing with egress node reporting timeouts: > > OLD > > If timer t-recvFail expires for a given PCN-egress-node, the > Decision Point SHOULD notify management. A Decision Point > collocated with a PCN-ingress-node SHOULD cease to admit > PCN-flows to the ingress-egress-aggregate associated with the > given PCN-egress-node, until it again receives a report from > that node. A centralized Decision Point MAY cease to admit > PCN-flows to all ingress-egress-aggregates destined to the > PCN-egress-node concerned, until it again receives a report > from that node. > > NEW > > If timer t-recvFail expires for a given PCN-egress-node, the > Decision Point SHOULD notify management. A log format is > defined for that purpose in Section 5.2.1.1. Other actions > depend on local policy, but MAY include blocking of new flows > destined for the PCN-egress-node concerned until another report > is received from it. Termination of already-admitted flows is > also possible, but could be triggered by the receipt of > "Destination unreachable" messages at the PCN-ingress-node. > > 5.1.2. Specification of Node- and Link-Specific Parameters > ========================================================== > > Replaced the first three paragraphs of this section: > > OLD > > Each PCN-ingress-node needs filters to classify incoming PCN packets > according to ingress-egress-aggregate, both to satisfy Decision Point > requests for sent traffic rates and, if applicable, to support > encapsulation. If PCN packets are being tunneled to the PCN-egress- > nodes (encapsulation), the PCN-ingress-node also needs the address of > the PCN-egress-node for each ingress-egress-aggregate. > > Each PCN-egress-node needs filters to classify incoming PCN packets > by ingress-egress-aggregate, in order to gather measurements on a > per-aggregate basis. The PCN-egress-node also needs to know the > address of the Decision Point to which it sends reports for each > ingress-egress-aggregate. > > If [I-D.tsvwg-rsvp-pcn] is deployed and the Decision Points are > collocated with the PCN-ingress-nodes, this information can be built > up dynamically from the contents of the end-to-end RSVP signalling > and does not have to be pre-configured. Otherwise the filters have > to be derived from the routing tables in use in the domain, and the > address of the peer at the other end of each ingress-egress-aggregate > has to be tabulated for each PCN-edge-node. > > NEW > > Filters are required at both the PCN-ingress-node and the PCN-egress- > node to classify incoming PCN packets by ingress-egress-aggregate. > Because of the potential use of multi-path routing in domains > upstream of the PCN-domain, it is impossible to do such > classification reliably at the PCN-egress-node based on the packet > header contents as originally received at the PCN-ingress-node. > (Packets with the same header contents could enter the PCN-domain at > multiple PCN-ingress-nodes.) As a result, the only way to construct > such filters reliably is to tunnel the packets from the PCN-ingress- > node to the PCN-egress-node. > > The PCN-ingress-node needs filters in order to place PCN packets into > the right tunnel in the first instance, and also to satisfy requests > from the Decision Point for admission rates into specific ingress- > egress-aggregates. These filters select the PCN-egress-node, but not > necessarily a specific path through the network to that node. As a > result, they are likely to be stable even in the face of failures in > the network, except when the PCN-egress-node itself becomes > unreachable. The primary basis for their derivation will be routing > policy given the packet's original origin and destination. Since all > PCN packets will be tunneled, the PCN-ingress-node also needs to know > the address of the peer PCN-egress-node associated with each filter. > > Operators may wish to give some thought to the provisioning of > alternate egress points for some or all ingress-egress aggregates in > case of failure of the PCN-egress-node. This could require the > setting up of standby tunnels to these alternate egress points. > > Each PCN-egress-node needs filters to classify incoming PCN packets > by ingress-egress-aggregate, in order to gather measurements on a > per-aggregate basis. These filters are constructed on the basis of > the identifier of the tunnel from which the incoming packet has > emerged (e.g. the source address in the outer header if IP > encapsulation is used). The PCN-egress-node also needs to know the > address of the Decision Point to which it sends reports for each > ingress-egress-aggregate. > > 5.2.1. Event Logging In the PCN Domain > ======================================= > > Added the following paragraph: > > The field names (e.g., HOSTNAME, STRUCTURED-DATA) used in the > following subsections are defined in [RFC5424]. > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > From iesg-secretary@ietf.org Tue Feb 28 11:41:20 2012 Return-Path: X-Original-To: pcn@ietfa.amsl.com Delivered-To: pcn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056FE21F86B2; Tue, 28 Feb 2012 11:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 17Op9dXQZbM1; Tue, 28 Feb 2012 11:41:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0D721F865E; Tue, 28 Feb 2012 11:41:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120228194119.24271.67621.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 11:41:19 -0800 Cc: pcn@ietf.org Subject: [PCN] Last Call: (Encoding 3 PCN-States in the IP header using a single DSCP) to Proposed Standard X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 19:41:20 -0000 The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'Encoding 3 PCN-States in the IP header using a single DSCP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to decision points which then decide whether to admit or block new flow requests or to terminate some already-admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding provides for up to three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC5696. This document contains a normative reference to an informational RFC - RFC 5559 "Pre-Congestion Notification (PCN) Architecture". The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pcn-3-in-1-encoding/ No IPR declarations have been submitted directly on this I-D.