[CCAMP] Overdue announcement: Communications received from the OIF, 23rd July 2009 (2/2)

[Lou Berger <lberger at labn.net>]

The following was sent to the CCAMP WG chairs on July 23rd, 2009.  A
URL to the original communication (pdf) can be found below.  The text in
the communication is also enclosed.

This communication should have been announced prior to the last IETF.

A full list of Communications and Liaisons to and from CCAMP can be
found at:
http://trac.tools.ietf.org/wg/ccamp/trac/wiki/CommsLiasons

Lou
------------------------------------------------------------------
[http://trac.tools.ietf.org/wg/ccamp/trac/raw-attachment/ticket/15/oif2009.247.05.pdf]

July 23, 2009

Mr. Lou Berger, lberger at labn.net, IETF CCAMP Co-Chair
Ms. Deborah Brungard, dbrungard at att.com, IETF CCAMP Co-Chair
Cc: Ross Callon, rcallon at juniper.net, IETF Routing Area Director
David Ward, dward at cisco.com, IETF Routing Area Director
From: Lyndon Ong, lyong at ciena.com, OIF Technical Committee Chair

Dear Lou and Deborah,

OIF recently completed a worldwide interoperability demonstration. Among
other functions, GMPLS RFC 4872 end-to-end recovery was used to control
Full LSP Rerouting across multiple carrier domains, on three
continents. Details are at
http://www.oiforum.com/public/OIF_Networking_Demo_2009.html. The GMPLS
protocol operated successfully. This liaison informs you of our findings
on four aspects of the protocol, and solicits your comments.

First, carriers were unable to allocate a globally unique association
source address to each LSP originator.  Available LSR addresses were
unique only at carrier domain scope. In order to uniquely identify the
association source, an experimental ASSOCIATION object was used that
included a routing area ID to scope the association source address. In
the past ccamp has insisted that globally unique addresses must be
assigned to all GMPLS LSRs. We note that this continues to prove
difficult when actually deploying worldwide GMPLS networks.

Second, we found behaviour differences in error reporting and
restoration triggering. Some implementations sent both Notify and
PathErr detailing the fault location, others sent only Notify. Some
implementations regarded the Notify as the trigger for restoration,
others triggered on either message. Text in RFC 4872 section 11
indicates that the trigger is a "Notify and/or a PathErr". This text has
been interpreted in different ways. Perhaps it could be clarified to
indicate that either message individually, or the arrival of both
messages within an interval, should be regarded as a single restoration
trigger.

Third, some implementations reported intermediate link failures using
error code/sub-code 25/9 (Notify Error/LSP Failure) others 25/11 (Notify
Error/LSP Locally Failed). RFC 4872 section 11 seems clear that 25/11
should be used to report an intermediate link failure for
restoration. However, it seems strange not to trigger restoration
procedures on receipt of errors that describe other faults.

Fourth, some implementations used error code zero for administratively
initiated graceful release of an LSP.  We see that
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#section-4.2
suggests error codes when the cause is link or node maintenance, but no
suitable value exists to indicate an administrative LSP release for
other reasons.

We would welcome opinions or guidance from ccamp on these four
points. If ccamp indicates that RFC errata or protocol updates are
desirable, we would be glad to contribute.

Best regards,
Lyndon Ong
OIF Technical Committee Chair