Skip to main content

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.