GMPLS - Communication of Alarm Information
draft-ietf-ccamp-gmpls-alarm-spec-06

[Ballot discuss]
Global Timestamp requires a better description.  RFC 4049 says:
  >
  > The integer value is the number of seconds, excluding leap seconds,
  > after midnight UTC, January 1, 1970.  This time format cannot
  > represent time values prior to January 1, 1970.  The latest UTC time
  > value that can be represented by a four-octet integer value is
  > 03:14:07 on January 19, 2038, which is represented by the hexadecimal
  > value 7FFFFFFF.
  >
  Does this specification intend the same use of the sign bit?
  I strongly suspect that leap seconds are being ignored here too.

  I expect to see the following text to resolve this point:
  >
  > An unsigned fixed-point integer that indicates the number of seconds
  > since 00:00:00 UT on 1 January 1970 according to the clock on the node
  > that originates this TLV. This time MAY include leap seconds if they are
  > used by the local clock and SHOULD contain the same time value as used
  > by the node when the alarm is reported through other systems (such as
  > within the Management Plane) if global time is used in those reports.

I am putting this back into "revised ID needed" since
another update is imminent in order to respond to the
last point in Russ' DISCUSS (the authors should have
this in relatively soon).

[Ballot discuss]
Global Timestamp requires a better description.  RFC 4049 says:
  >
  > The integer value is the number of seconds, excluding leap seconds,
  > after midnight UTC, January 1, 1970.  This time format cannot
  > represent time values prior to January 1, 1970.  The latest UTC time
  > value that can be represented by a four-octet integer value is
  > 03:14:07 on January 19, 2038, which is represented by the hexadecimal
  > value 7FFFFFFF.
  >
  Does this specification intend the same use of the sign bit?
  I strongly suspect that leap seconds are being ignored here too.

[Ballot discuss]
Section 3.1.1:

The Severity TLV has the following format:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type            |            Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Reserved                  |Impact |  Severity    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved: 24 bits

        This field is reserved.  It MUST be set to zero on generation,
        MUST be ignored on receipt and MUST be forwarded unchanged and
        unexamined by transit nodes.

The number of bits that are reserved are in error, only 20 bits are reserverd.


Section 3.1.1:

      Impact: 4 bits

        Indicates the impact of the alarm indicated in the TLV.  See
        [M.20] for a general discussion on classification of failures.
        The following values are defined:

          Value      Definition
          -----      ---------------------
            0        Unspecified impact
            1        Non-Service Affecting (Data traffic not interrupted)
            2        Service Affecting (Data traffic is interrupted)

      Severity: 8 bits

        Indicates the impact of the alarm indicated in the TLV.  See
        [RFC3877] and [M.3100] for more information on severity.  The
        following values are defined:

          Value      Definition
          -----      ----------
            0        Cleared
            1        Indeterminate
            2        Critical
            3        Major
            4        Minor
            5        Warning

The formulation of the two above definitions are unclear. Are the values define in the present document or the exact definitions present in referenced documents used? Which it is must be clarified. If it is the former, then I am missing IANA section for these registries.

[Ballot discuss]
Section 3.1.1:

The Severity TLV has the following format:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type            |            Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Reserved                  |Impact |  Severity    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Reserved: 24 bits

        This field is reserved.  It MUST be set to zero on generation,
        MUST be ignored on receipt and MUST be forwarded unchanged and
        unexamined by transit nodes.

The number of bits that are reserved are in error, only 20 bits are reserverd.

[Ballot comment]
The following text in Section 5 is confusing, or at least confused me:

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

I suggest to clarify it by replacing it with:

NEW:
  Additionally, Section 3.1.3 defines a new RSVP Error Code.  The Error
  Code is "Alarms" and the suggested Error Code value is 28. The
  interpretation of the Error Value field is context-specific. The
  context is derived from the value of the Error Code field. When
  the Error Code field indicates "Alarms", the value of the Error Value
  field is taken from the IANA ITU Alarm TC MIB defined in the Alarm MIB
  [RFC3877]

IANA Last Call Comments:

he reservations are going to be two different registries
http://www.iana.org/assignments/rsvp-parameters
and http://www.iana.org/assignments/gmpls-sig-parameters
Below is slightly modified version of the standard responses that I think
are clearer for future processing as well as understanding by the editors.


first assignment:
Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/
rsvp-parameters

A new class named ALARM_SPEC will be created in the 11bbbbbb range (197
suggested) with following values

o Class = TBA, C-Type = 1 [RFC-ccamp-gmpls-alarm-spec]
Reserved. (C-Type value defined for ERROR_SPEC, but is not defined
for use with ALARM_SPEC.)

o Class = TBA, C-Type = 2 [RFC-ccamp-gmpls-alarm-spec]
Reserved. (C-Type value defined for ERROR_SPEC, but is not defined
for use with ALARM_SPEC.)

