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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf