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 protected]] Sent: Sunday, December 29, 2013 6:51 PM To: General Area Review Team ([email protected]); Attila Takacs; [email protected]; [email protected] Cc: [email protected]; [email protected]; [email protected] 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 protected]); > [email protected]; [email protected]; > [email protected] > Cc: Black, David; [email protected]; [email protected]; [email protected] > 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 protected] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