o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 [RFC-ccamp-gmpls-
alarm-spec]
Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].

o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 [RFC-ccamp-gmpls-
alarm-spec]
Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].

This concludes the assignments in this section of the above registry.

Second assignment:

Upon approval of this document, the IANA will make the following assignments
in the "GMPLS Signaling Parameters" registry located at http://www.iana.org/
assignments/gmpls-sig-parameters section "Interface_ID Types"
xx2 8 REFERENCE_COUNT [RFC-ccamp-gmpls-alarm-spec]
xx3 8 SEVERITY [RFC-ccamp-gmpls-alarm-spec]
xx4 8 GLOBAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec]
xx5 8 LOCAL_TIMESTAMP [RFC-ccamp-gmpls-alarm-spec]
xx6 variable ERROR_STRING [RFC-ccamp-gmpls-alarm-spec]
(51 suggested for xx)


This concludes assignments in this registry.

Third assignment
Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/
rsvp-parameters
In the Admin-Status C-types a new list will be created with the following
values
Value Name Reference
---------- --------------------------------- -----------------
0x80000000 Reflect (R) [RFC3473/RFC3471]
0x00000010 Inhibit Alarm Communication (I) [RFC-ccamp-gmpls-alarm-spec]
0x00000004 Testing (T) [RFC3473/RFC3471]
0x00000002 Administratively down (A) [RFC3473/RFC3471]
0x00000001 Deletion in progress (D) [RFC3473/RFC3471]

This concludes the assignments requested by this document.

[Ballot discuss]
The references to the values used for IANAItuProbableCause in the Alarm MIB [RFC3877]in sections 3.1.3 and 5 require an assignment of a new value in the IANAItuProbableCause TC which may be problematic. I am entering this DISCUSS to make sure that we understand the issue and methodology of assigning these values, and will be glad to clear it when we make sure that this is well defined. 

Section 3.1.3 refers to the (RSVP)error code values used with both ERROR_SPEC and ALARM_SPEC objects and states that the values used in the Error Values field are the same as the values used for IANAItuProbableCause in the Alarm MIB [RFC3877]. 

The text in Section 5 then states:

'The Error Code is "Alarms" and uses Error Values defined in the Alarm MIB[RFC3877].  The suggested Error Code value is 28.'

It is not clear what 'suggested' means, and what is the suggestion based on. Currently at http://www.iana.org/numbers.html there is a question mark in the Registration/Assignment Procedures for IANA ITU Alarm TC MIB, while in http://www.iana.org/assignments/ianaitualarmtc-mib the last assgned value for communication alarms related causes is 26.

My suggestion:

1. IANA should fill in the Registration/Assignment Procedure for IANA ITU Alarm TC MIB. I believe that 'First Come First Serve with specification recommended' would be appropriate
2. This document should either make a crisp statement about the chosed value if this is agreed with IANA, or abstain to make any suggestion in the text and rather say 'The suggested Error Code value is defined by the enumerated value gmplsAlarm'.
3. The Abstract section of the document should mention that a new value is defined for the IANAItuProbableCause TC, together with the existing reference to the modification of the RSVP ERROR_SPEC object.
4. Value 27 should be used if not allocated yet, rather than value 28.

[Ballot comment]
Section 3., paragraph 1:
>    The communication of alarm information is optional.

  Nit: s/optional/OPTIONAL/


Section 3.1.1., paragraph 1:
>    All TLVs defined in this section are optional.

  Nit: s/optional/OPTIONAL/


Section 3.1.1., paragraph 8:
>          The number of times this alarm has been repeated as determined
>          by the reporting node.  This field MUST NOT be set to zero.

  "...when sent, and a received TLV with a reference count of zero MUST
  be ignored." (I assume?) Also, is there a need to describe what
  happens at rollover?


Section 3.1.1., paragraph 22:
>          The number of seconds since 0000 UT on 1 January 1970,
>          according to the clock on the node that originates this TLV.

  Rolls over in 2038 - do we need to care?


Section 3.1.2., paragraph 2:
>    Nodes that support the communication of alarm information, SHOULD
>    record the information contained in a received ALARM_SPEC for later
>    use.

  Can't parse the sentence.


Section 3.1.4., paragraph 1:
>    The support of ALARM_SPEC objects is optional.  Non-supporting nodes
>    will pass the objects through the node unmodified, because the
>    ALARM_SPEC object has a C-Num of the form 11bbbbbb.

  Nit: s/optional/OPTIONAL/ and s/will/MUST/ (or SHOULD?)


Section 5., paragraph 1:
>    This section uses the terminology of BCP 26 "Guidelines for Writing
>    an IANA Considerations Section in RFCs" [BCP26].

  Nit: Missing Reference: 'BCP26' is mentioned on line 635, but not defined


