[CCAMP] AD review of draft-ietf-ccamp-oam-configuration-fwk

["Adrian Farrel" <[e-mail]>]

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.