Re: [OPSAWG] WGLC on draft-ietf-opsawg-mpls-tp-oam-def

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Feb 02, 2011 at 11:32:22AM +0100, Bert (IETF) Wijnen wrote:
 
> 2. I am not sure that the document is clear in how/where I should categorize/put
>     CONFIGURATION. For example Netconf? Is that part of OAM? There is some
>     configuration listed under "Maintenance" on page 7.
>     I can see it can also be used for Provisioning.

My understanding is that the document takes the viewpoint that OAM is
mostly horizontal, that is inband (element <-> element), and NETCONF
pretty much is designed/expected to be used vertically (element <->
element mgr <-> network mgr). If my interpretation is correct, NETCONF
really is a Mgmt protocol, not an OAM protocol.

>     And then there is FCAPS, where it could fall under the C.

As the document states, FCAPS is a complementary functional
categorization, but even though NETCONF matches the C well, you also
need a configuration protocol to do things such as security
management. In fact, management protocols and data models usually work
across the functional FCAPS boundaries and hence classifying protocols
or data models along FCAPS boundaries is IMHO a pointless exercise.

My reading of the document is that it takes the following viewpoint
(perhaps it even makes sense to include a figure? Of course, this
makes some asymmetry stand out):

      +--------- O&M -------+
      |                     |
     OAM                   Mgmt
     - Operations          - Fault
     - Administration      - Configuration
     - Maintenance         - Accounting
     - (Provisioning)      - Performance
                           - Security
     - horizontal          - vertical

The text stating that "Provisioning" is outside the scope of the
document but then a definition is provided is kind of interesting.
Perhaps the idea was to say that "Provisioning" is outside the scope
of OAM?  That would IMHO make more sense (and I would not mind to have
OAMP defined as OAM plus Provisioning).

While I find the document in general useful, especially section 3, I
suggest to merge the content of section 4 into the beginning of 3. It
is kind of odd to read the rationale for the recommended acronyms
before seeing the acronyms being recommended.

Personally, I am not too happy with the choice of the O&M acronym
because it is very easy to confuse with OAM - the difference really
does not stand out.

One alternative approach would be to look at these terms more like
this (establishing nice symmetry)

      +-------- Mgmt -------+
      |                     |
     OAM                   FCAPS
     - Operations          - Fault
     - Administration      - Configuration
     - Maintenance         - Accounting
     - (Provisioning)      - Performance
                           - Security
     - horizontal          - vertical

but this view might make some people feel uncomfortable (although I
admit that I like it because it is simple and clear).

Another approach would be using OAM+Mgmt instead of O&M (just to
reduce the risk of confusion because OAM and O&M look so similar), but
of course, this carries the asymmetry forward:

      +------ OAM+Mgmt -----+
      |                     |
     OAM                   Mgmt
     - Operations          - Fault
     - Administration      - Configuration
     - Maintenance         - Accounting
     - (Provisioning)      - Performance
                           - Security
     - horizontal          - vertical

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>