Re: [PCN] Last Call: draft-ietf-pcn-architecture (Pre-Congestion Notification (PCN) Architecture) to Informational RFC

[Fortune HUANG <[e-mail]>]

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