Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11

From: Attila Takacs <[email-masked]>
Date: Sun, 12 Jan 2014 07:38:59 +0000

Hi David,
Thanks for the review! 
Please look for [at] below to see how we address your comments.
Attila

-----Original Message-----
From: Black, David [mailto:[email-masked]] 
Sent: Sunday, December 29, 2013 6:51 PM
To: General Area Review Team ([email-masked]); Attila Takacs; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11

One additional nit - Don Fedyk's email address listed in the draft does not work.

[at] email address updated.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Sunday, December 29, 2013 9:46 PM
> To: General Area Review Team ([email-masked]); 
> [email-masked]; [email-masked]; 
> [email-masked]
> Cc: Black, David; [email-masked]; [email-masked]; [email-masked]
> Subject: Gen-ART review of draft-ietf-ccamp-oam-configuration-fwk-11
> 
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments 
> you may receive.
> 
> Document: draft-ietf-ccamp-oam-configuration-fwk-11
> Reviewer: David L. Black
> Review Date: December 29, 2013
> IETF LC End Date: January 5, 2014
> 
> Summary: This draft is basically ready for publication, but has nits 
> that should be fixed before publication.
> 
> This draft describes the GMPLS framework for signaling OAM 
> configuration, and specifies additional RSVP elements to support that 
> signaling.  Knowledge of RSVP, and specifically RSVP-TE is assumed; 
> beyond that, the draft is complete, although it is very detailed - see 
> editorial comment below on Section 3.
> 
> Nits/editorial comments:
> 
> Sections 3.1-3.3 dive into the details very quickly.  They would be 
> easier to understand if there was an overview paragraph near the start 
> of Section 3 that describes the roles of the two ADMIN_STATUS flags 
> and the two LSP Attributes flags in OAM configuration (establishment, 
> change/adjustment, deletion) before the current text that contains the details of RSVP message processing.
> 

[at]  Added the two paragraphs below preceding the start of the detailed discussions of Sections 3.1-3.3.

      Administrative Status Information is carried in the
      ADMIN_STATUS Object.  The Administrative Status Information is
      described in [RFC3471], the ADMIN_STATUS Object is specified for
      RSVP-TE in [RFC3473]. Two bits are allocated for the
      administrative control of OAM monitoring: the "OAM Flows
      Enabled" (M) and "OAM Alarms Enabled" (O) bits.  When the "OAM
      Flows Enabled" bit is set, OAM mechanisms MUST be enabled; if it
      is cleared, OAM mechanisms MUST be disabled.  When the "OAM
      Alarms Enabled" bit is set OAM triggered alarms are enabled and
      associated consequent actions MUST be executed including the
      notification to the management system.  When this bit is
      cleared, alarms are suppressed and no action SHOULD be executed
      and the management system SHOULD NOT be notified.

     The LSP_ATTRIBUTES and the LSP_REQUIRED_ATTRIBUTES objects
      are defined in [RFC5420] to provide means to signal LSP
      attributes and options in the form of TLVs.  Options and
      attributes signaled in the LSP_ATTRIBUTES object can be passed
      transparently through LSRs not supporting a particular option or
      attribute, while the contents of the LSP_REQUIRED_ATTRIBUTES
      object MUST be examined and processed by each LSR. One bit "OAM
      MEP entities desired" is allocated in the LSP Attributes Flags
      TLV to be used in the LSP_ATTRIBUTES object.  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. One bit "OAM MIP entities desired" is
      allocated in the LSP Attributes Flags TLV to be used in the
      LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUES objects. If the "OAM
      MIP entities desired" bit is set in the LSP_ATTRIBUTES Flags TLV
      in the LSP_REQUIRED_ATTRIBUTES Object, it is indicating that the
      establishment of OAM MIP entities is required at every transit
      node of the signaled LSP.

> There are a number of instances of "(IANA to assign)" in section 4 
> that the RFC Editor will need to remove - an RFC Editor note to that 
> effect should be inserted at the start of Section 4.

[at] note added
> 
> Section 4.5 is necessarily incomplete on P2MP considerations, because 
> (as it says) "P2MP OAM mechanisms are very specific to the data plane technology".
> It would be helpful if section 4.5 contained language indicating what 
> a specific data plane specification should include to completely 
> specify P2MP OAM configuration for that data plane.
> 

[at] Updated the text to reflect that the procedures highlighted in the section are the baseline aspects that a technology specific document should specify for a particular OAM technology to be sufficiently complete for use. It would be difficult to indicate what would be required for a complete P2MP OAM specification for any data plane; hence we took the approach to clarify what the minimum requirements are. This is basically what is described in Section 4.5. 

> idnits 2.13.01 didn't find anything that needs attention.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer EMC Corporation, 176 South St., 
> Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------