GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration
draft-ietf-ccamp-oam-configuration-fwk-13

[Ballot comment]
This is a well written document and I just have a few nits that you might consider.

There were a number of terms that as far as I could see were unexpanded on first use and are not "well known". I picked up DWDM, RSVP-TE, LSP, WSON, TDM, SDH/SONET. Please can I suggest an quick abbreviation scrub.

With the text "the ADMIN_STATUS Object is specified for RSVP-TE in [RFC3473]. "  This ref should go a little earlier in the para, when you first use the term

"If this is not possible, a PathErr SHOULD be sent "
and
"a ResvErr may be sent"

Presumable these are "messages" or "responses"


    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 (IANA)        |          Length              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    OAM Type  |                Reserved                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  ~                          sub-TLVs                            ~
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Type: indicates a new type: the OAM Configuration TLV (IANA to
  assign).

Is the length syntax well known in this context?

[Ballot discuss]
This is an extremely trivial DISCUSS, and it will take about 17 milliseconds to fix it.  In the subsections of Section 5.5, registration policies are specified ("IETF Review" and "Experimental") without reference to any definition of those policies (RFC 5226).  I suggest this change:

OLD
  IANA is requested to create sub-registries as defined in the
  following subsections:
NEW
  IANA is requested to create sub-registries as defined in the
  following subsections.  The registration procedures specified
  are as defined in [RFC5226].
END

(And, of course, add a normative reference to RFC 5226.)

[Ballot comment]
A very minor editorial point in the abstract: I found myself wishing that the abstract used "OAM" a few times, instead of repeating the expansion five times.  Please consider making it "Operations, Administration and Maintenance (OAM)" the first time, and just "OAM" the other four.

[Ballot discuss]
I'm holding this Discuss for two issues raised by IANA. I will move to "Yes" when they have been addressed.

1. The authors need to update the next version of the document
to clarify the value 0 in the new Error subcode registry and
use the term "Unassigned", rather than "Not allocated".

We can handle this with an RFC Editor note, but I need the authors to agree some text.

2. You indicated that "There is no top value to the range." in section 5.5.3.  That means that the new created registry
"RSVP-TE OAM Configuration Registry" has no maximum values (bit numbers).  We want to make sure we understood it correctly.

This can be answered by email. Are you indicating that there can be any number of bits allocated over time? Of course, there is a practical limit to this set by the length field of TLVs, Objects, and Messages.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ccamp-oam-configuration-fwk-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has questions about some of the requested actions in this draft
document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are nine actions which IANA must complete.

First, in the Administrative Status Information Flags subregistry of the Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters registry located at:

http://www.iana.org/assignments/gmpls-sig-parameters/

two new flags will be registered as follows:

Bit Number: [ TBD-at-registration ]
Hex Value: [ TBD-at-registration ]
Name: OAM Alarms Enabled (O)
Reference: [ RFC-to-be ]

Bit Number: [ TBD-at-registration ]
Hex Value: [ TBD-at-registration ]
Name: OAM Flows Enabled (M)
Reference: [ RFC-to-be ]

Second, in the Attribute Flags subregistry of the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/

two new flags will be registered as follows:

Bit No: [ TBD-at-registration ]
Name: OAM MEP entities desired
Attribute Flags Path: Yes
Attribute Flags Resv: Yes
RRO: Yes
Reference: [ RFC-to-be ]

Bit No: [ TBD-at-registration ]
Name: OAM MIP entities desired
Attribute Flags Path: Yes
Attribute Flags Resv: Yes
RRO: Yes
Reference: [ RFC-to-be ]

Third, in the Attributes TLV Space subregistry of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) Parameters registry located at:

http://www.iana.org/assignments/rsvp-te-parameters/

a single, new attribute will be registered as follows:

Type: [ TBD-at-registration ]
Name: OAM Configuration TLV
Allowed on LSP_ATTRIBUTZES: Yes
Allowed on LSP_REQUIRED_ATTRIBZUTES: Yes
Reference: [ RFC-to-be ]

Fourth, in the Error Codes and Globally-Defined Error Value Sub-Codes subregistry of the Resource Reservation Protocol (RSVP) registry located at:

http://www.iana.org/assignments/rsvp-parameters

a new error code will be registered as follows:

Error Code: [ TBD-at-registration ]
Meaning: OAM Problem
Reference: [ RFC-to-be ]

The error code will be registered in the range 0-239.

Fifth, a new Error subcode registry will be created for the new error code created in the fourth action above.

This new Error Code has the following globally-defined Error Value sub-codes:

