[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Liaison received form the ITU-T
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