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

From: "t.petch" <[email-masked]>
Date: Tue, 1 Feb 2011 15:54:28 +0100

I assume that this is still

http://www.ietf.org/internet-drafts/draft-ietf-opsawg-mpls-tp-oam-def-07.txt

How long have we got?

Tom Petch

----- Original Message ----- 
From: "Scott O. Bradner" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 31, 2011 3:40 PM
Subject: [OPSAWG] WGLC on draft-ietf-opsawg-mpls-tp-oam-def

> 
> I should have done this right after the last IETF meeting
> but, in any case, this message starts a WGLC on 
> draft-ietf-opsawg-mpls-tp-oam-def - please let the
> list know if you think the ID is ready for publication
> as a BCP
> 
> thanks
> 
> Scott
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: [email-masked] (Scott O. Bradner)
Date: Tue, 1 Feb 2011 11:30:21 -0500 (EST)

> http://www.ietf.org/internet-drafts/draft-ietf-opsawg-mpls-tp-oam-def-07.txt

yup

> How long have we got?

sigh - should have said - two weeks (til feb 14)

Scott

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 2 Feb 2011 21:03:32 +1100

support

> list know if you think the ID is ready for publication

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Wed, 2 Feb 2011 21:03:54 +1100

BTW  - the support was with chair hat off.

	Chris

---
李柯睿
Check my PGP key here:

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 02 Feb 2011 11:32:22 +0100

I basically support this document.

Here are some review comments/questions

1. In section 1 I see:

        The examples below show a number of different ways that the OAM
        acronym has been expanded in previous documents.

    So are those "prvious" documents meant to be just IETF documents, or
    also non-IETF documents. And I guess we want to streamline our (IETF)
    use of these terms, but I bet we have very little (if any) influence on what
    other organisations do with this term. Would be good to be explicit on
    these aspects.

    Same for the recommendations. Are they specific for use in IETF documents,
    or are we suggesting it for wider applicability. Better to be specific I think.

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.
     And then there is FCAPS, where it could fall under the C.

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Feb 2011 13:16:56 +0100

>     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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "t.petch" <[email-masked]>
Date: Wed, 2 Feb 2011 12:41:20 +0100

We did get a liaison from the ITU-T on this I-D, file994.pdf, most of which
seems to have been rejected.  Is this correct?  I never saw any discussion of
the proposed changes on mpls-tp or OPSAWG lists, just the proposed
changes did not get incorporated.

And is this I-D being liaised to the ITU-T now, as part of the IETF-ITU-T JWT
or is it being treated as an IETF matter only?

Tom Petch

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 3 Feb 2011 16:29:50 -0500

Please see in-line... 

Snip...
>     other organisations do with this term. Would be good to 

"previous documents" is not very clear.  I could cut down the list to those only seen in IETF RFCs and say...

The examples below show a number of different ways that the OAM acronym has been expanded in IETF RFCs.

OAM = Operations, Administration, Maintenance
OAM = Operation, Administration, and Maintenance
OAM = Operations, Administration, and Maintenance
OAM = Operations, Administration, and Management
OAM = Operations and Management

There are more and there are variants that mess with commas, but I think 5 is probably enough to get the point across.

For completeness, however, another example of the "fourth letter" should be added..

OAM&P = Operation, Administration, Management and Provisioning

Obviously creating a standard abbreviation would be very helpful... 

>     or are we suggesting it for wider applicability. Better 

The recommendations are meant for IETF documents.  I was hoping the first sentence in the Introduction made the purpose of the clear.  However, if taking the word "main" out would make it clearer, I'm all for that...

Change "The main purpose of this document" to "The purpose of the this document is to provide a definition of the OAM acronym such that it is useful for the IETF".

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

I'll address this one in my response to Juergen's mail.

Regards,
-scott.

> draft-ietf-opsawg-mpls-tp-oam-def 
> > - please let the list know if you think the ID is ready for 
> > publication as a BCP
> >
> > thanks
> >
> > Scott

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 3 Feb 2011 17:02:38 -0500

Please see in-line...

Snip...
> 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.
> 
> 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
> 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).
> 

