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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
