Subject: [mpls-tp] OAM ambiguity in ID draft-vigoureux-mpls-tp-oam-requirements-00

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 11 Aug 2008 15:49:03 +0200

Hi all, 

         To minimize the confusion around the term OAM and waiting for
the Loa's clarification ID may I suggest to add, to the ID in subject, a
section similar to Section 4 of draft-gray-mpls-tp-nm-req-00.txt? 

The purpose of that section is to define the scope of the meaning of the
term OAM used in the rest of the ID.

For sake of simplicity I'll quote, with small modification, it here.

        The purpose of the Operation and Maintenance (OAM) functionality

        is to maintain the integrity of the network and to ensure that 

        the transport service is compliant with the committed Service 

        Level Agreement (SLA).  

        This ID specifies the requirements for the OAM functionality
that 

        are deployed in the transport plane to maintain the integrity of

        the client signal between ingress and egress ports of the MPLS-

        TP network. These OAM functionalities are sometimes called 

        "Horizontal OAM". 

        There are OAM functionalities that are deployed in the 

        management plane to support maintaining the overall network 

        integrity and achieving the SLA. These OAM functionalities are 

        sometimes called "Vertical OAM" or OAM&P (Operation, 

        Administration, Maintenance, & Provisioning), in the sense that 

        they involves higher level systems, such as element management 

        systems (EMS), network management systems (NMS), and/or service 

        management systems (SMS) and are addressed by
draft-gray-mpls-tp-nm-req-00.txt. 

        Examples of vertical OAM functions include hardware
provisioning, software configuration, alarm 

        notification/retrieval, performance monitoring (PM) data 

        collection & reporting.  

BR

Diego

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Loa Andersson <[email-masked]>
Date: Mon, 11 Aug 2008 15:56:51 +0200

Diego,

Diego Caviglia wrote:
> the Loa's clarification ID

I'm working on it, and will "steal most of section 4 from the gray
ID; with proper
acknowledgmets of course

  may I suggest to add, to the ID in subject, a
>         The purpose of the Operation and Maintenance (OAM) functionality

the only issue I have here is that mostly the A stands for Adminstration
when it is combined with Maintenance; and it stands for "and" in
combination with Management.

/Loa
> ------------------------------------------------------------------------
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 11 Aug 2008 16:04:49 +0200

Hi Loa,
       the point was that the mpls-tp-oam-requirements focuses only on a subset of what has been defined, in other ID such as the Eric one but also in the GAL ID, OAM that could lead, IMHO, to confusion.

Having a short sentence illustrating what kind of OAM functions are illustrated in the ID could help the reader.

My two cents.

BR

Diego

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]]
> Sent: lunedì 11 agosto 2008 15.57
> To: Diego Caviglia
> Cc: [email-masked]
> Subject: Re: [mpls-tp] OAM ambiguity in ID draft-vigoureux-mpls-tp-oam-
> requirements-00
> 
> Diego,
> 
> 
> 
> Diego Caviglia wrote:
> > Hi all,
> >

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 11 Aug 2008 16:23:17 +0200

Diego,

mpls-tp-oam-requirements is quite explicit on the fact that the OAM
it talks about is for data plane. Yet I have no specific issue with
adding e.g. "This ID specifies the requirements for the OAM 
functionality that are deployed in the transport plane".

I think that, as you rightfully say, and to avoid confusion, we should
wait for Loa's ID and refer to it.

Are you suggesting that the GAL covers both vertical and horizontal OAM?

regards,

-m

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 11 Aug 2008 16:31:20 +0200

Hi Martin,
          Thanks for the quick replay.  I think that this matter is quite complex and a reader could be confused quite easily, let's wait Loa work on that and then reference it could be the right way to proceeded.

W.r.t to the GAL ID I think that is written in the ID that cover both Horizontal and Vertical OAM.

>From the GAL ID
"   Note that, in this document, MPLS-TP OAM (functions, packets) should 
   be understood in the broad sense, that is, as a set of mechanisms 
   including Automatic Protection Switching (APS), Signalling Control 
   Channel (SCC) and Management Control Channel (MCC)."

So my understanding is that GAL cover both the so called vertical and horizontal OAM, draft-vigoureux-mpls-tp-oam-requirements-00 covers, as requisites, the horizontal while draft-gray-mpls-tp-nm-req-00.txt covers the vertical.

BR

Diego