We simply did not want to cover examples of provisioning in this document.  I do like your suggestion to point out that "provisioning" is not usually covered by the OAM acronym, that is why there is an &P added sometimes.

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

We had the recommendations summarized in Section 4.  I'm ok with putting the recommendation at the top of section 3.

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

The O&M acronym seems to be the one that is most confused with OAM (when talking with non-management folks).  That is why I think it is important to show both OAM and O&M.  If you want to equate O&M with OAM+Mgmt, we could point that out in the document.

I'm also not sure about including the figure because lining up OAM and FCAPS in that way doesn't really show off that one is horizontal and one is vertical.

Something like a matrix might be better...

---------------------------------
O |     |     |     |     |     |
---------------------------------
A |     |     |     |     |     |
---------------------------------
M |     |     |     |     |     |
---------------------------------
     F     C     A     P     S

This would point out that there is not a one-to-one mapping of what we mean by OAM to FCAPS.  As said before, FCAPS is more vertically oriented dealing with NE to EMS communication while the term OAM is horizontally oriented dealing with NE to NE communication.  So a simple picture like this might be helpful...

         NMS          
        /    \
    (FCAPS)  (FCAPS)
      /         \ 
     EMS        EMS 
    /    \       \ 
(FCAPS) (FCAPS) (FCAPS)
 /         |          \
NE -(OAM)- NE -(OAM)- NE

Snip...

Regards,
-scott.

---

From: Scott Mansfield <[email-masked]>
Date: Thu, 3 Feb 2011 17:21:00 -0500

The liaison I saw -> https://datatracker.ietf.org/liaison/876/  does have two paragraphs discussing vertical and horizontal management in more detail.  This was discussed with the commenter's and it was decided not to include the added complexity.  All of the other comments were basically editorial and handled during editing.  I can't find liaison/file994.pdf, so I'm not sure what else is a concern.

I believe this is considered an IETF matter now since the document does not specifically relate to MPLS-TP any longer.

Regards,
-scott.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Wednesday, February 02, 2011 6:41 AM
> To: [email-masked]; [email-masked]
> We did get a liaison from the ITU-T on this I-D, file994.pdf, 
> most of which seems to have been rejected.  Is this correct?  
> I never saw any discussion of the proposed changes on mpls-tp 
> or OPSAWG lists, just the proposed changes did not get incorporated.
> 
> And is this I-D being liaised to the ITU-T now, as part of 
> the IETF-ITU-T JWT or is it being treated as an IETF matter only?
> 
> Tom Petch
> 
> 
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 04 Feb 2011 01:28:37 +0100

Scott and Bert,

there has been a lot of water under the bridges since we started ths.
the original long list of expansions of the OAM acronym came
from documents that were published a "xxx-mpls-tp-xxx", by people I
as a novice in the area thought were OAM-experts".

So we set out to have some common ground in the tp-project, but when
we looke around the situation was the same all over, so the draft
were generalized in steps.

My take is the draft now has the correct scope and also a correct
recommendation.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Scott Mansfield <[email-masked]>
Date: Fri, 4 Feb 2011 08:08:52 -0500

I am ok with leaving the list as is.  Small changes are better than big ones at this point.

Regards,
-scott. 

> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Thursday, February 03, 2011 7:29 PM
> To: Scott Mansfield
> Cc: Bert (IETF) Wijnen; Scott O. Bradner; [email-masked]
> from documents that were published a "xxx-mpls-tp-xxx", by 
> people I as a novice in the area thought were OAM-experts".
> 
> So we set out to have some common ground in the tp-project, 
> but when we looke around the situation was the same all over, 
> so the draft were generalized in steps.
> 
> My take is the draft now has the correct scope and also a 
> correct recommendation.
> 
> /Loa
> 
> 
> >>          The examples below show a number of different 
> ways that the 
> >> OAM
> >>      also non-IETF documents. And I guess we want to 
> streamline our 
> >> (IETF)
> > "previous documents" is not very clear.  I could cut down 
> the list to those only seen in IETF RFCs and say...
> >
> > The examples below show a number of different ways that the 
> OAM acronym has been expanded in IETF RFCs.
> >
> > OAM = Operations, Administration, Maintenance OAM = Operation, 
> > Administration, and Maintenance OAM = Operations, 
> Administration, and 
> > Maintenance OAM = Operations, Administration, and Management OAM = 
> > Operations and Management
> >
> > There are more and there are variants that mess with 
> commas, but I think 5 is probably enough to get the point across.
> >
> >>      Same for the recommendations. Are they specific for 
> use in IETF 
> >> documents,
> > The recommendations are meant for IETF documents.  I was 
> hoping the first sentence in the Introduction made the 
> purpose of the clear.  However, if taking the word "main" out 
> would make it clearer, I'm all for that...
> >
> > Change "The main purpose of this document" to "The purpose 
> of the this document is to provide a definition of the OAM 
> acronym such that it is useful for the IETF".
> >
> >
> >>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Feb 2011 16:19:06 +0100

