Subject: [Lime-oam-model] Status

From: Ronald Bonica <[email-masked]>
Date: Sun, 1 Mar 2015 22:40:19 +0000

Folks,

Since the group's formation, we have lost two members (Nobo and Tissa). Santosh PK will replace Nobo.

Could Qin or Greg summarize that group's status for Santosh?

Also, Qin and Greg, do you think that the design team will have anything to report at IETF 92?

                                                Ron Bonica

---

From: Qin Wu <[email-masked]>
Date: Fri, 6 Mar 2015 03:37:41 +0000

Ron:
If my understanding is correct, here is the status of group discussion.
Based on first design team discussion ,people agreed to sort out common OAM requirements first, Greg provides OAM (Data) Model Analysis table from his perspective which compares IP OAM, IP/MPLS OAM, MPLS-TP OAM, TRILL OAM from several criteria and lists several common requirements.

Based on OAM Model Analysis, common elements used for OAM model are agreed, e.g., testing point, connection oriented vs connectionless,loss of continuity defect,fault domain,technology type, addressing, ECMP, common OAM functions(e.g., cc,cv, path discovery, performance measurement).

CFM like model as management plane model is orthogonal to data plane OAM protocol and meet all these requirements. 
Also MP terminologies are widely used in the most of OAM technologies, it is not a good idea to define new terminologies to represent common elements for the OAM model.

Therefore my understanding is that the choice of an OAM model seems to have no impact on the LIME work.
LIME model focuses on common part of various OAM technologies, therefore LIME's work can be made "model agnostic".

Regards!
-Qin
-----邮件原件-----
发件人: Lime-oam-model [mailto:[email-masked]] 代表 Ronald Bonica
发送时间: 2015年3月2日 6:40
收件人: [email-masked]
主题: [Lime-oam-model] Status

Folks,

                                                Ron Bonica

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

---

From: Ronald Bonica <[email-masked]>
Date: Fri, 6 Mar 2015 21:27:45 +0000

Qin,

Thanks for this summary. Unless I hear otherwise, I will assume that this is the group's consensus.

IMHO, the design team has three tasks standing between itself and completion:

- craft a slide deck documenting findings
- present that slide deck at IETF 92
- produce an ID recording findings

Do we have volunteers for any of those tasks?

                                                                 Ron

> -----Original Message-----
> From: Lime-oam-model [mailto:[email-masked]] On
> Behalf Of Qin Wu
> Sent: Thursday, March 05, 2015 10:38 PM
> To: Ronald Bonica; [email-masked]
> Cc: Deepak Kumar (dekumar)
> Subject: Re: [Lime-oam-model] Status
> 
> Ron:
> Based on first design team discussion ,people agreed to sort out common
> OAM requirements first, Greg provides OAM (Data) Model Analysis table
> from his perspective which compares IP OAM, IP/MPLS OAM, MPLS-TP
> OAM, TRILL OAM from several criteria and lists several common
> requirements.
> 
> Based on OAM Model Analysis, common elements used for OAM model are
> agreed, e.g., testing point, connection oriented vs connectionless,loss of
> continuity defect,fault domain,technology type, addressing, ECMP, common
> OAM functions(e.g., cc,cv, path discovery, performance measurement).
> 
> CFM like model as management plane model is orthogonal to data plane
> OAM protocol and meet all these requirements.
> Also MP terminologies are widely used in the most of OAM technologies, it is
> not a good idea to define new terminologies to represent common elements
> for the OAM model.
> 
> LIME model focuses on common part of various OAM technologies,
> therefore LIME's work can be made "model agnostic".
> 
> Regards!
> -Qin
> -----邮件原件-----

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Mar 2015 09:08:18 +0000

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]] 
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

[Qin]: It has been a few days and no-one has disagreed.

[Qin]: I will write the first draft and we can discuss on this list.

[Qin]: I am happy to do this if no one has objection.

[Qin]: I can also start this task. I think I can make a first draft before Dallas, but I am not allowed to post it until Monday morning of IETF week in Dallas.

Is that OK?

Thanks.

                                                                 Ron

> Based on first design team discussion ,people agreed to sort out 
> common OAM requirements first, Greg provides OAM (Data) Model Analysis 
> table from his perspective which compares IP OAM, IP/MPLS OAM, MPLS-TP 
> agreed, e.g., testing point, connection oriented vs 
> connectionless,loss of continuity defect,fault domain,technology type, 
> addressing, ECMP, common OAM functions(e.g., cc,cv, path discovery, performance measurement).
> 
> Also MP terminologies are widely used in the most of OAM technologies, 
> it is not a good idea to define new terminologies to represent common 
> elements for the OAM model.
>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 9 Mar 2015 16:11:50 +0000

Hi Qin, Ron, et. al,
apologies for the extended absence from the discussion.
      > OAM protocol and meet all these requirements.
Does not entirely reflect state of discussion within the DT, especially that "CFM like model … meets all the requirements".

And I cannot agree with the conclusion here either:
      > Also MP (assume that 'MP' stands for 'Maintenance Point') terminologies are widely used in the most of OAM technologies,
It is not about luck of terminology but luck of terminology likely indicates that respective objects not being identified or used. Hence, if we to build common OAM model, objects should be identified and defined, including through terminology. Alternatively, we have OAM technologies that share sufficient commonality to work with.

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

> To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
> 收件人: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
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: Tue, 10 Mar 2015 01:30:00 +0000

Folks,

Can I ask the design team to meet urgently this week and come to one of the following conclusions? Either:

1)      We have complete consensus and it is ………

2)      We have complete consensus on A, B and C. We don’t have consensus on D, E, and F

3)      We can’t even agree on the questions

If the answer is 2), please be prepared to describe A, B, C, D, E and F at IETF 92. Also, be prepared to describe the rationale between opposing positions.

                                                                         Ron

