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