> From: Martin Vigoureux [mailto:[email-masked]]
> Sent: lunedì 11 agosto 2008 16.23
> To: Diego Caviglia
> Cc: Loa Andersson; [email-masked]
> >        the point was that the mpls-tp-oam-requirements focuses only on a
> subset of what has been defined, in other ID such as the Eric one but also
> in the GAL ID, OAM that could lead, IMHO, to confusion.
> >
> > Having a short sentence illustrating what kind of OAM functions are
> illustrated in the ID could help the reader.
> >
> > My two cents.
> >
> > BR
> >
> > Diego
> >

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 11 Aug 2008 16:38:39 +0200

Diego

>           Thanks for the quick replay.  I think that this matter is quite complex and a reader could be confused quite easily, let's wait Loa work on that and then reference it could be the right w…
I think also

>    Channel (SCC) and Management Control Channel (MCC)."
ok I see what you mean

regards,

-m

---

From: <[email-masked]>
Date: Mon, 11 Aug 2008 16:19:12 +0100

Diego is quite right in what he says.  One of the characteristics of the co-cs network mode is that we are forced design/operate a 'network system' of at least 2 DP networks working in concert, ie there is the traffic (DP) network and there is the CP/MP (DP) network...and the latter often uses a cl-ps mode networking technology, usually IP-based.  There is no choice with the co-cs mode, the physics of labelling and resource allocation (which are coupled actions) forces this behaviour.  And it has some very useful consequences, eg:
-	the CP/MP protocols are logically (at least) OOB wrt to the traffic DP....good for security
-	one can't break the single source rules of a connection....good for things like client SLAs and simplifying network resource accounting
-	there are no QoS classes.....good for the same reasons as above

The cl-ps mode is not like this all...traffic, CP and MP protocols all use the same DP network.

The co-ps mode *should* follow the same rules as the co-cs mode....but this is not forced.  This is because when we carve up a time resource with irregular time slices then resource allocation and label allocation are independent actions.  This provides increased flexibility....but this increased flexibility comes with the price of easily created complexity.

BTW - The traffic DP OAM requirements for the 3 network modes are not the same.  I can provide several examples to show why this has to be.  However, the only additional point I'd like to make here is a plea for simplicity of the traffic DP defect detection/handling OAM...it should be kept to the absolute minimal as it has to be super-reliable and have a low cost to collect/process.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: 11 August 2008 15:39
> To: Diego Caviglia
> Cc: [email-masked]
> Subject: Re: [mpls-tp] OAM ambiguityin ID 
> draft-vigoureux-mpls-tp-oam-requirements-00
> 
> Diego
> 
> Diego Caviglia a écrit :
> > Hi Martin,
> >           Thanks for the quick replay.  I think that this 
> matter is quite complex and a reader could be confused quite 
> easily, let's wait Loa work on that and then reference it 
> could be the right way to proceeded.
> I think also
> 
> > 
> > So my understanding is that GAL cover both the so called 
> vertical and horizontal OAM, 
> draft-vigoureux-mpls-tp-oam-requirements-00 covers, as 
> requisites, the horizontal while 
> draft-gray-mpls-tp-nm-req-00.txt covers the vertical.
> > 
> > BR
> > 
> > Diego
> regards,
> 
> -m
> > 
> > 
> > 
> >> Subject: Re: [mpls-tp] OAM ambiguity in ID 
> >> draft-vigoureux-mpls-tp-oam- requirements-00
> >>
> >> Diego,
> >>
> >> I think that, as you rightfully say, and to avoid confusion, we 
> >> should wait for Loa's ID and refer to it.
> >>
> >>>        the point was that the mpls-tp-oam-requirements 
> focuses only 
> >>> on a
> >> subset of what has been defined, in other ID such as the 
> Eric one but 
> >> also in the GAL ID, OAM that could lead, IMHO, to confusion.
> >>>> Subject: Re: [mpls-tp] OAM ambiguity in ID 
> >>>> draft-vigoureux-mpls-tp-oam- requirements-00
> >>>>
> >>>> Diego,
> >>>>
> >>>>
> >>>>
> >>>> Diego Caviglia wrote:
> >>>>> Hi all,
> >>>>>
> >>>>>          To minimize the confusion around the term OAM 
> and waiting 
> >>>>> for the Loa's clarification ID
> >>>> ID; with proper acknowledgmets of course
> >>>>
> >>>>> The purpose of that section is to define the scope of 
> the meaning 
> >>>>> of
> >> the
> >>>>>         is to maintain the integrity of the network and 
> to ensure 
> >>>>> that
> >>>>>
> >>>>>         This ID specifies the requirements for the OAM 
> >>>>> functionality that
> >>>>>
> >>>>>         are deployed in the transport plane to maintain the 
> >>>>> integrity
> >> of
> >>>>>
> >>>>>         the client signal between ingress and egress 
> ports of the
> >> MPLS-
> >>>>>         integrity and achieving the SLA. These OAM 
> functionalities 
> >>>>> are
> >>>>>
> >>>>>         Administration, Maintenance, & Provisioning), 
> in the sense
> >> that
> ------------------------------------------------------------------
> >>>>> ----
> >> --