Section 6.2., paragraph 4:

>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>            Requirement Levels," RFC 2119.

  Nit: Should probably be normative.

AD comments:

> Abstract

Should say which RFCs are updated.

> 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs

>    The Global Timestamp TLV has the following format:
>
>        0                  1                  2                  3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              Type            |            Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                        Global Timestamp                      |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>
> Berger, et. al.               
>                                  [Page 7]
>
> Internet Draft  draft-ietf-ccamp-gmpls-alarm-spec-02.txt  November 2004
>
>
>      Global Timestamp: 32 bits
>
>          The number of seconds since 0000 UT on 1 January 1970,
>          according to the clock on the node that originates this TLV.
>
>      Only one Global Timestamp TLV may be included in an object.
>
>    The Local Timestamp TLV has the following format:
>
>        0                  1                  2                  3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              Type            |            Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                        Local Timestamp                        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      Local Timestamp: 32 bits
>
>          Number of seconds reported by the local system clock at the
>          time the associated alarm was detected on the node that
>          originates this TLV.
>
>      Only one Local Timestamp TLV may be included in an object.

Not clear what's put in it.

>  The Error String TLV has the following format:
>
>        0                  1                  2                  3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              Type            |            Length            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                              |
>      //          Error String      (NULL padded display string)      //
>      |                                                              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      Error String: 32 bits minimum (variable)
>
>          A string of characters, representing the type of error/alarm.
>          This string is padded to the next largest 4 byte boundary using
>          null characters.  Null padding is not required when the string
>          is 32-bit aligned.  The contents of error string are
>          implementation dependent.  See the condition types listed in
>          Appendices of [GR833] for a list of example strings.  Note
>          length includes padding.
>
>      Multiple Error String TLVs may be included in an object.

I think we're going to have a problem with internationalization here.
I'll ask Ted.

> 3.1.2. Procedures

...
> TLVs SHOULD be included to identify the
>    interface, if any, the severity, the time and a (brief) string
>    associated with the alarm.

This is very open to interpretation, please identify which TLVs.

>    There are two ways to indicate time.  A global timestamp TLV is used
>    to provide an absolute time reference for the occurrence of an alarm.
>    The local timestamp TLV is used to provide time reference for the
>    occurrence of an alarm that is relative to other information
>    advertised by the node.  The global timestamp SHOULD be used on nodes
>    that maintain an absolute time reference.  Both timestamp TLVs MAY be
>    used simultaneously.

Note, it's still unclear what gets put in the local timestamp TLV.

> 3.2.1. Updated Admin Status Object
>
>
>    The format of the Admin_Status object is updated to include the I
>    bit:
>
>        0                  1                  2                  3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |            Length            | Class-Num(196)|  C-Type (1)  |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |R|                        Reserved                  |I| |T|A|D|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Inhibit Alarm Communication (I): 1 bit
>          When set, indicates that alarm communication is disabled for
>          the LSP and that nodes SHOULD NOT add local alarm information.
>
>      See [RFC3471] for the definition of the remaining bits.

Seems the doc should say "Updates 3471" too.

> 3.2.2. Procedures

>    The I bit may be set and cleared using the procedures defined in
>    Sections 7.2 and 7.3 of [RFC3473].  A node that receives (or
>    generates) an Admin_Status object with the A or I bits set (1),
>    SHOULD remove all locally generated alarm information from the
>    matching LSP's outgoing Path and Resv messages.  When a node receives
>    (or generates) an Admin_Status object with the A and I bits clear
>    (0), it SHOULD add any local alarm information to the matching LSP's
>    outgoing Path and Resv messages.

"SHOULD add any" ? sounds strange.

> 4. Security Considerations
>
>    Some operators may consider alarm information as sensitive.  To
>    support environments where this is the case, implementations SHOULD
>    allow the user to disable the generation of ALARM_SPEC objects, or to
>    filter or correlate them at domain boundaries.
>
>    This document introduces no additional security considerations.  See
>    [RFC3473] for relevant security considerations.

What would happen if alarm info was spoofed?

> 5. IANA Considerations

The section is not clear what exact name spaces IANA has to create and
manage.

Subject: Draft ready for ADs : draft-ietf-ccamp-gmpls-alarm-spec-02.txt
Date: Fri, 21 Jan 2005 11:52:38 -0000
From: "Adrian Farrel"
To:
Cc: "Igor Bryskin" , "Brungard, Deborah A, ALABS"
    , "Dimitri Papadimitriou"
    , ,
    ,
Reply-to: "Adrian Farrel"

This draft has passed through WG last call and has been updated to my
satisfaction. (Note that I am a co-author.)

Please can you start the AD review process ready to take the draft to the
IESG.