Liaison statement
IETF PCN Working Group Response to Liaison Statement TD 151 (NGN-GSI) (Q.5/11) from ITU-T Study Group 11

To: ITU-T Study Group 11

Thank you for your liaison statement from your Geneva meeting on your intent to
incorporate PCN into the RACF framework.

For your information, the fifth draft of the PCN Architecture document has
completed working group last call, and we expect that the sixth draft
(incorporating edits in response to comments from the last call) will be
submitted for IESG review and IETF last call prior to the next IETF plenary in
November.  This draft is available at:
http://tools.ietf.org/html/draft-ietf-pcn-architecture-06.

Subsequent to our last liaison statement, the PCN working group has achieved
consensus to advance a 2-state PCN encoding proposal for Proposed Standard,
although the specific proposal is still under development.  Consensus was also
achieved to allow a 3-state PCN encoding proposal to be advanced for
Experimental status, although again no specific proposal has been finalized. 
We note that your attached draft Q.PCNApp "Enhancement of resource and
admission control protocols to use pre-congestion notification (PCN)" appears
to assume that a 3-state PCN encoding mechanism is available, and we wish to
advise you that there is no consensus to standardize a 3-state PCN encoding
mechanism at this time.

In addition, we wish to inform you that the PCN working group has not made
progress in defining a protocol for conveying pre-congestion information from
an egress node to an ingress node (corresponding to the Rc interface defined in
<Draft Q.PCNApp>).

We note that <Draft Q.PCNApp> discusses the transport of network topology
information from the TRC-PE function to an egress node, to assist the egress
node in associating a received packet with the ingress node via which that
packet entered the network.  We believe that the use of topology information as
a means to determine the ingress node of a particular packet will only work in
certain constrained network topologies.  We suggest that one alternative
approach would be to define an interface from the PD-PE function to the egress
node, to convey packet classification state for admitted flows.

We would like to ask for clarification on the role and operation of the Rp
interface in <Draft Q.PCNApp>.  It is not clear from the text whether commands
are issued by the centralized TRC-PE function towards the TRC-FE function, and
if so, what is the defined behavior of these commands.

Thank you,

Steven Blake and Scott Bradner, PCN working group co-chairs