[Gen-art] draft-ietf-pcn-cl-edge-behaviour-12.txt

Tom Taylor <tom.taylor.stds@gmail.com> Wed, 22 February 2012 19:54 UTC

Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@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 <multiple recipients>; 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 <tom.taylor.stds@gmail.com>
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 <pcn@ietf.org>, Fortune Huang <fqhuang@huawei.com>, Anna Charny <anna@mwsm.com>, Michael Menth <menth@informatik.uni-wuerzburg.de>, Georgios Karagiannis <karagian@cs.utwente.nl>, "Joel M. Halpern" <jmh@joelhalpern.com>, 'Brian Carpenter' <brian@cs.auckland.ac.nz>, gen-art@ietf.org, David Harrington <ietfdbh@comcast.net>
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: [Gen-art] draft-ietf-pcn-cl-edge-behaviour-12.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=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].