---

From: hejia <[email-masked]>
Date: Tue, 12 Aug 2008 11:27:56 +0800

Agree. It is better to clarify these OAM terms and make them consistent. 
Can't wait to taste "Loa's soup" :-)

B.R.
Jia

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Loa Andersson
> Sent: Monday, August 11, 2008 9:57 PM
> To: Diego Caviglia
> Cc: [email-masked]
> Subject: Re: [mpls-tp] OAM ambiguity in
> IDdraft-vigoureux-mpls-tp-oam-requirements-00
> 
> Diego,
> 
> 
> 
> Diego Caviglia wrote:
> > Hi all,
> >

---

From: hejia <[email-masked]>
Date: Tue, 12 Aug 2008 12:59:21 +0800

Hi Diego
     I'm still confused about the vertical and horizontal OAM concept. To
make it simple, can we say MCC and SCC belong to vertical OAM, which is
covered in draft-gray-mpls-tp-nm-req-00.txt, while CC/AIS/DM/LM etc. belong
to horizontal OAM, which is covered in
draft-vigoureux-mpls-tp-oam-requirements-00 ?
What about APS? 
   Could you help to make this clear? Thanks a lot.

B.R.
Jia

> Of Diego Caviglia
> Sent: Monday, August 11, 2008 10:31 PM
> To: Martin Vigoureux
> Cc: [email-masked]
>           Thanks for the quick replay.  I think that this matter is quite
> complex and a reader could be confused quite easily, let's wait Loa work
on
> that and then reference it could be the right way to proceeded.
> 
> W.r.t to the GAL ID I think that is written in the ID that cover both
Horizontal
> and Vertical OAM.
> So my understanding is that GAL cover both the so called vertical and
horizontal
> OAM, draft-vigoureux-mpls-tp-oam-requirements-00 covers, as requisites,
the
> horizontal while draft-gray-mpls-tp-nm-req-00.txt covers the vertical.
> 
> BR
> 
> Diego
> 
> 
> 
draft-vigoureux-mpls-tp-oam-
integrity

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 12 Aug 2008 11:34:53 +0200

Hi Jia,
       My understanding of that definition is that horizontal OAM is used e.g. for triggering recovery, etc etc, that is for all the OAM (whatever it means) operations related to an LSP.  

For that purpose the GAL label is one defined in Section 5.1.2 of the GAL ID and is used coupled with the LSP Label.

Vertical OAM is more related to the management/control plane activity that is SCC and MCC and is to be used without a LSP label before the GAL.  That is explained in section 5.1.1 of the GAL ID.

That is my understanding.

BR

Diego

> From: hejia [mailto:[email-masked]]
> Sent: martedì 12 agosto 2008 6.59
> To: Diego Caviglia
> Cc: [email-masked]; 'Martin Vigoureux'
> Subject: RE: [mpls-tp] OAM ambiguity inIDdraft-vigoureux-mpls-tp-oam-
> requirements-00
> 
> Hi Diego
> > > >        the point was that the mpls-tp-oam-requirements focuses only
> on
> a
> > > >>> The purpose of that section is to define the scope of the meaning
> of
> > > the
> functionality

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 12 Aug 2008 11:50:25 +0200

Diego,

I think a misunderstanding has slipped-in:
The sections 5.1.1 and 5.1.2 of GAL ID do not correspond
to the support for respectively horizontal OAM and vertical OAM.
These describe the GAL use when doing OAM on respectively
- MPLS Sections
- MPLS LSPs
which both are Maintenance Entities.
The ID currently does not say/restrict the type of OAM packet
that can be found after the GAL.

regards,

-m

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 12 Aug 2008 13:42:07 +0200

Hi Martin,
          Now I'm a little bit confused, leave the horizontal and vertical stuff apart for a while.

The ID states that it encompasses OAM in the following sense.

