[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [CCAMP] Communication from OIF - October 22, 2009 (2 of 2)
Eric,
Thank you for your analysis. Please see below for responses/comments
in-line.
On 10/27/2009 12:14 PM, Eric Gray wrote:
> 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.
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.
> 2) Never-the-less, the text is reasonably clear - either a Notify,
> a PathErr, or both should be interpretted as a trigger.
100% agree.
> 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
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
> 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.
>
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.
> 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.
>
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
> --
> 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
>
>
>