[CCAMP] Communication from OIF - October 22, 2009 (2 of 2)

[Lou Berger <lberger at labn.net>]

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

Lou
------------------------------------------------------------------
[http://trac.tools.ietf.org/wg/ccamp/trac/attachment/wiki/CommsLiasons/091022b-OIF.pdf]


Mr. Lou Berger, lberger at labn.net, CCAMP Co-Chair
Ms. Deborah Brungard, dbrungard at att.com, CCAMP Co-Chair

Dear Lou and Deborah,

OIF would like to bring the attention of IETF CCAMP to three specific
issues identified in our liaison of July 23, 2009 on OIF Interop Demo
Findings which have not yet generated a response from IETF CCAMP. The
associated text in the July 23rd liaison was as follows:

“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 welcome guidance from CCAMP on these three points. Thank you for your
continued attention.

Best regards,
Lyndon Ong
OIF Technical Committee chair

cc: Ross Callon (rcallon at juniper.net) and Adrian Farrel
(adrian.farrel at huawei.com)