Now w.r.t. the LSP OAM that is clearly in section 5.2.1 but in order to use the GAL for MCC and SCC IMHO it should be without the LSP label, MCC and SCC are not related to an LSP, then I've understood that the Section version of the GAL can be used for that.

Thanks in advance for your clarification.

BR

Diego

> Sent: martedì 12 agosto 2008 11.50
> To: Diego Caviglia
> Cc: hejia; [email-masked]
> Subject: Re: [mpls-tp] OAM ambiguity inIDdraft-vigoureux-mpls-tp-oam-
> requirements-00
> 
> Diego,
> 
> >        My understanding of that definition is that horizontal OAM is
> used e.g. for triggering recovery, etc etc, that is for all the OAM
> (whatever it means) operations related to an LSP.
> >
> > For that purpose the GAL label is one defined in Section 5.1.2 of the
> GAL ID and is used coupled with the LSP Label.
> >
> > Vertical OAM is more related to the management/control plane activity
> that is SCC and MCC and is to be used without a LSP label before the GAL.
> That is explained in section 5.1.1 of the GAL ID.
> >

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 12 Aug 2008 14:14:43 +0200

Hi Diego,

> Now w.r.t. the LSP OAM that is clearly in section 5.2.1 but in order to use the GAL for MCC and SCC IMHO it should be without the LSP label, MCC and SCC are not related to an LSP, then I've underst…
"can" is the right word ;-)
but as currently written the draft does not say:
MCC and SCC only on MPLS Sections and the rest on MPLS LSPs.
(One could want to do CC & CV on an MPLS Section and conversely
send MCC packets between two LSRs connected by an LSP).
In other words as currently written the draft does not split OAM 
functions (in the very large sense) between Sections and LSPs.

The two sections describe how the GAL is used for the respective
Monitoring Entities, it does not say which OAM function one
should/should not run on these MEs.

hope it clarifies

-m

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 12 Aug 2008 14:35:32 +0200

Hi Martin,
          Thank now is clear.

That pose to me a new question how can I send a management message using an LSP if the management is needed to create that LSP?

And more generally is correct to bound management messages to an LSP?  If I have access to my management network from node A (is gateway) and the LSP I want to create goes from D to F how can I reach node D (B, C, D and F have not OOB access to the management network)?

A----B----C----D----F

I apologies if I'm only generation confusion and that kind of stuff is clear to everyone.

BR

Diego

> Sent: martedì 12 agosto 2008 14.15
> To: Diego Caviglia
> > Now w.r.t. the LSP OAM that is clearly in section 5.2.1 but in order to
> use the GAL for MCC and SCC IMHO it should be without the LSP label, MCC
> and SCC are not related to an LSP, then I've understood that the Section
> version of the GAL can be used for that.
> >>>>      I'm still confused about the vertical and horizontal OAM
> concept.
> >> To
> >>>>>> subset of what has been defined, in other ID such as the Eric one
> but
> >>>> also
> >>>>>>>>>          To minimize the confusion around the term OAM and
> waiting
> >>>> for
> >>>>>>>>>         is to maintain the integrity of the network and to
> ensure
> >>>> that
> >>>>>>>>>         the client signal between ingress and egress ports of
> the
> >>>>>> MPLS-
> >>>>>>>>>         Administration, Maintenance, & Provisioning), in the
> sense
> >>>>>> that
> >>>>> --------------------------------------------------------------------
> --
> >>>>>> --

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 12 Aug 2008 15:07:25 +0200

Diego,

why focus on MCC over an LSP?

-m

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 12 Aug 2008 09:45:13 -0400

Hi Diego,

As Martin said, the draft permits in-band MCC and SCC but does not mandate
it. So in your example if B, C and D have no OOB access to Control and
Management, then probably a static LSP could be configured (via local craft
terminal) between A and D with MCC, SCC channels.

I personally think it is better to have OOB MCC and SCC, since it will
better decouple the data, control and management planes. But in some cases
you may have no choice.

Regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Diego Caviglia
Sent: August-12-08 8:36 AM
To: Martin Vigoureux
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM ambiguity
inIDdraft-vigoureux-mpls-tp-oam-requirements-00

Hi Martin,
          Thank now is clear.

That pose to me a new question how can I send a management message using an
LSP if the management is needed to create that LSP?

And more generally is correct to bound management messages to an LSP?  If I
have access to my management network from node A (is gateway) and the LSP I
want to create goes from D to F how can I reach node D (B, C, D and F have
not OOB access to the management network)?

A----B----C----D----F

