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

From: Lou Berger <[email-masked]>
Date: Mon, 26 Oct 2009 19:07:49 -0400

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, [email-masked], CCAMP Co-Chair
Ms. Deborah Brungard, [email-masked], 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 ([email-masked]) and Adrian Farrel
([email-masked])

---

From: Eric Gray <[email-masked]>
Date: Tue, 27 Oct 2009 12:14:12 -0400

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: [email-masked] [mailto:[email-masked]] 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)

Lou

Dear Lou and Deborah,

"Second, we found behaviour differences in error reporting and

LSP release for other reasons."

Best regards,
Lyndon Ong

cc: Ross Callon ([email-masked]) and Adrian Farrel
([email-masked])
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Oct 2009 13:39:00 -0400

Eric,
	Thank you for your analysis.  Please see below for responses/comments
in-line.

>    explicitly specifying which of the two would be used.

I agree that the text could have been more explicit on the topic.  That
said, it could be either based on when Notify Request is used and the
time of the messages.

>    a PathErr, or both should be interpretted as a trigger.

100% agree.

>    identified in the liaison

Again, I agree.  Furthermore, with regard to the text: "Some
implementations sent both Notify and PathErr detailing the fault
location, others sent only Notify."  The ones that only sent Notifiy
messages are clearly not following RFC 3473.

>  (it seems likely that the issue is 

I agree with all the above.  Furthermore, it's fairly easy to determine
when on message matches the other.  I think this all goes to the point
that no matter how much detail is provided, someone will always want more.

> a good idea to trigger restoration based on a general error.

I think this is consistent with the current text in 4872.  The other
perspective, is that it may be useful to have error codes/values that
are "more informative" while still triggering LSP Rerouting.  I think
this is a valid perspective, but it doesn't match current RFCs.  (Now if
someone want's to contribute a draft on this, we can consider changing
this.)

Thank you for the basis of a response (to OIF)!

Lou