New Liaison Statement, "Liaison statement to ccamp responding to ccamp liaison of 21 February 2007"

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

We have received the following liaison from Question 14 of Study Group 15 of 
the ITU-T. A response is requested by 6th April 2007.

As usual, you can find the details at www.olddog.co.uk/ccamp.htm

Thanks,
Adrian

> Title: Liaison statement to ccamp responding to ccamp liaison of 21 
> February 2007
> Submission Date: 2007-03-14
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=305
> Attachment(s):
>     text of liaison 
> (https://datatracker.ietf.org/documents/LIAISON/file406.doc)

Thank you for your response to our previous liaison statement on the current 
ASON work in ccamp.  With respect to the current liaison statement we have 
the following comments:

On the selection of a loop prevention mechanism the liaison statement 
indicates that  “the choice was made after careful evaluation in cooperation 
with IETF's OSPF Working Group.”  We would appreciate further details of 
these considerations to allow us to fully understand the thought going into 
this decision and evaluate any impacts on the transport network.

In the context of an n:1or m:n relationship between Routing Controllers 
(RCs) and Transport Nodes the liaison states “we have yet to hear from 
anyone who wishes to implement or deploy in this ratio”.  While there may 
have not been direct input from CCAMP participants on this, the ITU-T 
liaison clearly expressed interest in these scenarios on the part of ITU-T 
participants.  We would appreciate understanding further the concerns in 
IETF ccamp with the wording change that was proposed in our last liaison to 
replace “Li” with “TE Link” in section 5.1.  Please note that in our 
previous liaison that the abbreviation SC refers to Signalling Controller 
(e.g. a RSVP instance).  Please note that the ASON terms and abbreviations 
are defined in ITU-T Recommendation G.8081 (available for free download from 
the ITU-T web site).

Regarding the use of “optional” in the draft for timeslot accounting, we 
believe “MUST” to be more appropriate to meet the requirements defined in 
G.7715.1, whereas “optional” implies that ASON requirements can be met 
without providing this level of accounting detail.  We agree that WDM 
systems do not have timeslots.  ASON is not specific to TDM networks, it may 
be applied to any network technology that can be modelled using G.805.  To 
achieve this ASON manages link connections.  Time slots and wavelengths are 
examples of link connections.  Therefore, routing announcements for ASON 
must contain link connection accounting information.

For the Local TE Router ID, we believe that “SHOULD only be included…if the 
Router_ID is advertising on behalf of more than one TE_Router_ID ” is overly 
constrained, and “MUST be included” is necessary since identifier separation 
is an ASON requirement.  This allows for the case of multiple Li per Ri (a 
common case for ASON).  This also allows separation of the identifiers used 
in the information being distributed from the identifiers used by the 
protocol supporting the distribution.  We do not require inter-operability 
with legacy OSPF routers in an ASON context.

The liaison states  “Please keep us informed as you evolve ASON to include 
multi-layer networks and any related GMPLS protocol requirements.”  It 
should be noted that ITU-T work has been addressing multi-layer networks for 
ASON for some time.  The results of this multi-layer work are reflected in 
G.7715.1 (2004) section 9.5, G.8080 amendment 2 (2005) sections 6.5 and 6.6, 
with further detail in G.8080 version 2 (2006) sections 6.5, 6.6 and 8.5 
(Available for free download from the ITU-T web site).  Previous ITU-T 
liaison statements have shared the drafts in progress and the final results. 
We request that you liaise any work that you have under way on multi-layer 
networks.

The liaison states: “With regard to "speedy recovery", can you clarify your 
concern on LS MAX Age and the implications for recovery? Are you saying that 
your concern is the continued behavior of upward dissemination of routing 
information in the event that the selected RC performing the dissemination 
fails?”.  Our expectation is that the parent/child redistribution of 
information will be continuous even when a redistribution point has failed. 
Could you explain how the mechanism that has been proposed behaves under 
this condition.
Regarding call and connection separation the liaison states:  “We understand 
that ASON Calls may be implemented through full call/connection separation 
(as in G.7713.3) or call/connection 'piggybacking' as in G.7713.2. Please 
confirm that our interpretation of G.8080 and G.7713 is correct.”  ASON 
requires full logical separation of the call and connection which may be 
implemented with separate or piggybacked call and connection signalling.

ITU-T SG 15 has been relying on a collaborative relationship with IETF ccamp 
to provide the protocol support for ASON.  This collaborative work should 
allow the industry to take advantage of the different expertise in each of 
the Standards Development Organizations.  Q.14/15 has not developed protocol 
specific Recommendations for ASON since 2003, based on an expected 
collaborative technical relationship, in which IETF ccamp would provide 
protocol solutions that fully meet the ITU-T ASON requirements.  However, 
the effectiveness of this SDO liaison relationship could be improved.

We observe that IETF ccamp has responded to some of the technical issues 
raised by suggesting that the ITU-T participants should provide input 
directly, to the work in ccamp.  We agree that having participants involved 
in both the  ITU-T and IETF improves the communication process.  We would 
like to confirm that this individual participation is not being suggested as 
a substitute for the liaison relationship.  A liaison statement or ITU-T 
Recommendation represents the consensus of the members of the ITU-T.  An 
individual participating in the work of ccamp is not authorized to represent 
or negotiate on behalf of the ITU-T.

One particular area for improvement of the liaison relationship is 
communicating the disposition of ITU-T comments related to the 
interpretation of ASON requirements.  For example comments provided on, 
draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now RFC 4258) and 
draft-ietf-ccamp-gmpls-ason-routing eval-00 (now RFC 4652) were not included 
in the published RFC and the rational for this decision has not been 
communicated.  ITU-T SG15 continues to be interested in providing 
clarification or validation of IETF ccamp interpretation of the ASON 
requirements and therefore continues to request that in future any documents 
under development that are potentially applicable to ASON be liaised so that 
ITU-T can validate the documents against the ASON requirements.

We look forward to receiving your response and hope that we can continue to 
build a cooperative and productive relationship between ccamp and SG 15.

An electronic copy of this liaison statement is available at:

http://ties.itu.int/u/tsg15/sg15/xchange/wp3/q14/0702/wd/rd29r6_ls_ccamp.doc