I apologies if I'm only generation confusion and that kind of stuff is clear
to everyone.

BR

Diego

---

From: hejia <[email-masked]>
Date: Wed, 13 Aug 2008 20:03:50 +0800

Hi Diego
   To my understanding, MCC works inside a maintenance entity between 2
MEPs, say two ends of a LSP. In your example, if the LSP is created from D
to F, MCC can be provided between D and F. How D and F get access to the
management network is probably implementation-specific but not related to
MCC between D and F.
    Well, that's my understanding.  ;-)

Best Regards,
Jia

> From: Diego Caviglia [mailto:[email-masked]]
> Sent: Tuesday, August 12, 2008 8:36 PM
> To: Martin Vigoureux
> Subject: RE: [mpls-tp] OAM
> ambiguityinIDdraft-vigoureux-mpls-tp-oam-requirements-00
> 
> Hi Martin,
>           Thank now is clear.
> 
not
> OOB access to the management network)?
> 
> A----B----C----D----F
> 
> > >>>> make it simple, can we say MCC and SCC belong to vertical OAM,
which
> > is
> > >>>> covered in draft-gray-mpls-tp-nm-req-00.txt, while CC/AIS/DM/LM
etc.
> > >>>> belong
> > >>>>> From: [email-masked] [mailto:[email-masked]]
On
> > >>>> Behalf
> > >>>>>           Thanks for the quick replay.  I think that this matter
is
> > >>>> quite
> > >>>>> complex and a reader could be confused quite easily, let's wait
Loa
> > >> work
> > >>>>>> From: Martin Vigoureux
[mailto:[email-masked]]
> > >>>>>> Subject: Re: [mpls-tp] OAM ambiguity in ID
draft-vigoureux-mpls-tp-
> > >>>> oam-
> > >>>>>> Are you suggesting that the GAL covers both vertical and
horizontal
> > >>>> OAM?
> > >>>>>>>>>         systems (EMS), network management systems (NMS),
and/or
> > >>>>>> service

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 14 Aug 2008 15:30:19 +0200

Hi Diego,

You wrote:

> That pose to me a new question how can I send a management message
> using an LSP if the management is needed to create that LSP?
> 
> And more generally is correct to bound management messages to an LSP?
> If I have access to my management network from node A (is gateway)
> and the LSP I want to create goes from D to F how can I reach node D
> (B, C, D and F have not OOB access to the management network)?
> 
> A----B----C----D----F
> 

There has to be MCC/SCC on each section A-B, B-C, C-D, D-F, this
allows to manage nodes B, C, D and F via the gateway at A.
It is not necessary to have MCC/SCC per LSP in this topology.

BTW this is similar to the DCC in the MS layer of SDH where
VC-n do not have DCC.

Ciao, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 18 Aug 2008 08:19:13 +0200

Hi Diego,

I am trying to get into the long discussion.

I think OAM (in the transport layer) stands for Operation,
Administration and Maintenance, and the scope of OAM is this document.

I do not understand why we should refer to the management plane or to
the "Vertical OAM" or OAM&P in this document and personally I would
prefer to see another terminology referring to the vertical one in order
to avoid confusion.

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Diego Caviglia
Sent: Monday, August 11, 2008 16:49
To: [email-masked]
Subject: [mpls-tp] OAM ambiguity in
IDdraft-vigoureux-mpls-tp-oam-requirements-00

Hi all, 

        Level Agreement (SLA).  

        "Horizontal OAM". 

        collection & reporting.  

BR

Diego

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 18 Aug 2008 08:19:24 +0200

I propose to differentiate between the both.
OAM is used both in the IETF MPLS/PW/L2VPN and the ITU-T as for the transport layer.
We need to think about a new terminology to the vertical one. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Diego Caviglia
Sent: Monday, August 11, 2008 17:05
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM ambiguity inID draft-vigoureux-mpls-tp-oam-requirements-00

Hi Loa,

My two cents.

BR

Diego

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 18 Aug 2008 08:19:22 +0200

Hi,
Please see inline.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Diego Caviglia
Sent: Tuesday, August 12, 2008 12:35
To: hejia
Cc: [email-masked]
Subject: Re: [mpls-tp] OAMambiguity inIDdraft-vigoureux-mpls-tp-oam-requirements-00

Hi Jia,
       My understanding of that definition is that horizontal OAM is used e.g. for triggering recovery, etc etc, that is for all the OAM (whatever it means) operations related to an LSP.  
<NS> LSP or Tandem Connection (segment) LSP

Vertical OAM is more related to the management/control plane activity that is SCC and MCC and is to be used without a LSP label before the GAL.  
That is explained in section 5.1.1 of the GAL ID.

BR

Diego

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 18 Aug 2008 07:42:38 -0500

Nurit,
 
    My mother and both of her younger brothers each decided to name
their
oldest daughters "Kathy" - in one form or another.  It was an accident,
as my
mother's oldest daughter was actually her 5th child, one of my uncles
first
daugther was his 3rd child and the other's was his first child and they
were 
all born really close to the same time.
 
    Interestingly enough, NOBODY suggested that any of them should find
a
new name for their daughter.

--
Eric Gray
Principal Engineer
Ericsson 

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
	Sent: Monday, August 18, 2008 2:19 AM
	To: Diego Caviglia; [email-masked]
	Subject: Re: [mpls-tp] OAM ambiguity
inIDdraft-vigoureux-mpls-tp-oam-requirements-00

	Hi Diego,

	I do not understand why we should refer to the management plane
or to the "Vertical OAM" or OAM&P in this document and personally I
would prefer to see another terminology referring to the vertical one in
order to avoid confusion.

	Best regards,

	Nurit

On Behalf Of ext Diego Caviglia

	Hi all, 

	         To minimize the confusion around the term OAM and
waiting for the Loa's clarification ID may I suggest to add, to the ID
in subject, a section similar to Section 4 of
draft-gray-mpls-tp-nm-req-00.txt? 

	The purpose of that section is to define the scope of the
meaning of the term OAM used in the rest of the ID.

	For sake of simplicity I'll quote, with small modification, it
here.

	        The purpose of the Operation and Maintenance (OAM)
functionality 

ensure that 

	        the transport service is compliant with the committed
Service 

	        Level Agreement (SLA).  

integrity of 

the MPLS-

	        TP network. These OAM functionalities are sometimes
called 

	        "Horizontal OAM". 

	        management plane to support maintaining the overall
network 

functionalities are 

sense that 

	        they involves higher level systems, such as element
management 

	        systems (EMS), network management systems (NMS), and/or
service 

	        collection & reporting.  

	BR

	Diego

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Mon, 18 Aug 2008 07:47:54 -0500

The term OAM has been used in the management plane (vertical) for many years, even in the titles of many Telecom specifications.

Regards,
Kam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Diego Caviglia
Sent: Monday, August 11, 2008 17:05
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM ambiguity inID draft-vigoureux-mpls-tp-oam-requirements-00

Hi Loa,

My two cents.

BR

Diego

---

From: Lucy Yong <[email-masked]>
Date: Mon, 18 Aug 2008 17:28:59 -0500

Some OAM functions reside on the data plane and some are outside of data
plane. The requirements in this document seems only scoped for OAM functions
residing on the data plane, isn't it? If yes, clarifying the scope of the
document should be good enough, is that right?
Lucy

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Lam, Hing-Kam (Kam)
> Sent: Monday, August 18, 2008 7:48 AM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Diego Caviglia; Loa
Andersson
> Cc: [email-masked]
> Subject: Re: [mpls-tp] OAM ambiguityinIDdraft-vigoureux-mpls-tp-oam-
> requirements-00
> 
> The term OAM has been used in the management plane (vertical) for many
years,
> even in the titles of many Telecom specifications.
> 
> Regards,
> Kam
> 
Of
> Sprecher, Nurit (NSN - IL/Hod HaSharon)
> OAM is used both in the IETF MPLS/PW/L2VPN and the ITU-T as for the
transport
> layer.
Of
> ext Diego Caviglia
subset of
> what has been defined, in other ID such as the Eric one but also in the
GAL ID,
> OAM that could lead, IMHO, to confusion.
> 
illustrated in
> the ID could help the reader.
> 
> My two cents.
> 
> BR
> 
> Diego
> 
functionality
service

---

From: "Lam, Hing-Kam \(Kam\)" <[email-masked]>
Date: Mon, 18 Aug 2008 22:17:11 -0500

Exactly!
In fact, in the NM draft <draft-gray-mpls-tp-nm-req-01_d1.doc> there is already text in section 4, which clarifies the scope of OAM in the management plane context and explains the relationship between the transport plane OAM & management plane OAM. 

In Diego's 8/11 email, he suggested similar text be added to <draft-vigoureux-mpls-tp-oam-requirements>. This suggestion is very appropriate. 

