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

[Attila Takacs <[e-mail]>]

Hi Adrian, all,
Thanks for the review! 
We have updated the document to address your comments. You can also find below the updates we have made to resolve your comments, look for [at].
Thanks,
Attila

-----Original Message-----
From: CCAMP [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: Monday, November 18, 2013 2:30 PM
To: [e-mail]
Cc: 'CCAMP WG'
Subject: [CCAMP] AD review of draft-ietf-ccamp-oam-configuration-fwk

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

[at] Thanks, I have updated the IANA section with the suggested text.
---

Please expand OAM and LSP in the Abstract.


[at] Done.
---

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.

[at] Aligned to rosetta-stone
---

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.

[at] Thanks, changed to the suggested text.
---

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.

[at] The use of OAM Configuration information in the Resv message is described in Section 3. To clarify the operation in the above case I have added the following paragraph to Section 3.1:

In case an egress LSR does not support the extensions
               defined in this document, according to RFC5420, it will silently ignore the new
               LSP Attributes Flags as well as the TLVs carrying additional OAM
               configuration information, and therefore no error will be raised
               that would notify the ingress LSR about the missing OAM
               configuration actions on the egress side. However, as
               described above, an egress LSR conformant to the specification
               of this document will set the LSP Attributes Flags and include
               the OAM Configuration TLV in the Resv message indicating the
               configuration of the OAM mechanisms, therefore an ingress LSR
               by detecting the missing information in the Resv message will
               be able to recognize that the remote end does not support the
               OAM configuration functionality and therefore it SHOULD tear
               down the LSP, and if appropriate signal the LSP without any OAM
               configuration information.
---

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.

[at] Thanks, changed to the suggested text.
---

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)



[at] I added the following clarification.

If an intermediate LSR does not support the
        extensions defined in this document it will not recognize the
        "OAM MIP entities desired" flag and although the
        LSP_REQUIRED_ATTRIBUTES object was used it will not configure
        MIP entities and will not raise any errors. If LSRs that are
        not supporting this document are to be assumed in the network,
        the ingress LSR SHOULD collect per-hop information about the
        LSP Attributes utilizing the LSP Attributes sub-object of the
        Record Route Object as defined in RFC5420. 
When the Record Route object is received
        the ingress SHOULD check whether all intermediate LSRs set the
        "OAM MIP entities desired" flag indicating support of the
        function, if not, depending on operator policy the LSP MAY
        need to be torn down. </t>
---

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.

[at] removed "(3)"
---

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".

[at] Thanks, changed to the suggested text.
---

Section 4.2

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

[at] Only one, changed text:
OLD
The OAM Configuration TLV MAY be carried in
               the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv
               messages.
NEW
One OAM Configuration TLV MAY be carried in
               the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object in Path and Resv
               messages.
---

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

[at]  added the following paragraph for clarification.

Two groups of TLVs are defined: generic sub-TLVs and
               technology specific sub-TLVs. Generic sub-TLVs carry
               information that are applicable independent of the actual OAM
               technology, while technology specific sub-TLVs are providing
               configuration parameters for specific OAM technologies. This
               document defines one generic sub-TLV, see Section 4.2.1, while it is
               foreseen that technology specific sub-TLVs will be defined by
               separate documents.
---

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.

[at] Thanks, changed to the suggested text.
---

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.

[at] Added the text below.
The TLV is padded to 4-octet alignment. The Length
               field indicates the size of the padded TLV in octets.
---

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".

[at] Thanks, changed to the suggested text.
---

Section 4.3

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

[at] done.
---

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?

[at] Changed to "When the "OAM Flows Enabled" bit is set,
        OAM mechanisms MUST be enabled; if it is cleared, OAM
        mechanisms MUST be disabled."
---

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.

[at]  The operation and use of these two bits are described in Section 3. To highlight this I added a note saying: "For a detailed description of the use of these flags see Section 3."

_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp