Liaison statement
Regarding any IETF work required for a new ITU-T Recommendation Q.Flowstatesig
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2008-05-05 |
From Group | TSV |
From Contact | Lars Eggert |
To Groups | ITU-T-SG-11, ITU-T-SG-11-Q5, ITU-T-SG-11-WP2 |
To Contacts | ITU-T SG 11 <tsg11gen@itu.int> ITU-T Q.5/11 <tsg11q5@itu.int> ITU-T WP 2/11 <tsg11wp2@itu.int> |
Cc | IETF Liaison to ITU-T on NGN Monique Morrow (mmorrow@cisco.com) IETF Liaison to ITU-T Scott Bradner (sob@harvard.edu) IETF Chair Russ Housley (chair@ietf.org) ITU-T Telecommunication Standardization Advisory Group (tsaggen@itu.int) |
Response Contact | Magnus Westerlund (magnus.westerlund@ericsson.com) Lars Eggert (lars.eggert@nokia.com) |
Technical Contact | Magnus Westerlund (magnus.westerlund@ericsson.com) Lars Eggert (lars.eggert@nokia.com) |
Purpose | For action |
Deadline | 2008-07-27 Action Taken |
Attachments | (None) |
Body |
The IETF Transport Area would like to thank ITU-T SG 11 for the liaison statement titled Comments on the IETF Liaison response on Y.2121 and the development of new Recommendation Q.Flowstatesig (COM 11 - LS 66 E). We appreciate SG11s willingness to have a successful cooperation and work within the agreements between our two standards organizations. We noted your clarification on the intended deployment environment of Flow State Aware (FSA) signaling. We would like to remark that although the intended deployment may be limited, the associated signaling and data traffic from an FSA-enabled end-system still appears to have a very high probability to be transmitted over the general Internet. The development of such functionality therefore must not have any negative impact on existing end-host and network infrastructure protocols. This is a major reason why any such proposals for extending IETF protocols require extensive review within the IETF community. Certain types of proposed extensions must be developed within the IETF itself, in order to ensure that they are well aligned with the overall Internet protocol suite. We are looking forward to receiving a liaison statement where SG11 provides an outline of the technical details of its proposed solution, with a focus on where the solution proposed by SG11 affects protocols and specifications that are under IETF change control. We would also like to strongly encourage to as soon as possible establish a more frequent, informal exchange between the technical experts in the IETF (area directors, liaison persons, WG chairs of relevant WGs) and SG11s technical experts, in order to discuss the required steps to accomplish any such changes or extensions. This is important, because the individual extensions to IETF protocols that Q.Flowstatesig entails may require different processes on the IETF side with varying completion times. At this time, it appears very likely that at least some of the changes to IETF protocols needed to instantiate SG11s proposal for FSA signaling will require extensions that are required to be developed within the IETF based on SG11s requirements. Because Y.2121 hints at the potential use of IP options for carrying the FSA information, we would like to use this single change as an example to illustrate what kinds of processes would be involved on the IETF side to realize FSA signaling. The creation of new IPv4 and IPv6 hop-by-hop options require the registration policy IESG Approval, IETF Consensus or Standards Action, as defined by RFC 2434. Considering the potential architectural impact of new IP options, the IESG is likely to require an IETF Standards Action, i.e., the publication of an RFC that has undergone IETF-wide review, for any such extension. (Note that whether the IESG will do so of course depends on an actual proposal this example is meant to illustrate a likely case.) This highlights why it is important to determine as early as possible what extensions or changes FSA signaling will require. In addition, in cases where IETF Standards Actions are required for an extension, a work item would need to be chartered in a suitable existing WG or a new WG might need to be created to host the new work item. We would therefore like to again extend an offer to host a Birds of a Feather (BOF) session on this topic at a future IETF meeting, in order to discuss the details of this proposal. Note that there is a process involved with requesting and approving a BOF session, and the proponents of this work should contact the Transport Area Directors at their earliest convenience. In summary, the IETF Transport Area kindly requests the following three actions from ITU-T SG 11: (1) That SG 11 as early as possible provide the IETF Transport Area with a general technical overview of the proposed solution for FSA signaling and that inform us on the foreseen impact on IETF protocols, focusing on any needed extensions to or changes of protocols under IETF change control. (2) That SG11 provide a time plan for when the above action can be completed as well as a projected time line that would detail the completion plan for the new recommendation Q. Flowstatesig. (3) That SG11 provide clarification on what is meant by the phrase that the FSA Transport Technology is overlaid on the NGN, which occurred in their previous liaison. This liaison statement represents the views of the IETF Transport Area Directors and has been reviewed and has the consensus of the IETF Transport Area. |