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

[Eric Gray <eric.gray at ericsson.com>]

Lou,

	On the reported issue with possible interpretation differences
of the "Notify and/or a PathErr" text in RFC 4872:

1) We probably should have made it simpler for implementers by 
   explicitly specifying which of the two would be used.
2) Never-the-less, the text is reasonably clear - either a Notify,
   a PathErr, or both should be interpretted as a trigger.
3) Under this (IMO - correct) interpretation, implementations that
   trigger restoration only on the Notify, are not compliant with
   RFC 4872 - however, it is not clear that this is the behavior
   identified in the liaison (it seems likely that the issue is 
   with implementations that trigger twice because they get both
   messages, although it would be better if it were clear what 
   problems this leads to).
4) If the result of "triggering" on both messages is harmfull (it
   is not clear how creation of a duplicate "logging event" is
   something that should be considered "harmful"), it should be
   obvious to even the most casual implementer that a robust
   implementation might include a timer to prevent this from
   happening innappropriately.
5) This seems to come under the heading of "guidelines to building
   a robust implementation", which - if a remember correctly - is 
   not actually something we generally do in the IETF.

	On the reported issue with which errors should trigger a
restoration, it is highly probable that restoration should only
be triggered if doing so was the explicit intent of the entity
sending an error message.  In particular, it does not seem to be
a good idea to trigger restoration based on a general error.

--
Eric Gray

-----Original Message-----
From: ccamp-bounces at ietf.org [mailto:ccamp-bounces at ietf.org] On Behalf Of Lou Berger
Sent: Monday, October 26, 2009 7:08 PM
To: CCAMP
Subject: [CCAMP] Communication from OIF - October 22, 2009 (2 of 2)

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)
_______________________________________________
CCAMP mailing list
CCAMP at ietf.org
https://www.ietf.org/mailman/listinfo/ccamp