Value | Description                    | Reference
------+---------------------------------+--------------
  1  | MEP establishment not supported | [ RFC-to-be ]
  2  | MIP establishment not supported | [ RFC-to-be ]
  3  | Unsupported OAM Type            | [ RFC-to-be ]
  4  | Configuration Error            | [ RFC-to-be ]
  5  | OAM Type Mismatch              | [ RFC-to-be ]
  6  | Unsupported OAM Function        | [ RFC-to-be ]
 
QUESTIONS:
Should the value 0 (zero) be marked as "Reserved" or "Unassigned"?
What is the maximum value for this new Error Value sub-codes registry?

Sixth, IANA will create a new registry called the "RSVP-TE OAM Configuration Registry" in the IANA Matrix located at:

http://www.iana.org/protocols

and this new registry will have a reference of [ RFC-to-be ].  This new registry will have a set of new subregistries described in the following steps.

Seventh, IANA will create a new "OAM Types" sub-registry of the "RSVP-TE OAM Configuration Registry" created in step six above.  The new registry will be maintained through IETF Review as defined in RFC 5226.  The reference for the new subregistry will be [ RFC-to-be ]. 

The value is to be selected from the range 0-255.  There are no initial registrations in the new subregistry.  Future registrations are made up of the following fields:

OAM Type Number
OAM Type Description
Reference

QUESTION: the current version said:

  There are no initial values in this registry.  IANA should show the
  registry as follows:

      OAM Type Number | OAM Type Description | Reference
      ----------------+----------------------+--------------
        0-255          | Not allocated        |


Do the authors prefer to use the term "Not allocated" in the new created
registry?  Or, do authors mean "Unassigned" rather?  Please see
http://tools.ietf.org/html/rfc5226#section-4. 

Eighth, IANA will create a new "OAM Sub-TLVs" sub-registry of the "RSVP-TE OAM Configuration Registry" created in step six above.  The reference for the new subregistry will be [ RFC-to-be ].

The new registry will be maintained using the following registration procedures - as defined in RFC 5226:

Range      | Purpose                      | Registration Procedures
------------+------------------------------|------------------------
0-31        | Generic Sub-TLVs            | IETF Review
32-65534    | Technology-specific Sub-TLVs | IETF Review
65535-65536 | Experimental Sub-TLVs        | Experimental

There are initial values in this registry as follows:

Sub-TLV Type | Description                | Reference
-------------+----------------------------+--------------
    0        | Reserved                  | [ RFC-to-be ]
    1        | OAM Function Flags Sub-TLV | [ RFC-to-be ]
  2-31      | Not allocated              |
  32-65534  | Not allocated              |

