From: The IESG Date: 2009-12-23 To: ITU-T SG 11 , ITU-T TSAG CC: Arshey Odera , Wei Feng , Kaoru Kenyoshi , Tina Zou Subject: Response to "Protocol for the Support of Flow State Aware Transport Technology" Reply-To: IESG Response Contact: IESG Technical Contact: IESG Purpose: For Action Deadline: 2010-1-31 The IESG would like to thank ITU-T Study Group 11 for their September 2009 response [1] to our June 2009 liaison statement [2] concerning their draft work on ITU-T Recommendation Q.Flowstatesig, "Signalling protocols and procedures relating to flow state aware access QoS control in an NGN". In their liaison statement, SG11 asked us to clarify our concerns on the use of an EXP/LU DSCP to mark a signaling packet for IPv4 packets, and goes on to say that we "only indicated concerns related to IPv6." The IESG would like to stress that the issues raised regarding the use of a EXP/LU DSCP in [2] makes no mention of a specific IP version, and consequently applies to both IPv4 and IPv6. (The IETF's differentiated services architecture is IP version agnostic.) SG11 also included a list of replies (quoted below) to some of the issues raised in our liaison statement. The IESG would like to comment on each of those replies: > 1. Responding to your concern that data corruption (is a consequence > of the implementation of draft Recommendation Q.Flowstatesig) when > modified end systems communicate with end systems that implement the > TCP and UDP standards, resulting in serious compatibility and > interoperability issues. > > It is stated in Q.Flowstatesig, clause 6, that “It is assumed that > signaling messages originate and terminate at Flow State Aware > Signalling Edge Functions as defined in clause 6.1 of [ITU-T Y.2121]” > > The implication of such termination is that the implementation of > Q.Flowstatesig does not involve signal packets being passed to end > systems where data corruption could occur. Instead, the > implementation requires that a FSA Signalling Edge Function deletes > signal packets from flows that are forwarded further downstream. The IESG would like to stress that this design remains extremely problematic under error conditions, where Q.Flowstatesig packets can leak to standard Internet hosts, because Q.Flowstatesig uses the same protocol numbers as standard TCP and UDP for variants of those protocols that are not compliant with the IETF standards. Because Q.Flowstatesig is meant for deployment in closed, walled-garden networks, the IESG notes that SG11 can eliminate this danger by using different IP protocol numbers for their modified transport protocols. Without significant changes to the current design, the IESG strongly requests that SG11 apply for separate numbers instead of using the protocol numbers assigned for standard TCP (6) and UDP (17). See [3]. > 2. In attempting to overcome concerns about collaboration, Dr. John > Adams has already attended the San Francisco meeting of the IETF and > presented a summary in the NSIS working group of the work on > Q.Flowstatesig in SG11. A consensus on the next steps reached within > NSIS was that the collaboration should proceed with the production of > an informational internet draft on in-band signalling packet marking. > Dr. Adams has now produced this draft and it will be submitted to the > IETF. The IESG would like to sincerely thank Dr. John Adams for his presentations at several IETF meetings - they have been very helpful in understanding the Q.Flowstatesig proposal. We would like to clarify that the submission of such an Internet-Draft is a first required step, followed by initiating the necessary protocol work in the IETF, should there be consensus for adopting the proposal. As pointed out several times in our liaison statements, *all* steps of this procedure must *conclude* before Q.Flowstatesig can be put forward for consent in the ITU-T, under the standing collaboration agreements between the two SDOs, because TCP and UDP are protocols that originated in the IETF and remain under IETF change control. (Moving Q.Flowstatesig to different IP protocol numbers - as outlined above - would simplify this procedure, because standard TCP and UDP would then not be modified.) > 3. Furthermore, Dr Adams also attended the Dublin meeting of the IETF, > in 2008, and submitted a first internet draft calling for the IETF to > “comment on a proposal that would rapidly help the advancement of the > work and where the help of the IETF would be invaluable. The IESG would like to point out that this first Internet-Draft (draft-adams-tsvwg-flow-signalling-codepoint-00) outlined a few high-level requirements for such a solution, but did not include sufficient technical details to evaluate whether existing IETF solutions were sufficient to address the stated requirements or if new protocol work should be initiated. We also note that the suggestion that SG11 contact the NSIS WG was based on this initial draft, because NSIS has been developing solutions that seemed to address most of the stated requirements in this Internet-Draft. > 4. In seeking clarification to the architectural concern of the use of > EXP/LU DSCPs. It should be pointed out that the proposed use in > Q.Flowstatesig is as an alert to an IP aware node, which seems well- > aligned with the architectural requirement. The IESG disagrees strongly that using a DSCP as a router-alert option is aligned with the DiffServ architecture. DSCPs indicate per-hop forwarding behaviors, i.e., affect data-plane queueing, and do not initiate or affect control-plane actions. > 5. We would also reiterate the limitations of scope of Q.Flowstatesig > and that any implementation based on Q.Flowstatesig is limited to its > scope, namely that it is restricted to signalling protocols and > procedures relating to Flow State Aware access QoS control in an NGN. > With these limitations, it is assumed that there are no significant > impacts on protocols and specifications under IETF change control. Under these constraints, the IESG believes that using different IP protocol numbers for Q.Flowstatesig flows (instead of the standard values for UDP and TCP) is the first step towards an acceptable solution. The procedures for obtaining a suitable IP protocol number are defined in [5]. The proponents of Q.Flowstatesig will need to write the necessary documents so that IANA can be authorized to make the required allocations after an IETF Standards Action or IESG Approval. Finally, the IESG would like to thank the Q.Flowstatesig proponents for taking the time to discuss their proposal during a recent phone meeting and explain the constraints under which Q.Flowstatesig is envisioned to be deployed. We believe that our recommendation to apply for different IP protocol numbers is in line with those constraints and are looking forward to assisting with the IANA assignment where we can. In view of the above comments and issues, the IESG would like to ask the ITU-T to confirm that it will not undertake any further approval, consent or other publication action until this matter is resolved to the satisfaction of both parties. [1] https://datatracker.ietf.org/documents/LIAISON/file701.doc [2] https://datatracker.ietf.org/documents/LIAISON/file664.txt [3] http://www.iana.org/assignments/protocol-numbers/ [4] http://tools.ietf.org/wg/nsis/minutes?item=minutes74.html [5] [RFC5237