4)      We have consensus and it is {{From: Gregory Mirsky [mailto:[email-masked]]
Sent: Monday, March 09, 2015 12:12 PM
To: Qin Wu; Ronald Bonica; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Mar 2015 02:04:50 +0000

发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2015年3月10日 0:12
收件人: Qin Wu; Ronald Bonica; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Hi Qin, Ron, et. al,
Does not entirely reflect state of discussion within the DT, especially that "CFM like model … meets all the requirements".
[Qin]: which requirements are not met by CFM like model.
In your comparison analysis table, you compare IP OAM, IP/MPLS OAM, MPLS-TP OAM, TRILL OAM, the following components are
supported by all the OAM technologies:
1.Trail Termination Source Information/MEP ID
2.MIP ID Implicit
3.On-demand Continuity Check
4.Proactive Continuity Check
5.On-demand Connectivity Verification
6.Loss Measurement
7.Delay Measurement
8.Loss of Continuity Defect
Therefore I believe CFM like model or layer independent OAM model support these above components.
As for Other components
9.Forward Defect Indication
10.Backward Defect Indication
11.Miss-merge Defect
12.Miss-connection Defect
These components can be supported by technology-specific data model extensions.

> elements for the OAM model.
[Qin]: I am just summarizing what we discussed before. I am confused with your statement.
Tom Taylor proposed to use new terminology to describe OAM model when you disagreed to use MP/MIP like terminologies.
You suggest not invent new terminologies.
http://www.ietf.org/mail-archive/web/lime-oam-model/current/msg00056.html
Isn’t your current statement against what you said to Tom’s proposal before?

[Qin]: which objects are not identified besides the above components you listed above?

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Tom Taylor <[email-masked]>
Date: Mon, 09 Mar 2015 22:25:41 -0400

My original E-mail protested against the abbreviations, but now I've 
read enough to understand them. BUT I also in that E-mail gave a list of 
functionalities, and I want to be sure that these are all covered by the 
entities that have been cited.

>> therefore LIME's work can be made "model agnostic".
...

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Mar 2015 02:32:01 +0000

Yes, I think functionalities you cited have been covered by existing entities.
I am also not encouraging to break down existing entities into more functionalities since this will add complexity.

-Qin
-----邮件原件-----
发件人: Tom Taylor [mailto:[email-masked]] 
发送时间: 2015年3月10日 10:26
收件人: Qin Wu; Gregory Mirsky; Ronald Bonica; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: Re: [Lime-oam-model] Status

My original E-mail protested against the abbreviations, but now I've read enough to understand them. BUT I also in that E-mail gave a list of functionalities, and I want to be sure that these are all covered by the entities that have been cited.

On 09/03/2015 10:04 PM, Qin Wu wrote:
> In your comparison analysis table, you compare IP OAM, IP/MPLS OAM, 
> MPLS-TP OAM, TRILL OAM, the following components are supported by all the OAM technologies:
> 1.Trail Termination Source Information/MEP ID 2.MIP ID Implicit 
> 3.On-demand Continuity Check 4.Proactive Continuity Check 5.On-demand 
> Connectivity Verification 6.Loss Measurement 7.Delay Measurement 
> 8.Loss of Continuity Defect Therefore I believe CFM like model or 
> layer independent OAM model support these above components.
> As for Other components
>> Also MP (assume that 'MP' stands for 'Maintenance Point') 
>> terminologies are widely used in the most of OAM technologies, it is 
>> not a good idea to define new terminologies to represent common elements for the OAM model.
> http://www.ietf.org/mail-archive/web/lime-oam-model/current/msg00056.h
> tml Isn’t your current statement against what you said to Tom’s 
> proposal before?
>
> To: Ronald Bonica; 
> [email-masked]<mailto:[email-masked]>
>> To: Ronald Bonica; 
>> [email-masked]<mailto:[email-masked]>
>> common OAM requirements first, Greg provides OAM (Data) Model 
>> Analysis table from his perspective which compares IP OAM, IP/MPLS 
>> OAM, MPLS-TP OAM, TRILL OAM from several criteria and lists several 
>> common requirements.
>>
>> connectionless,loss of continuity defect,fault domain,technology 
>> type, addressing, ECMP, common OAM functions(e.g., cc,cv, path discovery, performance measurement).
>>
>> Also MP terminologies are widely used in the most of OAM 
>> technologies, it is not a good idea to define new terminologies to 
>> represent common elements for the OAM model.
>>
...

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 10 Mar 2015 04:14:51 +0000

Hi Ron, et. al,
I’m in San Jose, if we can pull f2f. Otherwise, I’m available to a call at any time that works for the team.

                Regards,
                                Greg

From: Ronald Bonica [mailto:[email-masked]]
Sent: Monday, March 09, 2015 6:30 PM
To: Gregory Mirsky; Qin Wu; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Folks,

                                                                         Ron

4)      We have consensus and it is {{From: Gregory Mirsky [mailto:[email-masked]]
Sent: Monday, March 09, 2015 12:12 PM
To: Qin Wu; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Mar 2015 04:35:28 +0000

Works for me.

-Qin
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月10日 9:30
收件人: Gregory Mirsky; Qin Wu; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Tue, 10 Mar 2015 05:25:57 +0000

Works for me also.

Thanks,
Deepak

From: Qin Wu <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 9, 2015 8:35 PM
To: Ronald Bonica <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: dekumar <[email-masked]<mailto:[email-masked]>>
Subject: RE: Status

Works for me.

-Qin
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月10日 9:30
收件人: Gregory Mirsky; Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 10 Mar 2015 13:41:43 +0000

Greg, Qin,

Why don’t you two guys meet f2f. Bring up a conference bridge so that others can join you remotely.

                                                           Ron

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 12:35 AM
To: Ronald Bonica; Gregory Mirsky; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Mar 2015 04:10:27 +0000

I am willing to talk with Greg, but not possible for f2f. Also I am not possible to offer convenient conference bridge like WebEx.

-Qin
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月10日 21:42
收件人: Qin Wu; Gregory Mirsky; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Greg, Qin,

                                                           Ron

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 12:35 AM
To: Ronald Bonica; Gregory Mirsky; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Mar 2015 04:41:32 +0000

Hi Qin, et. al,
we can use my bridge:
Join the Audio Conference
Dial-In:

89922 ECN Short number

800 33 200 ECN Worldwide

+1 97 258 33200 International

+1 972 583 3200 Local USA, Plano, TX

Passcode:

6934 7421#

For a current list of available local and international freephone telephone numbers, CLICK HERE<http://www.yourconferencecentre.com/r.aspx?p=11&a=DaxemMxGoamuck>
Please pick two-three time slots that works well for you.

          Regards,
                   Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 9:10 PM
To: Ronald Bonica; Gregory Mirsky; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

-Qin
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月10日 21:42
收件人: Qin Wu; Gregory Mirsky; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Mar 2015 05:50:34 +0000

Greg:
Thanks for your offer:
I am in GMT+8. Any my working time works for me.

-Qin
发送时间: 2015年3月11日 12:42

Hi Qin, et. al,
we can use my bridge:

89922 ECN Short number

800 33 200 ECN Worldwide

Passcode:

6934 7421#

          Regards,
                   Greg

-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Mar 2015 22:29:39 +0000

Hi Qin, et. al,
I’m in -8:00 UTC zone. My 17:00 would be 09:00 next day for you, Qin. Right? Would that or hour later on my Thursday ( Friday 09:00 or 10:00) work?

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 10:51 PM
To: Gregory Mirsky; Ronald Bonica; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Greg:
Thanks for your offer:

-Qin
发件人: Gregory Mirsky [mailto:[email-masked]]
发送时间: 2015年3月11日 12:42
收件人: Qin Wu; Ronald Bonica; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Hi Qin, et. al,
we can use my bridge:

89922 ECN Short number

800 33 200 ECN Worldwide

Passcode:

6934 7421#

          Regards,
                   Greg

-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2015 01:26:39 +0000

Sorry for late, all your proposed time looks good to me, let me know when you are online.

-Qin
发件人: Lime-oam-model [mailto:[email-masked]] 代表 Gregory Mirsky
发送时间: 2015年3月12日 6:30
收件人: Qin Wu; Ronald Bonica; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: Re: [Lime-oam-model] Status

Hi Qin, et. al,

                Regards,
                                Greg

From: Qin Wu [mailto:[email-masked]]
Sent: Tuesday, March 10, 2015 10:51 PM
To: Gregory Mirsky; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: RE: Status

Greg:
Thanks for your offer:

-Qin

Hi Qin, et. al,
we can use my bridge:

89922 ECN Short number

800 33 200 ECN Worldwide

Passcode:

6934 7421#

          Regards,
                   Greg

-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Sat, 14 Mar 2015 08:25:52 +0000

Hi, Design team members:
Based on Ron’s request, Greg and I had a conference call on Friday and discussed LIME OAM model again, Deepak also joined the discussion.
Based on the discussion, I think we generally agreed commonality among various OAM technologies. The current model is applicable in IP for VPN technologies but not sure about non VPN scenarios which require more discussion.

Here is the initial version of Design team report we like to deliver and present at IETF92.
I like to ask your review and input. Thanks!

BTW: I apologize for the confusion as Tissa and nobo were left. Welcome Santosh on board.

Regards!
-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 16 Mar 2015 20:49:37 +0000

Folks,

If anyone doesn’t agree with the contents of this slide deck, now is the time to speak up.

If nobody objects, is anyone willing to present the deck at IETF 92?

Also, is this deck ready to post?

                                     Ron

From: Qin Wu [mailto:[email-masked]]
Sent: Saturday, March 14, 2015 4:26 AM
To: Ronald Bonica; Gregory Mirsky; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: Design Team report

Hi, Design team members:

Regards!
-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 16 Mar 2015 22:10:18 +0000

Dear All,
I’ll review and send my notes by tomorrow morning (Pacific time :))
Apologies for the delay.

                Regards,
                                Greg

From: Ron Bonica [mailto:[email-masked]]
Sent: Monday, March 16, 2015 1:50 PM
To: Qin Wu; Gregory Mirsky; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: RE: Design Team report

Folks,

                                     Ron

Hi, Design team members:

Regards!
-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 16 Mar 2015 23:49:53 +0000

Dear Qin,
many thanks for building very informative presentation on behalf of the DT.
Couple notes:

·         When talking about IP OAM I mean OAM for IP and LDP-based IP/MPLS networks. Perhaps p.6 may be good place to make such clarification;

·         to table on p.11:

o   connectivity verification assumes that there exists definition of miss-connection defect along with definitions of in-defect and out-defect conditions. I believe that neither IP, nor IP/MPLS had so far defined miss-connection defect and it only exists for MPLS-TP in RFC 6428. I think that table should be updated to reflect that only MPLS Echo Request/Reply, a.k.a. LSP Ping does support connectivity verification while other OAM mechanisms listed in the Connectivity Verification column (BFD, ICMP Ping, OWAMP/TWAMP Control protocols) do not support it;

o   not clear what role OWAMP/TWAMP control protocols play as Continuity Check OAM mechanism. Is it because they use TCP connection between Server and Control Client? But Server and Control Client could be network elements outside of Sender and Receiver/Reflector. By the same logic, should any application, e.g. BGP, that uses TCP connection be considered as Continuity Check OAM mechanism? I don’t think that is the case.

o   does TRILL OAM support Alarm suppression, Automatic Protection Switchover coordination like Y.1731?

o   MPLS-TP OAM includes Protection Switchover Coordination protocol RFC 6378;

o   I’m not familiar with Diagnostic Test or Client Failure Notification is MPLS –TP OAM function or mechanism, could you please help with the reference;

·         I’d like the Conclusion page to use two last bullets from p.6:

o   Make sure the LIME model proposed in /draft-tissa-lime-yang-oam-model-03 support IP OAM feature.

o   Or define IP OAM model first and separate it from LIME OAM model if the current model cannot support IP OAM.

Regards,
                Greg

Sent: Saturday, March 14, 2015 1:26 AM

Hi, Design team members:

Regards!
-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Mar 2015 01:38:19 +0000

Ron:
I will present if nobody objects.
Unless somebody has update, we are almost ready to post.

-Qin
发件人: Ron Bonica [mailto:[email-masked]]
发送时间: 2015年3月17日 4:50
收件人: Qin Wu; Gregory Mirsky; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: RE: Design Team report

Folks,

                                     Ron

Hi, Design team members:

Regards!
-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Mar 2015 02:35:33 +0000

Hi, Greg:
We are looking commonality pieces among various OAM technologies, not intending to include all the features define by each OAM technologies.
See my reply inline below.

-Qin
发送时间: 2015年3月17日 7:50

Dear Qin,

[Qin]:My pleasure.
Couple notes:

[Qin]:It seems you are talking about technology-specific data model extensions, e.g., mis-connection defect defined in MPLS-TP, alarm suppression, automatic protection switchover coordination defined in Y.1731. These model extension can be worked on in specific protocol Working group.

·         to table on p.11:

o   connectivity verification assumes that there exists definition of miss-connection defect along with definitions of in-defect and out-defect conditions. I believe that neither IP, nor IP/MPLS had so far defined miss-connection defect and it only exists for MPLS-TP in RFC 6428.

                           [Qin]: I think this is a piece belonging to technology-specific data model extensions, if you propose to make it common to all the OAM technologies, we can add “mis-connection
  defect”  As optional data node in the schema tree.

I think that table should be updated to reflect that only MPLS Echo Request/Reply, a.k.a. LSP Ping does support connectivity verification while other OAM mechanisms listed in the Connectivity Verification column (BFD, ICMP Ping, OWAMP/TWAMP Control protocols) do not support it;

                           [Qin] RFC7276 is the product of opsawg Working Group and summarize a lot of commonality among various OAM technologies. We should stick to use it. LIME WG should use
RFC7276 as basis to build generic model.
                           Your above statement is not consistent with RFC7276, table 4 since Table 4 indicates that connectivity verification are supported by BFD, OWAMP/TWAMP.
                           Also in page 7 of this slides, comparison table, on demand cv are supported by IP OAM.

                          [Qin]: First, RFC7276 table 4 said Continuity Check is supported by OWAMP/TWAMP control protocols. I believe there was consensus to add this support in the RFC7276. Why should we be skeptical about this?
                           Second, whether server and client is the network element outside of sender and receiver is implementation specific.

                         [Qin]: We are looking for commonality among various OAM technologies, not commonality between any two OAM technologies, if a feature is only supported by one OAM          technologies, we should define this feature in the technology-specific data model extensions.

                        [Qin]: Same as above.

                       [Qin]: We can make them as optional feature if we need to include them in the generic model for all the OAM technologies.
Yes, I will look for the reference.

                     [Qin]: It looks to me not necessary since we talk a lot about commonality among various OAM technologies. Also I think IP OAM feature should be supported by LIME generic OAM              model,  Otherwise it defeats the goal to building generic model. I would suggest author of tissa’s draft to give a presentation  and clarify how IP OAM is supported by LIME model proposed
                     In the tissa’s draft. I think this will address your comment.
                     Deepak, what do you think of this?

Regards,
                Greg

Hi, Design team members:

Regards!
-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 17 Mar 2015 05:13:30 +0000

Hi Qin,
yes, we’re looking for commonality among several OAM and for that, I believe, we need to describe them as detailed as possible. Then we, as a group, can see what is common and whether that common area is substantial or not.
Couple more notes in-line and tagged with GIM>>.

                Regards,
                                Greg

Sent: Monday, March 16, 2015 7:36 PM

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

[Qin]:It seems you are talking about technology-specific data model extensions, e.g., mis-connection defect defined in MPLS-TP, alarm suppression, automatic protection switchover coordination defined in Y.1731. These model extension can be worked on in specific protocol Working group.
GIM>> The definition of mis-connection defect is not MPLS-TP specific but common for transport networks, e.g. TDM, OTN. Again, we are trying to identify the common set and thus, I believe, need to be as detailed as possible.

·         to table on p.11:

                           [Qin]: I think this is a piece belonging to technology-specific data model extensions, if you propose to make it common to all the OAM technologies, we can add “mis-connection
  defect”  As optional data node in the schema tree.
GIM>> It very well could become technology-specific but I think it would be result of the analysis, unless you already have the answer.

GIM>> I find RFC 7276 to have inconsistent with transport network OAM as per G.800, Y.1710, and Y.1711. Personally, I don’t recall it was reviewed by MPLS or BFD WGs.

                        [Qin]: Same as above.

                     [Qin]: It looks to me not necessary since we talk a lot about commonality among various OAM technologies. Also I think IP OAM feature should be supported by LIME generic OAM              model,  Otherwise it defeats the goal to building generic model. I would suggest author of tissa’s draft to give a presentation  and clarify how IP OAM is supported by LIME model proposed
                     In the tissa’s draft. I think this will address your comment.
                     Deepak, what do you think of this?
GIM>> I don’t put forth what should and what should not be the result of an investigation before I collect all the data available. Apparently you already have the answer.

Regards,
                Greg

Hi, Design team members:

Regards!
-Qin

Greg, Qin,

                                                           Ron

Works for me.

-Qin

Folks,

                                                                         Ron

Hi Qin, Ron, et. al,

        Regards,
                Greg

-----Original Message-----
From: Lime-oam-model [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, March 09, 2015 2:08 AM
To: Ronald Bonica; [email-masked]<mailto:[email-masked]>
Cc: Deepak Kumar (dekumar)
Subject: Re: [Lime-oam-model] Status

Hi, Ron:
-----邮件原件-----
发件人: Ronald Bonica [mailto:[email-masked]]
发送时间: 2015年3月7日 5:28
收件人: Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Status

Qin,

Is that OK?

Thanks.

                                                                 Ron

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Mar 2015 05:58:39 +0000

Hi, Greg:

发送时间: 2015年3月17日 13:14

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

・         When talking about IP OAM I mean OAM for IP and LDP-based IP/MPLS networks. Perhaps p.6 may be good place to make such clarification;

[Qin]: Based on your analysis table which compared IP OAM, IP/MPLS OAM, MPLS-TP, TRILL OAM, it looks apparent that mis-connection defect metric and mis-merge defect are both not common to various OAM technologies and only applied to MPLS-TP and TRILL and not applied to IP OAM and IP/MPLS OAM.

・         to table on p.11:

[Qin]: Yes, this is from analysis table. The analysis table was initially provided by you. :)

[Qin]: If you don’t believe RFC7276 or consensus building from OPSAWG, I think you should ask chairs of OPSAWG.

……..

[Qin]: It was discussed on last Friday, it looks what you suggested is to separate OAM model analysis discussion from draft discussion(i.e., how draft-tissa-lime-yang-oam-model<http://tools.ietf.org/id/draft-tissa-lime-yang-oam-model-03.txt> support IP OAM feature). What am I missing?

Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 17 Mar 2015 18:11:24 +0000

Hi Qin,
as I’ve explained my position last week, I see two options:

・         limit scope of draft-tissa-lime-yang-oam-model-03;

・         extend existing OAM models first to create sufficient common set of OAM elements to be described by OAM Generic Data Model.
Because not only OAM of IP and LDP-based IP/MPLS networks lucks in definition of elements to be modeled, but MPLS-TP OAM is only applicable to bi-directional p2p LSPs and not to uni-directional p2p and p2mp LSPs, current scope of common elements is even less the ping and traceroute. Unless you propose to refer to a data model as generic even though many elements are yet undefined and may not fit into that model.

                Regards,
                                Greg

Sent: Monday, March 16, 2015 10:59 PM

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

・         to table on p.11:

……..

Regards,
                Greg

---

From: Qin Wu <[email-masked]>
Date: Wed, 18 Mar 2015 02:57:10 +0000

Hi, Greg:

发送时间: 2015年3月18日 2:11

Hi Qin,

・         extend existing OAM models first to create sufficient common set of OAM elements to be described by OAM Generic Data Model.
Because not only OAM of IP and LDP-based IP/MPLS networks lacks in definition of elements to be modeled,

[Qin]: LIME model proposed in draft-tissa-lime-yang-oam-model-03 has added such definitions. We already have a good basis for generic model to start with.
In the last IETF meeting, tissa have given a good presentation on how LIME model supports IP OAM, e.g., LIME model supports various addressing including IP addressing.

but MPLS-TP OAM is only applicable to bi-directional p2p LSPs and not to uni-directional p2p and p2mp LSPs,

[Qin]: Do you proposed to add p2p and p2mp,bi-directional, uni-direcational as part of LIME generic model, or add them as part of technology-specific data model extensions?

current scope of common elements is even less the ping and traceroute.

[Qin]: ping is corresponding to cc and traceroute is corresponding to path discovery in the table of RFC7276, we can make these rpc more generic.

Unless you propose to refer to a data model as generic even though many elements are yet undefined and may not fit into that model.

[Qin]: Elements common to various OAM technologies, have been identified based on a lot of our discussion, I believe you are talking a lot about piece belonging to technology-specific data model extensions. Also you might consider to add some pieces you identified during the analysis into LIME generic model or LIME base draft, That’s good, but that  can be used to improve base draft.
                Regards,
                                Greg

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

・         to table on p.11:

……..

Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 18 Mar 2015 16:06:32 +0000

Hi Qin,
I think we clearly agree to disagree on some fundamental issues. Perhaps the DT report is the right place to reflect that and continue discussion with the participation from WG experts.

                Regards,
                                Greg

Sent: Tuesday, March 17, 2015 7:57 PM

Hi, Greg:

发件人: Gregory Mirsky [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
发送时间: 2015年3月18日 2:11
收件人: Qin Wu; Ronald Bonica; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Design Team report

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

・         to table on p.11:

……..

Regards,
                Greg

---

From: Tom Taylor <[email-masked]>
Date: Wed, 18 Mar 2015 14:23:00 -0400

Below with [PTT].

...
>
> [Qin]: Do you proposed to add p2p and p2mp,bi-directional,
> uni-direcational as part of LIME generic model, or add them as part of
> technology-specific data model extensions?
>
[PTT] I would think topology is technology-independent as an abstract 
concept, and therefore belongs in the generic model. To bring that in 
line with reality, there would have to be interplay with the 
technology-specific models to indicate which topologies these models 
support.

...

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 19 Mar 2015 02:21:23 +0000

I agree with Tom, Topology is technology-independent and should belong to
generic model and expand it in technology specific model with specific
like p2p, p2mp, etc..

Thanks,
Deepak

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Mar 2015 04:07:14 +0000

+1

-Qin
-----邮件原件-----
发件人: Deepak Kumar (dekumar) [mailto:[email-masked]] 
发送时间: 2015年3月19日 10:21
收件人: Tom Taylor; Qin Wu; Gregory Mirsky; Ronald Bonica; [email-masked]
主题: Re: [Lime-oam-model] Design Team report

I agree with Tom, Topology is technology-independent and should belong to generic model and expand it in technology specific model with specific like p2p, p2mp, etc..

Thanks,
Deepak

On 3/18/15 11:23 AM, "Tom Taylor" <[email-masked]> wrote:

>> uni-direcational as part of LIME generic model, or add them as part 
>> of technology-specific data model extensions?
>>

---

From: Ronald Bonica <[email-masked]>
Date: Thu, 19 Mar 2015 05:28:23 +0000

Folks,

If the DT isn’t converging, please document the points of disagreement. The meeting is just five days away!

                            Ron

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, March 18, 2015 5:07 PM
To: Qin Wu; Ronald Bonica; [email-masked]
Cc: Deepak Kumar (dekumar)
Subject: RE: Design Team report

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

・         to table on p.11:

……..

Regards,
                Greg

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Mar 2015 06:07:00 +0000

It looks we have different understanding on Carlos’s statement “IP OAM is underdefined”.
I think how IP OAM is supported by LIME model has been discussed by Tissa in the last meeting.
LIME model proposed in draft-tissa-lime-yang-oam-model<http://tools.ietf.org/id/draft-tissa-lime-yang-oam-model-03.txt> did support IP OAM and fill this gap.
I disagree this is fundamental issue since we have a good basis model to start with,
any missing elements to be agreed can be added later into LIME generic model.

Regards!
-Qin
发送时间: 2015年3月19日 0:07

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

・         to table on p.11:

……..

Regards,
                Greg

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Mar 2015 06:20:32 +0000

Hi, Ron:
If there is any point of disagreement, it has been documented in the page 6 of the slides with
“
current model is applicable in IP for VPN technologies but not sure about non VPN scenarios which require more discussion.
”
I don’t think this is a big issue since we have justified to Greg and we can fill the gap if anything missing piece coming up.
we can move this to the conclusion page if you think necessary.

-Qin
发送时间: 2015年3月19日 13:28

Folks,

                            Ron

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

*         limit scope of draft-tissa-lime-yang-oam-model-03;

*         extend existing OAM models first to create sufficient common set of OAM elements to be described by OAM Generic Data Model.
Because not only OAM of IP and LDP-based IP/MPLS networks lacks in definition of elements to be modeled,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

*         When talking about IP OAM I mean OAM for IP and LDP-based IP/MPLS networks. Perhaps p.6 may be good place to make such clarification;

*         to table on p.11:

……..

Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Mar 2015 15:22:52 +0000

Hi Qin,
I’m not aware of “IP for VPN” whether OAM or network. I believe there’s IP regardless it is overlay or not. And the draft you’re supporting so strongly does not apply to IP OAM.

                Regards,
                                Greg

Sent: Wednesday, March 18, 2015 11:21 PM

Hi, Ron:

-Qin
发件人: Ronald Bonica [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
发送时间: 2015年3月19日 13:28
收件人: Gregory Mirsky; Qin Wu; [email-masked]<mailto:[email-masked]>
抄送: Deepak Kumar (dekumar)
主题: RE: Design Team report

Folks,

                            Ron

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

*         to table on p.11:

……..

Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Mar 2015 15:22:48 +0000

Hi Deepak,
I thought I agree with Tom that topology of monitored object, e.g. p2p or mp2mp, is technology-independent OAM-wise but your view puts topology against ... topology. Perhaps you can illustrate or give definition to what you view as technology-independent topology and how it is different from the topology of monitored object.

	Regards,
		Greg

-----Original Message-----
From: Deepak Kumar (dekumar) [mailto:[email-masked]] 
Sent: Wednesday, March 18, 2015 7:21 PM
To: Tom Taylor; Qin Wu; Gregory Mirsky; Ronald Bonica; [email-masked]
Subject: Re: [Lime-oam-model] Design Team report

Thanks,
Deepak

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 19 Mar 2015 15:22:53 +0000

Dear Qin,
“we have justified to Greg”
I think it would be fair and appropriate that the WG decides that. In the meantime the authors of the draft-tissa-lime-yang-oam-model<http://tools.ietf.org/id/draft-tissa-lime-yang-oam-model-03.txt> may choose to work on filling the gap. I’ll be glad to review and provide my comments.

                Regards,
                                Greg

Hi, Ron:

-Qin

Folks,

                            Ron

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

*         to table on p.11:

……..

Regards,
                Greg

---

From: Tom Taylor <[email-masked]>
Date: Thu, 19 Mar 2015 16:22:07 -0400

The bottom line is this:
  -- what service does the IP layer provide? (Datagram service, of 
course, with no guarantees of ordering or delivery.)
  -- what are the observable defects in that service? I'd say loss, 
delay, and maybe jitter (or is that a transport-level (L4) defect?) 
beyond expected levels.
  -- what management tools do we need to detect these defects? To 
localize them? Do they fall into the alphabet soup of operations Qin is 
so keen on?

Obviously, ping and traceroute are the prime IP-level working tools. But 
I wouldn't call ping a matter of Connectivity Check except in the 
grossest sense. It's not normally a matter of 0% loss vs. 100% loss, but 
loss exceeding, say, 5%. You would have to redefine connectivity failure 
to mean "loss above expected level" to make ping fit into that 
framework. In the absence of such a definition, I would say that 
Connectivity Check has limited usefulness at the IP level. Connectivity 
Verification is, of course, totally irrelevant. One can think of some 
aspects of ICMP as Backward Defect Indication (e.g., Destination 
Unreachable).

Ping can certainly be seen as a performance measurement tool, for both 
delay and loss. And both ping and traceroute effectively use loopback.

Linktrace is a recurring issue, assuming it means tracing the exact path 
taken by packets. The ECMP problem was noted in the problem statement. 
IP OAM is missing a tool for that.

My conclusion is that IP OAM is implemented within limits. Performance 
measurement is the primary means to detect defects at the IP level. As a 
result, I don't quite agree with the entries in the IP column of Greg's 
table (in his message received at the IETF Tue,  3 Feb 2015 17:22:29 
-0800 (PST)). Specifically, the Continuity Check items have to be 
qualified (Note 1), Connectivity Verification has to be a "No", there 
should be a qualified "Yes" for Backward Defect Indication (Note 2), and 
the Loss of Continuity Defect "Yes" should be qualified (Note 1 again).

Note 1: for IP OAM, "loss of continuity" is redefined to be an observed 
packet loss rate higher than the expected/engineered level for a 
duration of x seconds.

Note 2: some ICMP messages (e.g., Destination unreachable) can be 
interpreted as Backward Defect Indication.

Tom Taylor

On 19/03/2015 11:22 AM, Gregory Mirsky wrote:
> Hi Qin,
>
> I’m not aware of “IP for VPN” whether OAM or network. I believe there’s
> IP regardless it is overlay or not. And the draft you’re supporting so
> strongly does not apply to IP OAM.
>
>                  Regards,
>
>                                  Greg
>
...

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Fri, 20 Mar 2015 01:34:54 +0000

Hi Greg,

I was referring to following model, where topology is defined as empty in generic model and can be extended by technology specific OAM in their own Yang model.

Grouping topology {
    Choice topology {
      Case topo-null {
        Description
          "this is a placeholder when no topology is needed";
        Leaf topo-null {
           Type empty;
           Descroption
             "there is no topology define, it will be define in technology specific."
        }
      }
    }
}

Grouping MEP {

    Leaf mep-name {
    }
    Uses MEP-ID;
    Uses mp-address;
    Leaf interface {
    }
    Uses topology;
}

Thanks,
Deepak

On 3/19/15 8:22 AM, "Gregory Mirsky" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Deepak,

Regards,
Greg

-----Original Message-----
From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Wednesday, March 18, 2015 7:21 PM
To: Tom Taylor; Qin Wu; Gregory Mirsky; Ronald Bonica; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lime-oam-model] Design Team report

Thanks,
Deepak

On 3/18/15 11:23 AM, "Tom Taylor" <[email-masked]<mailto:[email-masked]>> wrote:

Below with [PTT].

...

---

From: Qin Wu <[email-masked]>
Date: Fri, 20 Mar 2015 02:26:58 +0000

I remember this was something you discussed with Deepak last Friday, therefore we documented it in the slides.

-Qin
发送时间: 2015年3月19日 23:23

Hi Qin,

                Regards,
                                Greg

Hi, Ron:

-Qin

Folks,

                            Ron

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

*         to table on p.11:

……..

Regards,
                Greg

---

From: Qin Wu <[email-masked]>
Date: Fri, 20 Mar 2015 02:35:56 +0000

Based on RFC7276,IP OAM is not primarily used for performance measurement.
RFC7276 Table 4 summarizes the OAM functions that are supported in each of
the OAM toolsets.
Toolset support one or several of these OAM functions including CC, CV, path discovery, performance measurement, other function.
Take IP OAM as example, CC can be supported by IP Ping Toolset using Echo request/reply messages and path discovery can be supported
By IP Traceroute toolset using Traceroute.

-Qin
-----邮件原件-----
发件人: Tom Taylor [mailto:[email-masked]] 
发送时间: 2015年3月20日 4:22
收件人: Gregory Mirsky; Qin Wu; Ronald Bonica; [email-masked]
抄送: Deepak Kumar (dekumar)
主题: Re: [Lime-oam-model] Design Team report

The bottom line is this:
  -- what service does the IP layer provide? (Datagram service, of course, with no guarantees of ordering or delivery.)
  -- what are the observable defects in that service? I'd say loss, delay, and maybe jitter (or is that a transport-level (L4) defect?) beyond expected levels.
  -- what management tools do we need to detect these defects? To localize them? Do they fall into the alphabet soup of operations Qin is so keen on?

Obviously, ping and traceroute are the prime IP-level working tools. But I wouldn't call ping a matter of Connectivity Check except in the grossest sense. It's not normally a matter of 0% loss vs. 100% loss, but loss exceeding, say, 5%. You would have to redefine connectivity failure to mean "loss above expected level" to make ping fit into that framework. In the absence of such a definition, I would say that Connectivity Check has limited usefulness at the IP level. Connectivity Verification is, of course, totally irrelevant. One can think of some aspects of ICMP as Backward Defect Indication (e.g., Destination Unreachable).

Ping can certainly be seen as a performance measurement tool, for both delay and loss. And both ping and traceroute effectively use loopback.

Linktrace is a recurring issue, assuming it means tracing the exact path taken by packets. The ECMP problem was noted in the problem statement. 
IP OAM is missing a tool for that.

My conclusion is that IP OAM is implemented within limits. Performance measurement is the primary means to detect defects at the IP level. As a result, I don't quite agree with the entries in the IP column of Greg's table (in his message received at the IETF Tue,  3 Feb 2015 17:22:29
-0800 (PST)). Specifically, the Continuity Check items have to be qualified (Note 1), Connectivity Verification has to be a "No", there should be a qualified "Yes" for Backward Defect Indication (Note 2), and the Loss of Continuity Defect "Yes" should be qualified (Note 1 again).

Note 1: for IP OAM, "loss of continuity" is redefined to be an observed packet loss rate higher than the expected/engineered level for a duration of x seconds.

Note 2: some ICMP messages (e.g., Destination unreachable) can be interpreted as Backward Defect Indication.

Tom Taylor

On 19/03/2015 11:22 AM, Gregory Mirsky wrote:
> Hi Qin,
>
> I’m not aware of “IP for VPN” whether OAM or network. I believe 
> there’s IP regardless it is overlay or not. And the draft you’re 
> supporting so strongly does not apply to IP OAM.
>
>                  Regards,
>
>                                  Greg
>
...

---

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Mar 2015 08:31:44 -0400

As Greg said, that is the opposite of what I intended. It does raise an 
interesting question: is a service like p2mp an IP service or a service 
provided by a different layer?

Tom

On 19/03/2015 9:34 PM, Deepak Kumar (dekumar) wrote:
> Hi Greg,
>
> I was referring to following model, where topology is defined as empty
> in generic model and can be extended by technology specific OAM in their
> own Yang model.
>
> Grouping topology {
>      Choice topology {
>        Case topo-null {
>          Description
> On 3/19/15 8:22 AM, "Gregory Mirsky" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Deepak,
>     I thought I agree with Tom that topology of monitored object, e.g.
>     p2p or mp2mp, is technology-independent OAM-wise but your view puts
>     topology against ... topology. Perhaps you can illustrate or give
>     definition to what you view as technology-independent topology and
>     how it is different from the topology of monitored object.
>
>     Regards,
>     Greg
>
>     To: Tom Taylor; Qin Wu; Gregory Mirsky; Ronald Bonica;
>     [email-masked] <mailto:[email-masked]>
>     I agree with Tom, Topology is technology-independent and should
>     belong to generic model and expand it in technology specific model
>     with specific like p2p, p2mp, etc..
>
>     Thanks,
>     Deepak
>
>     On 3/18/15 11:23 AM, "Tom Taylor" <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Below with [PTT].
>

---

From: Tom Taylor <[email-masked]>
Date: Fri, 20 Mar 2015 08:34:05 -0400

I guess RFC7276 is wrong, then.

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Fri, 20 Mar 2015 15:51:03 +0000

Hi Tom,

Good point. p2mp can't exist without multicast stack support but as we are
building rpc for tool in generic model I have used common tools (ping,
trace and defect indication (icmp error(s))) and technology specific Yang
can extend these generic tools and add new tools.

This is the reason I visualize about topology to be empty as from generic
model meaning generic model is not providing or assuming any topology
details or restrictions as this can vary from switch to switch also
depending on implementation. Ping/trace rpc in generic model should work
on Addressing itself without any topology details.

But as topology is defined as choice case, we can extend different
topology type easily. Do you see we need to provide any topology specific
restriction in generic model? If yes, then I have no issue extending cases
for different kind of topologies.

Thanks,
Deepak

---

From: Gregory Mirsky <[email-masked]>
Date: Fri, 20 Mar 2015 16:07:03 +0000

Hi Qin,
perhaps it was what we used but that is certainly not the term to use in a document. As VPN presents a single hop, we’re talking about single-hop OAM, for example single-hop BFD. It certainly has some interest but, obviously, very and very small and can not be considered as representative model of IP OAM.

                Regards,
                                Greg

Sent: Thursday, March 19, 2015 7:27 PM

-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Ron:

-Qin

Folks,

                            Ron

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

*         to table on p.11:

……..

Regards,
                Greg

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 21 Mar 2015 09:27:37 -0000

Hi Tom, all,

Tom said 

> I guess RFC7276 is wrong, then.

And i find that a little bit unhelpful.
Since he was replying to Qin:

> > Toolset support one or several of these OAM functions including CC, CV, path
> > discovery, performance measurement, other function.
> > Take IP OAM as example, CC can be supported by IP Ping Toolset using Echo
> > request/reply messages and path discovery can be supported

...I assume that Tom asserts that at least one of these items captured from 7276
is wrong.

Let's look at them one at a time:

"IP OAM is not primarily used for performance measurement"
This statement is not found in section 4.1 (on IP ping) but may be deduced from
that section.
Furthermore the development of OWAMP and TWAMP lead one to deduce that IP ping
was not suitable or performance monitoring.

"RFC7276 Table 4 summarizes the OAM functions that are supported in each of the
OAM toolsets."
I think that fact is beyond dispute.

"Toolset support one or several of these OAM functions including CC, CV, path
discovery, performance measurement, other function."
I think the definition of "toolset" speaks for itself.

"Take IP OAM as example, CC can be supported by IP Ping Toolset using Echo
request/reply messages"
Section 4.1 has:
   As defined in [NetTerms], it is a program
   used to test reachability of destinations by sending them an ICMP
   Echo request and waiting for a reply.
I'm not asserting that RFC1208 is the only document that can describe IP ping,
but it has been unquestioned for a while. 
Section 4.1 goes on:
   The ICMP Echo request/reply exchange in Ping is used as a Continuity
   Check function for the Internet Protocol.  The originator transmits
   an ICMP Echo request packet, and the receiver replies with an Echo
   reply.  ICMP Ping is defined in two variants: [ICMPv4] is used for
   IPv4, and [ICMPv6] is used for IPv6.
2.7 defines CC as:
      Continuity Checks are used to verify that a destination is
      reachable, and are typically sent proactively, though they can be
      invoked on-demand as well.
So the statement looks good.

"and path discovery can be supported by IP Traceroute toolset using Traceroute."
I think that is self-evident!

So what is the issue?

Going back a bit I see Tom said:

>>> Obviously, ping and traceroute are the prime IP-level working tools. But I
>>> wouldn't call ping a matter of Connectivity Check except in the grossest
sense. 

I wonder whether there is confusion about CC and LM.
CC means "is the destination reachable?" It is binary over a relatively short
period.
LM means "how many of my packets get through?" It is qualitative over a longer
period.

So perhaps the debate is about the definition of CC, not about what tools can be
applied to CC or whether 7276 is right in its description of the tools.

I do not think that it will be helpful to debate the definition of some pretty
well established terms related to OAM. If you want to define your own terms,
that will be fine (then others can map them to the existing terms), but trying
to change the meaning of terms that are in use will cause indigestion.

Thanks,
Adrian

---

From: Tom Taylor <[email-masked]>
Date: Sat, 21 Mar 2015 07:32:25 -0400

I do not ask that CC be redefined, though I suggested that it could be. 
The main point I wanted to get across is that IP-level defects are in 
the form of delay and loss, not just unreachability. You need the 
appropriate tools to detect each. Ping can do it all at a gross level. 
OWAMP and TWAMP become necessary when you are trying to get more exact, 
as when you want to verify that you are meeting an SLA.

I'm trying to understand Greg's concerns, so I'm poking a bit. Part of 
the problem, I think, is that RFC 7276 has named two tools and said that 
was the IP OAM toolset. But, focussing on LIME's intentions, if a defect 
is detected on a layer running above an IP transport segment, and the 
problem is at the IP layer, there needs to be a means to detect the 
corresponding IP-layer defect so it can be correlated with the one at 
the higher layer.

Bottom line: I'm saying that the generic LIME model should be able to 
trigger performance monitoring regardless of the layer under examination.

Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 21 Mar 2015 14:36:38 -0000

> trigger performance monitoring regardless of the layer under examination.

Well say "attempt to" because, if the layer doesn't support a particular OAM
function, obviously it won't be triggered.
Similarly, if an implementation is missing that function.

But beyond that, yes, there is a set of generic OAM functions that need to be in
the LIME model for config and enablement.
Since the model is generic and layer-independent, we would assume that the
function set in the LIME model is a superset of the functions in any specific
known layer.

A

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 21 Mar 2015 17:57:49 +0000

Hi Adrian, et. al,
the only identified common OAM function identified so far is ping/traceroute. But this is, primarily, on-demand functions and do not require configuration but are, what is referred, long-running command, which is sort of challenge for Netconf  but not specific to LIME discussion. Configuration of OAM, as I think of it, is primarily for proactive OAM tools, e.g. BFD Async, TWAMP in IP. And that where I find RFC 7276 and attempt to extend TRIL OAM to IP and LDP-based IP/MPLS OAMs come short.

	Regards,
		Greg

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Saturday, March 21, 2015 7:37 AM
To: 'Tom Taylor'; 'Qin Wu'; Gregory Mirsky; 'Ronald Bonica'; [email-masked]
Cc: 'Deepak Kumar (dekumar)'
Subject: RE: [Lime-oam-model] Design Team report

> trigger performance monitoring regardless of the layer under examination.

Well say "attempt to" because, if the layer doesn't support a particular OAM function, obviously it won't be triggered.
Similarly, if an implementation is missing that function.

But beyond that, yes, there is a set of generic OAM functions that need to be in the LIME model for config and enablement.
Since the model is generic and layer-independent, we would assume that the function set in the LIME model is a superset of the functions in any specific known layer.

A

---

From: Qin Wu <[email-masked]>
Date: Sat, 21 Mar 2015 18:40:38 +0000

I think we can support both proactive mode and on demand mode by generalizing ping/traceroute rpc.

-Qin
-----邮件原件-----
发件人: Gregory Mirsky [mailto:[email-masked]] 
发送时间: 2015年3月22日 1:58
收件人: [email-masked]; 'Tom Taylor'; Qin Wu; 'Ronald Bonica'; [email-masked]
抄送: 'Deepak Kumar (dekumar)'
主题: RE: [Lime-oam-model] Design Team report

Hi Adrian, et. al,

	Regards,
		Greg

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Saturday, March 21, 2015 7:37 AM
To: 'Tom Taylor'; 'Qin Wu'; Gregory Mirsky; 'Ronald Bonica'; [email-masked]
Cc: 'Deepak Kumar (dekumar)'
Subject: RE: [Lime-oam-model] Design Team report

A

---

From: Qin Wu <[email-masked]>
Date: Sun, 22 Mar 2015 02:59:43 +0000

When you are saying single hop support, are you  talking about BFD with single hop and multi-hop support?
I think LIME model and BFD model can developed orthogonally. LIME model is developed to provide consistent reporting and representation across layers when there are multi-layer involved while BFD is not necesary.
That is to say, Either Generic BFD model is developed separately from LIME generic model or LIME model extension with BFD technology specific can be developed.
It is up to requirements that need to be met.
For LIME model extension, both single hop and multi-hop can be supported in the model extension.

-Qin
发送时间: 2015年3月21日 0:07

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Ron:

-Qin

Folks,

                            Ron

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

*         to table on p.11:

……..

Regards,
                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 22 Mar 2015 03:07:41 +0000

Hi Qin,
a VPN presents a link on service layer, IP in case of L3VPN. Though there’s BFD single-hop protocol and IP FRR, which is local, i.e. link, protection I don’t think it is worthy to develop IP link OAM model separate from IP network, i.e. multi-hop, OAM model. I believe that link model is special case, perhaps simpler, of more generic multi-hop model. Thus LIME should look at IP network OAM model.

                Regards,
                                Greg

Sent: Saturday, March 21, 2015 8:00 PM

-Qin

Hi Qin,

                Regards,
                                Greg

-Qin

Hi Qin,

                Regards,
                                Greg

Hi, Ron:

-Qin

Folks,

                            Ron

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

Hi Qin,

Hi, Greg:

Hi Qin,

                Regards,
                                Greg

Hi, Greg:

-Qin

Dear Qin,

[Qin]:My pleasure.
Couple notes:

*         to table on p.11:

……..

Regards,
                Greg

---

From: Qin Wu <[email-masked]>
Date: Sun, 22 Mar 2015 16:13:29 +0000

Exactly.

-Qin
-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2015年3月21日 22:37
收件人: 'Tom Taylor'; Qin Wu; 'Gregory Mirsky'; 'Ronald Bonica'; [email-masked]
抄送: 'Deepak Kumar (dekumar)'
主题: RE: [Lime-oam-model] Design Team report

A