Hi all, There are still some places in in draft-ietf-pcn-architecture-09 where the "ingress/ingress-node" might be misused. Clarification or editorial changes are required in those places. Please see the detailed comments below. 6.2. Flow termination : "In one approach the PCN-egress-node measures the rate of PCN-traffic that is not excess-traffic-marked, which is the amount of PCN-traffic that can actually be supported, and communicates this to the PCN-ingress-node. Also the PCN-ingress-node measures the rate of PCN-traffic that is destined for this specific PCN-egress-node, and hence it can calculate the excess amount that should be terminated." Comment: It is the decision point but not the ingress node to be communicated by the egress and to decide the amount of termination. 6.4. Information transport: "Signalling is needed to transport PCN-feedback-information between the PCN-boundary-nodes, for example to convey the fraction of PCN-marked traffic from a PCN-egress-node to the relevant PCN-ingress-node." Comment: PCN-feedback-information should transport from the egress to the decision point of admission control or flow termination. 7.4. Admission control functions: " There are various possibilities for how the functionality could be distributed (we assume the operator would configure which is used): o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress-node. The rationale is that the PCN-egress-node naturally has the necessary information about PCN-marking on the ingress-egress-aggregate, but the PCN-ingress-node is the policy enforcement point [RFC2753], which polices incoming traffic to ensure it is part of an admitted PCN-flow. o The decision is made at the PCN-ingress-node, which requires that the PCN-egress-node signals PCN-feedback-information to the PCN-ingress-node. For example, it could signal the current fraction of PCN-traffic that is PCN-marked. o The decision is made at a centralised node (see Appendix; beyond scope of current PCN WG charter). Note: Admission control functionality is not performed by normal PCN-interior-nodes." Comment: I would suggest we replace the view "the decision is made at the PCN-ingress-node or PCN-egress-node or a centralized node" by "the decision point may be co-located with the ingress or egress, or may be deployed on a standalone node". 7.5. Flow termination functions: "o (if required) Communicate PCN-feedback-information to the node that makes the flow termination decision. For example, as in [I-D.briscoe-tsvwg-cl-architecture], communicate the PCN-egress-node's measurements to the PCN-ingress-node." Comment: I suggest we remove the example sentence in order to avoid misleading. 9.1.1. System options: "o Where flow admission and termination decisions are made: at PCN-ingress-nodes or at PCN-egress-nodes (or at a centralised node, see Appendix). " Comment: I suggest we replace this sentence by "o Where flow admission and termination decisions are made: co-located with PCN-ingress-nodes or co-located with PCN-egress-nodes or at a standalone node (see Appendix). " 9.5. Security OAM: "o A PCN-ingress-node receiving feedback signals about the pre-congestion level on a non-existent aggregate, or that are inconsistent with other signals (eg unexpected sequence numbers, inconsistent addressing, conflicting reports of the pre-congestion level, etc)." Comment: I suggest we replace the "PCN-ingress-node" by something like "The decision point of admission control or flow termination". Best Regards, Fortune
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf