Subject: [Lime-oam-model] OAM Model analisys. First cut

From: Gregory Mirsky <[email-masked]>
Date: Wed, 4 Feb 2015 01:22:26 +0000

Dear All,
apologies for belated update. Attached please find first cut of the proposal for approach to OAM Model comparison and example of it being used.

Your questions, comments, suggestions always welcome and greatly appreciated.

                Regards,
                                Greg

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Feb 2015 02:03:28 +0000

Greg:
What conclusion do you make from this analysis? Do you want to make BDI and FDI being supported as common OAM function? Or do you want to make linktrace and loop back layer independent? Aren’t linktrace and loopback Ethernet specific functions?
I think the example you give in the table 1 gets complete alignment with the Table 4 in the section 5.2 of RFC7276.
That is to say Continuity Check, Connectivity Verification, Path Discovery, Performance measurement are common OAM functions for the all the OAM technologies.
Besides Common OAM functions, we also have fault domain, test point, addressing, technology type, sub technology type, specific layer. They are all common things
for all the OAM technologies.

Regards!
-Qin
发件人: Lime-oam-model [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年2月4日 9:22
收件人: [email-masked]
主题: [Lime-oam-model] OAM Model analisys. First cut

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 4 Feb 2015 19:54:44 +0000

Hi Qin,
I believe that LIME charter is not to develop new OAM tools but to work on OAM data model that is relevant to all or some OAM models. If some OAM models do not have some of functions we find in other models, then we can flag that and discuss but in other group. The table you find in my writing is only start of what OAM model analysis may look like. I’d like the team to review it and help with comments and suggestions to extend the table. Then we can come to informed decision on what is common among IETF OAM models and discuss how useful data model of that common set may be.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 6:03 PM
To: Gregory Mirsky; [email-masked]
Subject: RE: OAM Model analisys. First cut

Greg:

Regards!
-Qin
发件人: Lime-oam-model [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年2月4日 9:22
收件人: [email-masked]<mailto:[email-masked]>
主题: [Lime-oam-model] OAM Model analisys. First cut

Dear All,

                Regards,
                                Greg

---

From: Tom Taylor <[email-masked]>
Date: Wed, 04 Feb 2015 16:12:21 -0500

Thanks for your work, Greg. I'll get into this discussion later today 
(which amounts to tomorrow your time). I have some other work in hand at 
the moment.

Tom

On 04/02/2015 2:54 PM, Gregory Mirsky wrote:
> _______________________________________________
> Lime-oam-model mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime-oam-model
>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 5 Feb 2015 02:23:16 +0000

Hi Greg,

Thanks for detailed Analysis. I have few queries.
In Metrics Is Lock is covered under Defect Indication?
How's Test signal get covered?
Should we talk about Throughput or as it's application ignore for now.

Metric is covering "Source Information/MEP ID" and "MIP ID", but we should also extend to add other metrics related to Administrative Domain and MEP for completeness.
For Eg:- Administrative Domain, OAM Technology Layer Type, Level (implicit or NA), MEP addressing and ECMP (Flow Entropy or Customer traffic information).

We should also add metrics for Server Layer, Client Layer and also concept similar to Server MEP (Which is lower layer of OAM sending AIS/LCK to upper layer to suppress Alarms).
Also this concept is useful in OAM interworking between different technology also.

I believe providing information regarding server layer in data model will allow application using data model to efficiently go down one layer at a time and Isolate the Fault.

Thanks,
Deepak

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 3, 2015 5:22 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Lime-oam-model] OAM Model analisys. First cut

Dear All,

                Regards,
                                Greg

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Feb 2015 03:15:26 +0000

One thing I am surprising is there is no references have been provided for this analysis.
If we have all the referenced document put together, it will be easy to help us to find what
are common things in these various OAM technologies.
e.g., some references I can provide include:
a. IEEE 802.1Q
b. ITU-T Y.1731
c.  MPLS-TP OAM model in the section 4 of RFC6371
d. MEF-38 Service OAM Fault Management YANG Modules Technical Specification
e. MEF-39 Service OAM Performance Monitoring YANG Module Technical Specification

-Qin
发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2015年2月5日 3:55
收件人: Qin Wu; [email-masked]
主题: RE: OAM Model analisys. First cut

Hi Qin,

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, February 03, 2015 6:03 PM
To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>
Subject: RE: OAM Model analisys. First cut

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 5 Feb 2015 06:30:23 +0000

Hi Qin,
many thanks for your suggestion. I think that we should define the scope of our discussion. I believe that non-IETF technologies should be out of scope and only IETF ones analyzed. That is why I’ve included only IP, IP/MPLS, MPLS-TP and TRILL. If we to use the list of references, then we may be stepping into IEEE, ITU-T and MEF territory. Hope our WG chairs can clarify that.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 7:15 PM
To: Gregory Mirsky; [email-masked]
Subject: RE: OAM Model analisys. First cut

-Qin
发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2015年2月5日 3:55
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
主题: RE: OAM Model analisys. First cut

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Feb 2015 06:49:52 +0000

Here is my point.
Using any model from other SDOs as basis doesn’t mean we step into other SDO territory.
From Several reference document I listed, we can see what are LIME related work?
What commonality are they sharing?
e.g., IEEE 802.1Q based model is similar to Y.1731 based model
MEF 38 and MEF39 use 802.1Q based model, i.e., CFM model.
RFC6371 uses Y.1731 based model as basis.
We should not deny this fact, we should not neglect non-IETF work by worrying about stepping into other SDO territory.

Regards!
-Qin
发送时间: 2015年2月5日 14:30

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 5 Feb 2015 06:58:51 +0000

Hi Qin,
there’s no surprise that CFM and Y.1731 follow the same model. Nor that MEF documents you’ve referenced so close to Y.1731, since Carrier Ethernet is, in fact and for practical purposes, Y.1731. And for those who followed MPLS-TP JWT strong resemblance of Y.1731 is not surprise either.
What I think we’re trying to establish is whether there is enough commonality between IP/IP-based OAM models and CFM/Y.1731/MPLS-TP/TRILL OAM.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 10:50 PM
To: Gregory Mirsky; [email-masked]
Subject: RE: OAM Model analisys. First cut

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Feb 2015 07:34:08 +0000

Sure, IP based OAM model and CFM based OAM model have different addressing,
CFM is originally designed for Ethernet technology. but CFM based OAM model support both connection less and connection oriented communication.
Becos Ethernet technologies support both connection oriented and connection less.

Regards!
-Qin
发送时间: 2015年2月5日 14:59

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 6 Feb 2015 16:40:20 +0000

Hi Qin,
IP and IP/MPLS networks are distinctly connectionless and their OAM models, in my view, share very little common elements with Ethernet OAM, which primarily serves transport, i.e. connection-oriented, network, as well as MPLS-TP.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 11:34 PM
To: Gregory Mirsky; [email-masked]
Subject: RE: OAM Model analisys. First cut

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 7 Feb 2015 02:29:51 +0000

Hi Deepak,
many thanks for your suggestions and questions. Please find my notes in-line and tagged GIM>>.

                Regards,
                                Greg

From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Wednesday, February 04, 2015 6:23 PM
To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lime-oam-model] OAM Model analisys. First cut

Hi Greg,

Thanks for detailed Analysis. I have few queries.
In Metrics Is Lock is covered under Defect Indication?
GIM>> Frankly, I haven't thought of Lock. AFAIK, Lock is not to indicate a defect or failure but is the step to turn a service off of the given connection.
How's Test signal get covered?
GIM>> Do you refer to ETH-TST?
Should we talk about Throughput or as it's application ignore for now.
GIM>> Throughput measurement is not an operation but method that can be implemented using different operations.

Metric is covering "Source Information/MEP ID" and "MIP ID", but we should also extend to add other metrics related to Administrative Domain and MEP for completeness.
GIM>> Agree, will add.
For Eg:- Administrative Domain, OAM Technology Layer Type, Level (implicit or NA), MEP addressing and ECMP (Flow Entropy or Customer traffic information).
GIM>> In MPLS-TP Level is realized through SPME, which is a hack, IMO.
We should also add metrics for Server Layer, Client Layer and also concept similar to Server MEP (Which is lower layer of OAM sending AIS/LCK to upper layer to suppress Alarms).
GIM>> I think that Server and Client Layers are distinct only in
Also this concept is useful in OAM interworking between different technology also.

GIM>> I agree that will be beneficial. To add to your point, having Defect data model shared among reviewed OAM models will help as well.

Thanks,
Deepak

Dear All,

                Regards,
                                Greg

---

From: Qin Wu <[email-masked]>
Date: Sat, 7 Feb 2015 06:10:36 +0000

Here is my understanding
IP is connection less but IP can use upper layer protocol to setup connection with other hosts, even though it is communicating over connection less network. The upper layer can be connectionless or connection-oriented.
Ethernet is also connectionless. Ethernet can use upper layer protocol or is encapsulated into connection oriented network technology to set up connections with other hosts, even though it is communicating over connectionless network and data-link layer protocols.
It does not matter whether connectionless or connection-oriented.

Whether connectionless or connection-oriented, the common elements they have are fault domain, test points, addressing, layering.

-Qin
发送时间: 2015年2月7日 0:40

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 7 Feb 2015 06:26:48 +0000

Hi Qin,
could you point to where in IP and IP/MPLS we can find definition of elements analogous to MD/MA or MEG; MP (both MEP and MIP)? In the table I’ve marked all of them as absent in IP and IP/MPLS OAM? Do you think I’ve missed them?

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Friday, February 06, 2015 10:11 PM
To: Gregory Mirsky; [email-masked]
Subject: RE: OAM Model analisys. First cut

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Qin Wu <[email-masked]>
Date: Sat, 7 Feb 2015 06:34:30 +0000

Why MD/MA or MEG should be coupled with Ethernet OAM or MPLS-TP? They are just some terminology. We can make these term more generialized.
What’s the harm to apply MD/MA or MAG to IP and IP/MPLS, I see the benefit
Of using MD/MA or MAG to provide consistent reporting and representation,
Especially in the end to end path diagnose case.

Also LIME’s goal is to provide consistent reporting, representation and configuration.

Regards!
-Qin
发送时间: 2015年2月7日 14:27

Hi Qin,

                Regards,
                                Greg

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 7 Feb 2015 06:39:41 +0000

Hi Qin,
as I understand, LIME WG is not to define new OAM but to create YANG data model for existing. You’re proposing work on introducing new elements into IP and IP/MPLS OAM models. That may be useful but I’m not sure that that is in LIME WG charter. Hope our WG chairs will direct us.

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Friday, February 06, 2015 10:35 PM
To: Gregory Mirsky; [email-masked]
Subject: RE: OAM Model analisys. First cut

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Qin Wu <[email-masked]>
Date: Sat, 7 Feb 2015 06:43:43 +0000

My understanding is LIME WG is not aimed at defining  new OAM protocol.
What am I missing?
Sure, WG chairs and our ADs can provide direction.

Regards!
-Qin
发送时间: 2015年2月7日 14:40

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Sat, 7 Feb 2015 17:28:43 +0000

Hi Greg,

As MEP and MIP are implicit in IP how does defining a Yang model to fill this implicit MEP/MIP specific information changes IP OAM protocol as we are not carrying this MEP/MIP information over the protocol or defining new RPC.
Again this is not OAM specific information but Management specific information for operator(s).

We need this Test point(s) for Yang Application or Server to efficiently debug the problem and Also these Test points give information regarding the underlying Server layer, so it aid application to go down layer one at a time to isolate Fault.

If we don't provide these Test points and intelligence provided by network, then how does Yang effort will be different than snmp mibs currently present except some perfomance improvements.

Thanks,
Deepak

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 6, 2015 10:39 PM
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lime-oam-model] OAM Model analisys. First cut

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 7 Feb 2015 22:53:49 +0000

Hi, Greg, Qin, Deepak,

This is a good discussion. The charter is very explicit about what’s in versus what’s not in scope: “The working group will not develop any new OAM protocols.”

The group is chartered with developing generic YANG data model(s) for OAM mechanisms, as well as an architectural guidance to be used (elsewhere) to develop new OAM protocols or extend existing ones.

It is well within charter to existing OAM mechanisms with models that were not initially defined for them — that is why LIME is needed, to normalize and abstract the OAM functions and elements of various mechanisms.

In particular, I think that the “model” for IP OAM is potentially under-defined, specifically as compared to the MPLS one for example.

Thanks!

— Carlos.

On Feb 7, 2015, at 12:28 PM, Deepak Kumar (dekumar) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Greg,

Thanks,
Deepak

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

_______________________________________________
Lime-oam-model mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime-oam-model

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 8 Feb 2015 00:59:03 +0000

You are both correct.

LIME is not chartered to produce a new OAM protocol. It is chartered to produce a YANG model describing OAM information.

                            Ron

From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Saturday, February 07, 2015 1:44 AM
To: Gregory Mirsky; [email-masked]
Subject: Re: [Lime-oam-model] OAM Model analisys. First cut

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 8 Feb 2015 19:30:56 +0000

Hi Deepak,
these are very fine questions.
I’m not sure that MP (MEP/MIP) has much value outside of OAM model but for our effort to build OAM YANG data model, whether it will be one common for all IETF OAMs or several, it is one of the cornerstones. I don’t have answers to all the questions, at least not yet. And your ideas, suggestions, as of all of our DT, very much welcome and urgently needed.

                Regards,
                                Greg

From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Saturday, February 07, 2015 9:29 AM
To: Gregory Mirsky; Qin Wu; [email-masked]
Subject: Re: [Lime-oam-model] OAM Model analisys. First cut

Hi Greg,

Thanks,
Deepak

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my understanding

-Qin

Hi Qin,

                Regards,
                                Greg

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

Here is my point.

Regards!
-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Greg:

Regards!
-Qin

Dear All,

                Regards,
                                Greg

---

From: Tom Taylor <[email-masked]>
Date: Sun, 08 Feb 2015 16:27:36 -0500

Could we get away from the coded terminology and use something more 
intuitive? Obviously we're venturing into management architecture here, 
but presumably what we need to distinguish to start with (I'm sure 
there's more) are:

-- defect detection points -- talk to the reporting point
-- defect reporting points -- talk to the manager
-- test injection points -- talk to the manager
-- test responding points -- talk to the manager
-- target trail starting point -- obeys the test injection point?
-- target trail ending point -- obeys the test injection point?

These may be collocated in any combination. For instance, for BFD, I 
believe the test injection point and test responding point are collocated.

Tom

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 9 Feb 2015 02:38:38 +0000

Hi Tom,
most of OAM already use MP (MIP/MEP) terminology. It was adopted for MPLS-TP OAM and, as I understand, it's been used in TRIL OAM. I see benefits of sticking to terminology widely used in all OAM rather than inventing some new.

	Regards,
		Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Sunday, February 08, 2015 1:28 PM
To: [email-masked]
Subject: Re: [Lime-oam-model] OAM Model analisys. First cut

Could we get away from the coded terminology and use something more intuitive? Obviously we're venturing into management architecture here, but presumably what we need to distinguish to start with (I'm sure there's more) are:

These may be collocated in any combination. For instance, for BFD, I believe the test injection point and test responding point are collocated.

Tom

On 08/02/2015 2:30 PM, Gregory Mirsky wrote:
> From: Gregory Mirsky 
> <[email-masked]<mailto:[email-masked]>>
> To: Qin Wu <[email-masked]<mailto:[email-masked]>>, 
> "[email-masked]<mailto:[email-masked]>" 
> <[email-masked]<mailto:[email-masked]>>
> To: Gregory Mirsky; 
> [email-masked]<mailto:[email-masked]>
> What’s the harm to apply MD/MA or MAG to IP and IP/MPLS, I see the 
> benefit Of using MD/MA or MAG to provide consistent reporting and 
> representation, Especially in the end to end path diagnose case.
>
> To: Gregory Mirsky; 
> [email-masked]<mailto:[email-masked]>
> To: Gregory Mirsky; 
> [email-masked]<mailto:[email-masked]>
> Sure, IP based OAM model and CFM based OAM model have different 
> addressing, CFM is originally designed for Ethernet technology. but CFM based OAM model support both connection less and connection oriented communication.
> To: Gregory Mirsky; 
> [email-masked]<mailto:[email-masked]>
> e.g., IEEE 802.1Q based model is similar to Y.1731 based model MEF 38 
> and MEF39 use 802.1Q based model, i.e., CFM model.
> To: Gregory Mirsky; 
> [email-masked]<mailto:[email-masked]>
> If we have all the referenced document put together, it will be easy 
> to help us to find what are common things in these various OAM technologies.
> c.  MPLS-TP OAM model in the section 4 of RFC6371 d. MEF-38 Service 
> OAM Fault Management YANG Modules Technical Specification e. MEF-39 
> Service OAM Performance Monitoring YANG Module Technical Specification
>
> -Qin
> To: Gregory Mirsky; 
> [email-masked]<mailto:[email-masked]>
> Besides Common OAM functions, we also have fault domain, test point, 
> addressing, technology type, sub technology type, specific layer. They are all common things for all the OAM technologies.
>
> Regards!
> -Qin

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Feb 2015 02:14:43 +0000

When is the next LIME design team meeting? It looks we have sorted out a lot of thing.

-Qin
-----邮件原件-----
发件人: Lime-oam-model [mailto:[email-masked]] 代表 Tom Taylor
发送时间: 2015年2月9日 5:28
收件人: [email-masked]
主题: Re: [Lime-oam-model] OAM Model analisys. First cut

Tom