Once Loa's clarification I-D is available, we could then update both the OAM and NM drafts to pointing to the Loa's draft.

To my opinion, we have enough discussion on topic.

Regards,
Kam 

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]] 
Sent: Monday, August 18, 2008 6:29 PM
To: Lam, Hing-Kam (Kam); 'Sprecher, Nurit (NSN - IL/Hod HaSharon)'; 'ext Diego Caviglia'; 'Loa Andersson'
Cc: [email-masked]
Subject: RE: [mpls-tp] OAMambiguityinIDdraft-vigoureux-mpls-tp-oam-requirements-00

Of
Andersson
years,
Of
transport
Of
subset of
GAL ID,
illustrated in
functionality
service

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 19 Aug 2008 12:13:10 +0200

Hello Lucy,

You wrote:

> Some OAM functions reside on the data plane and some are outside
 > of data plane.

[hvh] do you mean the processing of the OAM information sent in
the dataplane can be performed in the dataplane or CP or MP?

> The requirements in this document seems only scoped for OAM functions
> residing on the data plane, isn't it? 

[hvh] No, this draft describes how the OAM information is
transported in the dataplane i.e the mechanisms to do that.
So it describes the OAM overhead added to the normal traffic.
The OAM overhead contains information for fault handling,
performance monitoring, management, signalling, experimental,
vendor specific, etc.

> If yes, clarifying the scope of the document should be good enough,
 > is that right?

[hvh] We already agreed to do that.

Regards, Huub.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 19 Aug 2008 12:38:02 +0200

Amazing and exciting story. 

From: ext Eric Gray [mailto:[email-masked]] 
Sent: Monday, August 18, 2008 15:43
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); Diego Caviglia;
[email-masked]
Subject: RE: [mpls-tp] OAM ambiguity
inIDdraft-vigoureux-mpls-tp-oam-requirements-00

Nurit,

--
Eric Gray
Principal Engineer
Ericsson 

	Hi Diego,

	Best regards,

	Nurit

	Hi all, 

	        Level Agreement (SLA).  

	        "Horizontal OAM". 

	        collection & reporting.  

	BR

	Diego

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 19 Aug 2008 09:08:19 -0500

Nurit,
 
    And apt, too.  Your suggestion that we should find another name for
"vertical OAM" is directly analogous to this "amazing and exciting
story".
 
    As Kam pointed out, OAM (or O&M) - in one form or another - is a 
term that has been used for device management for a fairly long time.
Referring to device management (or the management plane) is what we
have done to reduce the confusion of OAM (or some variation of this 3
letter acronym) in the data plane (horizontal OAM) with OAM in the
management plane.
 
    Introducing yet another term for device management will not reduce 
confusion.

--
Eric Gray
Principal Engineer
Ericsson 

	From: Sprecher, Nurit (NSN - IL/Hod HaSharon)
[mailto:[email-masked]] 
	Sent: Tuesday, August 19, 2008 6:38 AM
	To: Eric Gray; Diego Caviglia; [email-masked]
	Subject: RE: [mpls-tp] OAM ambiguity
inIDdraft-vigoureux-mpls-tp-oam-requirements-00
	Importance: High

	

	Nurit,

	    My mother and both of her younger brothers each decided to
name their

	oldest daughters "Kathy" - in one form or another.  It was an
accident, as my

	mother's oldest daughter was actually her 5th child, one of my
uncles first

	daugther was his 3rd child and the other's was his first child
and they were 

	    Interestingly enough, NOBODY suggested that any of them
should find a

	--
	Eric Gray
	Principal Engineer
	Ericsson 

[mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN -
IL/Hod HaSharon)

		Hi Diego,

		I think OAM (in the transport layer) stands for
Operation, Administration and Maintenance, and the scope of OAM is this
document.

		I do not understand why we should refer to the
management plane or to the "Vertical OAM" or OAM&P in this document and
personally I would prefer to see another terminology referring to the
vertical one in order to avoid confusion.

		Best regards,

		Nurit

[mailto:[email-masked]] On Behalf Of ext Diego Caviglia

		Hi all, 

		         To minimize the confusion around the term OAM
and waiting for the Loa's clarification ID may I suggest to add, to the
ID in subject, a section similar to Section 4 of
draft-gray-mpls-tp-nm-req-00.txt? 

		The purpose of that section is to define the scope of
the meaning of the term OAM used in the rest of the ID.

		For sake of simplicity I'll quote, with small
modification, it here.

		        The purpose of the Operation and Maintenance