> The O&M acronym seems to be the one that is most confused with OAM (when talking with non-management folks).  That is why I think it is important to show both OAM and O&M.  If you want to equate O&…

Now I am confused. Section 4 says:

   O&M - OAM and Management

So this is not my proposal, this is what the I-D says. My point is
that OAM and O&M are way to easy to confuse and misread and hence I
would prefer some other notation.

> This would point out that there is not a one-to-one mapping of what
> we mean by OAM to FCAPS.  As said before, FCAPS is more vertically
> oriented dealing with NE to EMS communication while the term OAM is
> horizontally oriented dealing with NE to NE communication.  So a
> simple picture like this might be helpful...
> 
>          NMS          
>         /    \
>     (FCAPS)  (FCAPS)
>       /         \ 
>      EMS        EMS 
>     /    \       \ 
> (FCAPS) (FCAPS) (FCAPS)
>  /         |          \
> NE -(OAM)- NE -(OAM)- NE

This is an interesting way of drawing this. I kind of like it.

/js

---

From: Scott Mansfield <[email-masked]>
Date: Fri, 11 Feb 2011 15:25:40 -0500

I understand your point.  OAM is easy to confuse with O&M.  However, I think it is important to highlight the differences because (in my experience anyway) where O&M is used it usually means all of management, and when the term OAM is used it sometime means all of management and sometimes means the horizontal management protocol(s) used between NE's.

I suggest keeping O&M as the suggested acronym for management because it usually means what we want it to mean.  If you would like to add extra text pointing out what O&M means, that might be useful to add.

Regards,
-scott. 

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Friday, February 11, 2011 10:19 AM
> To: Scott Mansfield
> Cc: Bert (IETF) Wijnen; [email-masked]
> > The O&M acronym seems to be the one that is most confused 
> with OAM (when talking with non-management folks).  That is 
> why I think it is important to show both OAM and O&M.  If you 
> want to equate O&M with OAM+Mgmt, we could point that out in 
> the document.
> 
> So this is not my proposal, this is what the I-D says. My 
> point is that OAM and O&M are way to easy to confuse and 
> misread and hence I would prefer some other notation.
> 
> > This would point out that there is not a one-to-one mapping 
> of what we 
> > mean by OAM to FCAPS.  As said before, FCAPS is more vertically

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Feb 2011 21:46:50 +0100

On Fri, Feb 11, 2011 at 03:25:40PM -0500, Scott Mansfield wrote:
 
> I understand your point.  OAM is easy to confuse with O&M.  However,
> I think it is important to highlight the differences because (in my
> experience anyway) where O&M is used it usually means all of
> management, and when the term OAM is used it sometime means all of
> management and sometimes means the horizontal management protocol(s)
> used between NE's.

This document is making a strong (BCP) recommendation what the IETF
should be using when referring to OAM + Management. I am taking the
position that OAM and O&M are too easy to confuse, they almost look
the same. I am not questioning the explanation "where O&M is used it
usually means all of management".

> I suggest keeping O&M as the suggested acronym for management
> because it usually means what we want it to mean.

So where is "usually"? I am concerned about the usage in the IETF and
I am concerned that OAM and O&M can be too easily confused.

> If you would like to add extra text pointing out what O&M means,
> that might be useful to add.

I think we are not discussing the meaning, we are discussing the
symbol to use to refer to the meaning.

/js