QUESTION: Can the authors please clarify the term "Not allocated"
depicted above?  Does it mean "Unassigned" (which means 'available
for future assignments.')? 

Ninth, IANA will create a new "OAM Function Flags" sub-registry of the "RSVP-TE OAM Configuration Registry" created in step six above.  The reference for the new subregistry will be [ RFC-to-be ].  The registry will be maintained via IETF Review as defined by RFC 5226.

There is no top value to the range of values in this new registry. 

There are initial registrations in this subregistry as follows:

OAM Function Flag | Description
bit number        |
------------------+---------------------------------------------
  0              | Continuity Check (CC)
  1              | Connectivity Verification (CV)
  2              | Fault Management Signal (FMS)
  3              | Performance Monitoring/Loss (PM/Loss)
  4              | Performance Monitoring/Delay (PM/Delay)
  5              | Performance Monitoring/Throughput Measurement
                  |    (PM/Throughput)
  6-...          | Not allocated
 
QUESTION: Same question as above.  Can the authors please clarify
the term "Not allocated" depicted above?  Should it be "Unassigned"
as defined in RFC5226?

IANA understands that these nine actions are the only ones need to be
completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (GMPLS RSVP-TE extensions for OAM Configuration) to Proposed Standard

The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'GMPLS RSVP-TE extensions for OAM Configuration'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-1-5 (this last call is extended slightly to
cover the holiday period). Exceptionally, comments may be sent to
iesg@ietf.org instead. In either case, please retain the beginning of the
Subject line to allow automated sorting.

Abstract

  Operations, Administration and Maintenance is an integral part of
  transport connections, hence it is required that Operations,
  Administration and Maintenance functions are activated/deactivated in
  sync with connection commissioning/decommissioning; avoiding spurious
  alarms and ensuring consistent operation.  In certain technologies,
  Operations, Administration and Maintenance entities are inherently
  established once the connection is set up, while other technologies
  require extra configuration to establish and configure Operations,
  Administration and Maintenance entities.  This document specifies
  extensions to RSVP-TE to support the establishment and configuration
  of Operations, Administration and Maintenance entities along with
  Label Switched Path signaling.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-oam-configuration-fwk/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1021/
  http://datatracker.ietf.org/ipr/1623/

AD review
======

Thank you for this document. I think it is well written and clear. It is
very nearly ready to be advanced for publication, but we need to do a
little work on the IANA section to make it completely clear for IANA. I
suggest the following, but please review it carefully because I have
introduced new material that you did not have in your original text.

I also have some smaller nits and editorial comments, and a few places
where it would be really helpful to clarify the text.

I've moved the I-D status to show I expect to see a revision, but please
discuss these points with me if you like.

Thanks for the work.

Adrian

===

OLD
5.  IANA Considerations

  Two bits ("OAM Alarms Enabled" (O) and "OAM Flows Enabled" (M)) needs
  to be allocated in the ADMIN_STATUS Object.

  Two bits ("OAM MEP entities desired" and "OAM MIP entities desired")
  needs to be allocated in the LSP Attributes Flags Registry.

  This document specifies one new TLV to be carried in the
  LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES objects in Path and Resv
  messages: OAM Configuration TLV.

  One new Error Code: "OAM Problem" and a set of new values: "MEP
  establishment not supported", "MIP establishment not supported",
  "Unsupported OAM Type", "Configuration Error", "OAM Type Mismatch"
  and "Unsupported OAM Function" needs to be assigned.

  IANA is requested to open a new registry: "RSVP-TE OAM Configuration
  Registry" that maintains the "OAM Type" code points, an associated
  sub-TLV space, and the allocations of "OAM Function Flags" within the
  OAM Configuration TLV.


  RSVP-TE OAM Configuration Registry

    OAM Type          Description
  ------------      ------------------
      0-255              Reserved


  Sub-TLV Type                  Description
  ------------      ------------------------------------
      0                          Reserved
      1                  OAM Function Flags Sub-TLV
      2-31              Reserved for generic Sub-TLVs
      32-          Reserved for technology specific Sub-TLVs


  OAM Function Flag bit#      Description
  ----------------------  -------------------------------
    0                    Continuity Check (CC)
    1                    Connectivity Verification (CV)
    2                    Fault Management Signal (FMS)
    3                    Performance Monitoring/Loss (PM/Loss)
    4                    Performance Monitoring/Delay (PM/Delay)
    5                    Performance Monitoring/Throughput Measurement
                          (PM/Throughput)
    6-                    Reserved
NEW
5.  IANA Considerations

5.1. ADMIN_STATUS Object Bit Flags

  IANA maintains a registry called "Generalized Multi-Protocol Label
  Switching (GMPLS) Signaling Parameters" with a sub-registry called
  "Administrative Status Information Flags".

  IANA is requested to allocate two new flags as follows:

  Bit Number |  Hex Value | Name                    | Reference
  -----------+------------+--------------------------+----------------
    TBA      |  TBA      | OAM Alarms Enabled (O)  | [This.ID]
    TBA      |  TBA      | OAM Flows Enabled" (M)  | [This.ID]
 
5.2. LSP Attributes Flags

  IANA maintains a registry called "Resource Reservation Protocol-
  Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
  "Attribute Flags".

  IANA is requested to allocate two new flags as follows:

  Bit | Name                    | Attribute  | Attribute  | RRO | Ref
  No  |                          | Flags Path | Flags Resv |    |
  ----+--------------------------+------------+------------+-----+-----
  TBA | OAM MEP entities desired |  Yes      |    No      | Yes |
  TBA | OAM MIP entities desired |  Yes      |    No      | Yes |

5.3. New LSP Attributes

  IANA maintains a registry called "Resource Reservation Protocol-
  Traffic Engineering (RSVP-TE) Parameters" with a subregistry called
  "Attributes TLV Space"
 
  IANA is requested to allocate one new TLV type as follows:

  Type | Name                  | Allowed on    | Allowed on    | Ref
        |                      | LSP_ATTRIBUTES | LSP_REQUIRED_ |
        |                      |                | ATTRIBUTES    |
  -----+-----------------------+----------------+---------------+------
    TBA | OAM Configuration TLV |    Yes        |    Yes      | 

5.4. RSVP Error Code

  IANA maintains a registry called "Resource Reservation Protocol
  (RSVP) Parameters" with a subregistry called "Error Codes and
  Globally-Defined Error Value Sub-Codes".

  IANA is requested to allocate one new Error Code as follows:

  Error Code | Meaning    | Reference                 
  -----------+-------------+-------------
      TBA    | OAM Problem |  [This.ID]

  The value is to be selected from the range 0-239.

  The following Error Value sub-codes are defined for this new Error
  Code as follows:

  Value | Description                    | Reference
  ------+---------------------------------+--------------
    1  | MEP establishment not supported | [This.ID]
    2  | MIP establishment not supported | [This.ID]
    3  | Unsupported OAM Type            | [This.ID]
    4  | Configuration Error            | [This.ID]
    5  | OAM Type Mismatch              | [This.ID]
    6  | Unsupported OAM Function        | [This.ID]

5.5. RSVP-TE OAM Configuration Registry

  IANA is requested to create a new registry called "RSVP-TE OAM
  Configuration Registry".

  IANA is requested to create sub-registries as defined in the
  following subsections:
 
5.5.1. OAM Types Sub-Registry

  IANA is requested to create the "OAM Types" sub-registry of the
  "RSVP-TE OAM Configuration Registry" as follows:

    Range | Registration Procedures
  -------+-------------------------
    0-255 | IETF Review

    There are no initial values in this registry.  IANA should show the
    registry as follows:


    OAM Type Number | OAM Type Description | Reference
    ----------------+----------------------+--------------
    0-255          | Not allocated        |


5.5.2. OAM Sub-TLVs Sub-Registry

  IANA is requested to create the "OAM Sub-TLVs" sub-registry of the
  "RSVP-TE OAM Configuration Registry" as follows:

    Range      | Purpose                      | Registration Procedures
  -------------+------------------------------|------------------------
    0-31        | Generic Sub-TLVs            | IETF Review
    32-65534    | Technology-specific Sub-TLVs | IETF Review
    65535-65536 | Experimental Sub-TLVs        | Experimental

  IANA is requested to populate the registry as follows:

  Sub-TLV Type | Description                | Reference
  -------------+----------------------------+-------
      0        | Reserved                  | [This.ID]
      1        | OAM Function Flags Sub-TLV | [This.ID]
      2-31      | Not allocated              |
      32-65534  | Not allocated              |

5.5.3. OAM Function Flags Sub-Registry

  IANA is requested to create the "OAM Function Flags Sub-Registry"
  sub-registry of the "RSVP-TE OAM Configuration Registry".

  New values in the registry are allocated by "IETF Review". There is
  no top value to the range. Bits are counted from bit 0 as the first
  bit transmitted.

  IANA is requested to populate the registry as follows.

  OAM Function Flag | Description
  bit number        |   
  ------------------+---------------------------------------------
    0              | Continuity Check (CC)
    1              | Connectivity Verification (CV)
    2              | Fault Management Signal (FMS)
    3              | Performance Monitoring/Loss (PM/Loss)
    4              | Performance Monitoring/Delay (PM/Delay)
    5              | Performance Monitoring/Throughput Measurement
                    |    (PM/Throughput)
    6-...          | Not allocated
END

---

Please expand OAM and LSP in the Abstract.

---

In Section 3 you have some terms defined (MP, ME, MIP, MEP). Some of
these terms are consistent with the use of terms in draft-ietf-mpls-tp-
rosetta-stone and some are not. Is there a specific reason why you have
diverged from this other draft? If not, you should align this work.

---

Section 3.1

  When using the GMPLS control
  plane, establishment and enabling of OAM functions MUST be bound to
  RSVP-TE message exchanges.

I think you mean...

  When using the GMPLS control plane for both LSP establishment and to
  enable OAM functions on the LSPs, the control of both processes is
  bound to RSVP-TE message exchanges.

---

Section 4.1

  If the "OAM MEP entities desired" bit is set it is indicating that
  the establishment of OAM MEP entities are required at the endpoints
  of the signaled LSP.  If the establishment of MEPs is not supported
  an error MUST be generated: "OAM Problem/MEP establishment not
  supported".

I can see how this works for an implementation of this document that
chooses not to (or cannot) support OAM on a given LSP. I do not
understand how it works when a node that does not support this document
receives the "OAM MEP entities desired" bit set - it cannot return the
desired response because it doesn't support this document.

To handle this, I think you need to split the two cases.
1. Does not support the establishment of MEPs on this specific LSP
2. Does not support any establishment of MEPs.

In the second case you need to determine how this will be made to work.
Since 5420 specifies that the unknown bit in an LSP_ATTRIBUTE object
will be silently ignored, you need to use the absence of a positive
acknowledgement to indicate to the ingress that the function is not
supported.

See also Section 4.4.

---

Section 4.1

  This bit MUST only be set if the "OAM MEP entities desired" bit is
  set.

This is a rather unusual construction. I think you may mean...

  If the "OAM MEP entities desired" bit is not set then this bit MUST
  NOT be set.

---

Section 4.1

  If the establishment of a MIP is not supported
  an error MUST be generated: "OAM Problem/MIP establishment not
  supported".

Exactly the same problem as described for "OAM MEP entities desired"
above except for the additional behavior if used on
LSP_REQUIRED_ATTRIBUTES. (See also 4.4)

---

Section 4.2

  Type: indicates a new type: the OAM Configuration TLV (3) (IANA to
  assign).

If this is a specific request that the value 3 is assigned, you should
reflect this in Section 5.

---

Section 4.2

  When carried in the LSP_ATTRIBUTES
  Object, intermediate nodes not supporting the OAM Type pass the
  object forward unchanged as specified in [RFC5420], and only Label
  Edge Nodes MUST generate an error if the OAM Type is not supported at
  the LSP end-point.

There are a couple of issues here. You have defined a "Label Edge Node".
You also have another "only MUST" construction. How about...

  When carried in the LSP_ATTRIBUTES
  Object, intermediate nodes not supporting the OAM Type pass the
  object forward unchanged as specified in [RFC5420]. Ingress and
  egress nodes that support the OAM Configuration TLV but that do not
  support a specific OAM Type MUST respond with an error indicating
  "OAM Problem/Unsupported OAM Type".

---

Section 4.2

Can multiple copies of the OAM configuration TLV be present in one
LSP_ATTRIBUTES object?

---

I think section 4.2 needs to mention the generic sub-TLVs. Reading the
text as it stands, it appears that all sub-TLVs are for technology-
specific OAM. So you need:
- To explain generic sub-TLVs so that future sub-TLVs can be defined
- To include a forward pointer to 4.2.1

---

Section 4.2.1

  As the first sub-TLV the "OAM Function Flags Sub-TLV" MUST always be
  included in the "OAM Configuration TLV".

I think you mean:

  The "OAM Configuration TLV" MUST always include a single instance of
  the "OAM Function Flags Sub-TLV" and it MUST always be the first sub-
  TLV.

---

Section 4.2.1

You need to reiterate that the Length field counts octets (because for a
variable length bitmap someone might easily think it is a count of bits)
and then you need to explain how to set the length field and how to
handle padding.

---

Section 4.2.2

  One technology specific sub-TLV MAY be defined for each "OAM Type".
  This sub-TLV MUST contain any further OAM configuration information
  for that specific "OAM Type".  The technology specific sub-TLV, when
  used, MUST be carried within the OAM Configuration TLV.  IANA is
  requested to maintain the OAM technology specific sub-TLV space in
  the new "RSVP-TE OAM Configuration Registry".

The use of 2119 language here is odd. It is really meant for
implementation instructions, not to constrain future specifications.
How about saying:

  If technology-specific configuration information is needed for a
  specific "OAM Type", then this information is carried in a
  technology-specific sub-TLV. Such sub-TLVs are OPTIONAL and an
  OAM Configuration TLV MUST NOT contain more than one technology-
  specific sub-TLV. IANA is requested to maintain the OAM technology
  specific sub-TLV space in the new "RSVP-TE OAM Configuration
  Registry".

---

Section 4.3

s/are allocated by this draft/are allocated by this document/

---

Section 4.3

  When
  the "OAM Flows Enabled" bit is set, OAM packets are sent; if it is
  cleared, no OAM packets are emitted.


When the bit is sent, is that MAY, SHOULD, or MUST send OAM packets?
If clear, I think that is MUST NOT be sent.

Why do you say "OAM packets"? Doesn't this I-D apply to all OAM
mechanisms?

---

Section 4.3

  When the "OAM Alarms Enabled"
  bit is set OAM triggered alarms are enabled and associated consequent
  actions are executed including the notification to the management
  system.  When this bit is cleared, alarms are suppressed and no
  action is executed and the management system is not notified.

I understand "When this bit is cleared, alarms are suppressed" and "the
management system is not notified", but I don't understand "no action is
executed." If there is no action on OAM detecting some issue, then why
run OAM? There is clearly something you had in mind when you created two
separate admin statuses, but the purpose is not clear in your document.