[CCAMP] Communication to the OIF on Error Messages

"BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com> Tue, 26 January 2010 18:59 UTC

Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 26 Jan 2010 13:59:34 -0500
Message-ID: <D6CB948F7AFD6F4881D4B4F80C8509AA0573BB8C@gaalpa1msgusr7e.ugd.att.com>
Thread-Topic: Communication to the OIF on Error Messages
Thread-Index: AcqeubLf588ErZUHSOOyX+dIC+mJBA==
From: "BRUNGARD, DEBORAH A (ATTLABS)" <db3546@att.com>
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: Ross Callon <rcallon@juniper.net>, CCAMP <ccamp@ietf.org>, kchiu@oiforum.com, Adrian Farrel <Adrian.Farrel@huawei.com>
Subject: [CCAMP] Communication to the OIF on Error Messages
Precedence: list

Dear Lyndon,

In your communication of Oct. 22nd, you asked guidance on the following
points.

 > 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.

This is incorrect behavior.  Per RFC3473:
    The Notify message does not replace existing error messages.
and
    Notify messages are most commonly generated at nodes that detect an
    error that will trigger the generation of a PathErr or ResvErr
    message.

The remainder of the procedures discuss the cases where Notify is 
generated *in addition* to a PathErr or ResvErr.

We believe the RFC is sufficiently clear on this point.

 > 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.

Here too implementations must process both Err messages and Notify 
messages. RFC4872 is an extension to RSVP-TE.  RSVP has always supported
the indication of errors in Err messages.  As discussed above, RFC3473 
does not change this, nor does RFC4872. As such when RFC4872 uses the 
phrase "detects the failure" it MUST be read to include receipt of an 
Err message.

If you wish, you can open an editorial errata on this point so that this
topic is clarified in a future revision of the standard.

 >
 > 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.

As written, RFC4872 uses "LSP Failure" to indicate a Switchover Request,
and "LSP Locally Failed" to indicate a failure in the data plane.

 > However, it seems strange not to trigger restoration
 > procedures on receipt of errors that describe other faults.
 >

This is not precluded (nor required) by the RFC, so an implementation 
may choose to trigger restoration on any error.

 > Fourth, some implementations used error code zero for
administratively
 > initiated graceful release of an LSP.

Per RFC2205:
    o    Error Code = 00: Confirmation

         This code is reserved for use in the ERROR_SPEC object of a
         ResvConf message.  The Error Value will also be zero.


 > We see that
 > 
http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#se
ction-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."
 >

You are correct that such an error value for this explicit purpose is
not defined. 
Such a value can be defined by submitting an Internet draft with the 
definition of the value and then bringing the document to the CCAMP 
working group.  In short, the RFC4929 defined process may be followed to
get such an error value assigned.

 > We welcome guidance from CCAMP on these three points. Thank you for
 > your continued attention.

Regards,
Lou Berger and Deborah Brungard
IETF CCAMP Working Group Co-Chairs

[CCAMP] Communication to the OIF on Error Messages BRUNGARD, DEBORAH A (ATTLABS)