Liaison received form the ITU-T

["Adrian Farrel" <[e-mail]>]

Hi,

We were copied on a liaison from ITU-T SG15 to the OIF discussing call and 
connection modification and deletion.

You can see the liaison at 
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=271

The text is included below.

The liaison is for information only and we are not required to respond, but 
if anyone has anything they need to say...

Adrian

===

Q14/15 thanks OIF for the liaison statement (oif2006.258.02, 
TD283/3-SG15-2006) on the effort to align the signalling procedure in 
G.7713.2, OIF UNI/ENNI, and IETF for connection deletion.

We have tried to research the underlying rationale for the difference 
between G.7713.2 and RFC 3473 regarding this procedure. Note that G.7713.1, 
G.7713.2, and G.7713.3 were developed at the same time and it was a goal to 
maintain protocol behaviour consistency across the three. We think that one 
consideration might have been related to usage of a somewhat similar 
mechanism in previous ITU-T Q.931 signalling protocol to support a 3 message 
release sequence, where there is an initial message sent to notify the 
remote end that release is requested. However, in this procedure the initial 
message always results in release of the connection.

As a result the A bit is not used in G.7713.x for setting a permanent 
administrative state. It might therefore be used by G.7713.2 in the 
Path/Resv message to initiate deletion from an intermediate node instead of 
using the Notify message (as described in section 7.3 of RFC3473) so as to 
save one extra message type (i.e., the Notify message type).

In the management plane, prior to deleting (or performing maintenance on) a 
resource, it is a common practice to put the resource in the administrative 
"locked" state (equivalent to the administrative-down status). Our current 
thinking is that a similar feature in the control plane is worth 
consideration so as to maintain the same operational principle as in the 
management plane.



Q14/15 agrees with OIF's desire to support maximal alignment among these 
documents. We would like to have a structured approach for the alignment 
effort. Note that the existing G.7713 does not have abstract messages in 
support of connection deletion from intermediate nodes and connection state 
modification. So the first step is to develop the abstract messages to 
support these functionalities. Once these new abstract messages are defined, 
corresponding RSVP protocol details can be added to G.7713.2. The impact of 
the G.7713 and G.7713.2 changes on G.7713.1 and G.7713.3 might need to be 
considered too. SG15/Q14 would like to collaborate with the OIF in the 
alignment effort.

Here is a summary of required enhancements:

-        Connection Modification, currently for further study in G.7713 
(SP19), would have to be defined. This would allow for the capability to 
change the administrative status of a connection without deleting it. Once 
the abstract message is defined, the RSVP messages in G.7713.2 could be 
modified to align with RFC3473 and proper use of the A-bit.

-        An abstract message for deletion from intermediate nodes would have 
to be defined in G.7713. This message would then be mapped to proper RSVP 
protocol details in line with RFC3473.

Regarding the proposed solutions, we have the following comments:

-        For both proposals, there appears to be limitations in the 
backwards compatibility and it is not clear what the behaviour is when the 
old version (1.0) is surrounded by newer version (2.0).

-        oif2006.182.00 lacks a clear mapping of RSVP messages to abstract 
messages.

-        oif2006.232.00 seems to require provisioning/discovery of neighbour 
version for compatibility.

-        oif2006.232.00 introduces new abstract messages (Connection Modify 
Request/Connection Modify Indication/Connection Release Notify) that could 
be incorporated into G.7713

 An electronic copy of this liaison statement is available at: 
ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html