(OAM) functionality 

to ensure that 

		        the transport service is compliant with the
committed Service 

		        Level Agreement (SLA).  

		        are deployed in the transport plane to maintain
the integrity of 

ports of the MPLS-

		        TP network. These OAM functionalities are
sometimes called 

		        "Horizontal OAM". 

		        There are OAM functionalities that are deployed
in the 

		        management plane to support maintaining the
overall network 

		        sometimes called "Vertical OAM" or OAM&P
(Operation, 

		        Administration, Maintenance, & Provisioning), in
the sense that 

		        they involves higher level systems, such as
element management 

and/or service 

		        Examples of vertical OAM functions include
hardware provisioning, software configuration, alarm 

		        notification/retrieval, performance monitoring
(PM) data 

		        collection & reporting.  

		BR

		Diego

---

From: Lucy Yong <[email-masked]>
Date: Tue, 19 Aug 2008 09:41:55 -0500

Hi Huub,

See below.

Of
> Huub van Helvoort
> Sent: Tuesday, August 19, 2008 5:13 AM
> Cc: [email-masked]
> Subject: Re: [mpls-tp] OAMambiguityinIDdraft-vigoureux-mpls-tp-oam-
> requirements-00
> 
> Hello Lucy,
> 
> You wrote:
> 
[Lucy:] OAM functions residing on the data plane are the OAM autonomous
functions built on the data plane, which could include some OAM information
sent in the data plane. OAM functions residing on the CP or MP are the
(autonomous) functions built on the CP or MP, which could also include some
OAM information sent through the data plane.
> performance monitoring, management, signalling, experimental,
[Lucy:] In packet transport, OAM information is carried by individual OAM
packets. I would not call it "OAM overhead" because we do not need to add
OAM information to every transported packet. OAM packets should be sent
regardless whether there is traffic packet sent or not. Traffic packets are
only transported when the sender sent it. This is difference from TDM
transport. 

Regards, Lucy
Behalf
Behalf
Behalf
management

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 19 Aug 2008 17:11:19 +0200

Hi,

Well I do not agree with you, but I will not argue about the message of
the story... otherwise you will have to write a book of stories......

I think (1) that we are concentrating on names/solutions instead of on
the requirements and the functional architecture, and (2) we have a
great opportunity to correct this confusion.

In addition, the fact that for the vertical OAM we have a few
terminologies (OAM, O&M, OAM&P) is already a problem....and we need to
resolve it and have one terminology only (which IMO do not have to be
OAM).

The fact is that your document is titled with NM (and not on OAM, etc).
I propose you concentrate on the requirements and the framework....and
afterwards we'll concentrate on the solutions...

Best regards,

Nurit

Sent: Tuesday, August 19, 2008 17:08

Nurit,

management plane.

confusion.

--
Eric Gray
Principal Engineer
Ericsson 

	

	Nurit,

	
	--
	Eric Gray
	Principal Engineer
	Ericsson 

		Hi Diego,

		Best regards,

		Nurit

		Hi all, 

		        Level Agreement (SLA).  

		        "Horizontal OAM". 

		        collection & reporting.  

		BR

		Diego

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 19 Aug 2008 17:20:26 +0200

Hello Lucy,

> OAM information sent through the data plane.

[hvh:-] this is the same explanation

> only transported when the sender sent it. This is difference from TDM

[hvh:-] I am very much aware of that, however the OAM packets
require transport bandwidth which reduces the traffic bandwidth,
so in that sense it is overhead.
It should be an objective to minimise the OAM overhead bandwidth.

Regards, Huub.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 19 Aug 2008 16:24:04 +0100

> It should be an objective to minimise the OAM overhead bandwidth.

Oh, but that is *easy*.

Ah, do you mean "minimise overhead bandwidth while retaining functionality"?

A

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 19 Aug 2008 17:43:42 +0200

Ni hao Adrian,

>> It should be an objective to minimise the OAM overhead bandwidth.

[hvh] yes indeed, but I wrote *minimise*, not *nullify*   ;-)

> Ah, do you mean "minimise overhead bandwidth while retaining 

[hvh] right, and this aplies especially to the pro-active OAM

Cheers, Huub.

---

From: Lucy Yong <[email-masked]>
Date: Tue, 19 Aug 2008 14:03:53 -0500

Yes, that requirement is clear to me.
Cheers,
Lucy

Of
> Huub van Helvoort
> Sent: Tuesday, August 19, 2008 10:44 AM
> Cc: [email-masked]