A few additional comments.
> -- Also, are there interactions/race conditions between this alarm > communication with other mechanisms conveying problems along an LSP? > Some discussion in the doc. would be valuable.
Nothing to discuss. Unless you can suggest a problem that we should be worried about.
> -- The document mentions briefly that the LSP state must > be retained for the communicated alarm information to be useful. > > I think this is an important point, and worth expanding on in the doc. > I don't think there is any discussion right now of how one might > ensure that state has not been torn down by the time the alarm > information is correlated and ready to be communicated upstream > and downstream.
If the state has been torn down, there is clearly no LSP about which to communicate alarm state.
> -- And, can the document provide some examples of the types of alarms
> it is talking about/referring to? I think this will help a reader
> understand better the why behind this approach.
examples are illustrative anyway, if any they would be included in appendix, imho such examples would better fit in an applicability statement document
Agreed. Besides, there is no limit to the alarms that this could be applied to. Very specifically - any alarm that impacts or is related to the LSP.
Thanks, Adrian
-- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491