Protocol Action: 'GMPLS - Communication of Alarm Information' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'GMPLS - Communication of Alarm Information '
   <draft-ietf-ccamp-gmpls-alarm-spec-06.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and Bill Fenner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-06.txt

Technical Summary
 
   This document describes an extension to Generalized MPLS (Multi-
   Protocol Label Switching) signaling to support communication of alarm
   information.  GMPLS signaling already supports the control of alarm
   reporting, but not the communication of alarm information.
 
Working Group Summary
 
   No dissent was reported. This appears to be a pretty straightfoward
   way to report on certain alarms.
 
Protocol Quality
 
  There were no IETF last call comments. The document has been recently 
  updated to respond to Gen-ART review comments. There are 
  implementations. I have not heard reports of interoperability testing, 
  although the additions to the protocol that this document adds are 
  relatively straightforward. Ross Callon reviewed this for the IESG. 

IANA Note

   This document defines a new RSVP "ALARM_SPEC object" with a Class-Num
   of the form 11bbbbbb, see section 3.1.  The value 197 is suggested.
   The C-type values associated with this object should read "Same
   values as ERROR_SPEC (C-Num 6), with the exception of C-Types 1 and 2
   which are reserved".  The text associated with ALARM_SPEC object
   should also read "The ALARM_SPEC object uses the Error Code and
   Values from the ERROR_SPEC object."

   Additionally, Section 3.1.3 defines a new RSVP Error Code.  The Error
   Code is "Alarms" and uses Error Values defined in the Alarm MIB
   [RFC3877].  The suggested Error Code value is 28.

   This document also defines the TLVs for use with the RSVP IF_ID
   ERROR_SPEC objects defined in [RFC3473].  The following are the TLV
   descriptions and (suggested) type values listed in Section 3.1.1:
     Type    Length     Description
     ----------------------------------
     512       8        REFERENCE_COUNT
     513       8        SEVERITY
     514       8        GLOBAL_TIMESTAMP
     515       8        LOCAL_TIMESTAMP
     516    variable    ERROR_STRING

   Note that the type values are not sequential with existing RSVP IF_ID
   ERROR_SPEC object TLV assignments.  This is intentional and is
   intended to provide space for future error TLVs.

   This document also defines the I bit in the Admin Status Object, see
   Section 3.2.1.  This bit field was originally defined in Section 7.1
   of [RFC3473].  We request IANA to begin managing assignment of bits
   in the Admin Status Object, and that the bits be allocated through
   IETF Consensus actions.  Within the 32 bit field in the Admin Status
   Object, the defined bits are:

     Value      Name                              Reference
     ---------- --------------------------------- -----------------
     0x80000000 Reflect (R)                       [RFC3473/RFC3471]
     0x00000010 Inhibit Alarm Communication (I)   [This document]
     0x00000004 Testing (T)                       [RFC3473/RFC3471]
     0x00000002 Administratively down (A)         [RFC3473/RFC3471]
     0x00000001 Deletion in progress (D)          [RFC3473/RFC3471]


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce