Subject: [Lime] schema mount vs augment

From: Qin Wu <[email-masked]>
Date: Thu, 13 Oct 2016 07:39:13 +0000

Hi,
In Tuesday interim meeting this week, one issue we discussed is about how to apply CL model to other technology specific models, two approaches were proposed, the advantage and disadvantages between these two approach are compared:
Augment:
Pro: mature, supported by YANG 1.0,1.1, allow one model is extended to support technology specific
Con: N/A
Schema Mount:
Pro: Allow a set of models to be mounted under nested root
Con: doesn't support specific model to be mounted under a mount point
Doesn't support mount certain model at anywhere in the containment tree
Through the discussion Michale and Balazs raised on the netmod list,
http://www.ietf.org/mail-archive/web/netmod/current/msg15927.html
http://www.ietf.org/mail-archive/web/netmod/current/msg15932.html
http://www.ietf.org/mail-archive/web/netmod/current/msg15933.html

We see a lot of limitations of for the current schema mount, which is pretty much premature, introduces a nested root, support mount base
ietf-yang-library but doesn't support specific model to be mounted under specific mount point.
I heard Greg agreed to use augment instead of schema mount, but he hope to reuse the existing attributes defined in the technology specific models as much as possible.
I think this issue can be addressed by defining more reusable grouping to include these existing attributes in the technology specific model and CL base model reuse these grouping.

-Qin

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Oct 2016 15:45:57 -0700

Hi Qin,
indeed, I don't have strong feelings towards any of methods - augmentation
or mount. We, BFD YANG team, worked with TE Tunnel YANG mode
<https://tools.ietf.org/html/draft-ietf-teas-yang-te-03>l and, Reshad,
please correct if I'm wrong, agreed to augment BFD model in TE LSP. I
believe that since BFD exists in the context of an object, e.g. MPLS-TE LSP
or IP interface, YANG model of OAM for connectionless network would augment
models of these objects and, consequently, BFD YANG model.

Regards, Greg

On Thu, Oct 13, 2016 at 12:39 AM, Qin Wu <[email-masked]> wrote:

> Hi,
>
> In Tuesday interim meeting this week, one issue we discussed is about how
> to apply CL model to other technology specific models, two approaches were
> proposed, the advantage and disadvantages between these two approach are
> compared:
>
> *Augment:*
>
> *Pro: *mature, supported by YANG 1.0,1.1, allow one model is extended to
> support technology specific
>
> *Con:* N/A
>
> *Schema Mount:*
>
> *Pro: *Allow a set of models to be mounted under nested root
>
> *Con:* doesn’t support specific model to be mounted under a mount point
>
> Doesn’t support mount certain model at anywhere in the containment tree
>
> ietf-yang-library but doesn’t support specific model to be mounted under
> specific mount point.
>
> I heard Greg agreed to use augment instead of schema mount, but he hope to
> reuse the existing attributes defined in the technology specific models as
> much as possible.
>
> I think this issue can be addressed by defining more reusable grouping to
> include these existing attributes in the technology specific model and CL
> base model reuse these grouping.
>
>
>
> -Qin
>
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime
>
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 18 Oct 2016 01:50:05 +0000

Hi all,

The BFD YANG model currently augments the MPLS-TE YANG mode, https://tools.ietf.org/html/draft-ietf-bfd-yang-03#section-2.1.4

What we've been discussing in the context of LIME is whether BFD should instead augment/mount a LIME model where all of these objects are defined.

Regards,
Reshad.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 17, 2016 at 6:45 PM
To: Qin Wu <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, Reshad <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Srihari Raghavan (srihari)" <[email-masked]<mailto:[email-masked]>>, "Deepak Kumar (dekumar)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lime] schema mount vs augment

Hi Qin,
indeed, I don't have strong feelings towards any of methods - augmentation or mount. We, BFD YANG team, worked with TE Tunnel YANG mode<https://tools.ietf.org/html/draft-ietf-teas-yang-te-03>l and, Reshad, please correct if I'm wrong, agreed to augment BFD model in TE LSP. I believe that since BFD exists in the context of an object, e.g. MPLS-TE LSP or IP interface, YANG model of OAM for connectionless network would augment models of these objects and, consequently, BFD YANG model.

Regards, Greg

On Thu, Oct 13, 2016 at 12:39 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

-Qin

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

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 17 Oct 2016 19:36:55 -0700

Hi Reshad, et. al,
well, that is definitely not what I've suggested and if that is what the
authors of the LIME CL OAM YANG model propose, then I cannot support that.
I believe that LIME must not define protocol specific data model but
abstract to the level of Test Point and OAM function, i.e.on-demand
connectivity verification, proactive continuity check.

Regards, Greg

On Mon, Oct 17, 2016 at 6:50 PM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Hi all,
>
> The BFD YANG model currently augments the MPLS-TE YANG mode,
> https://tools.ietf.org/html/draft-ietf-bfd-yang-03#section-2.1.4
>
> What we’ve been discussing in the context of LIME is whether BFD should
> instead augment/mount a LIME model where all of these objects are defined.
>
> Regards,
> Reshad.
>
> From: Greg Mirsky <[email-masked]>
> To: Qin Wu <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Mahesh Jethanandani <
> [email-masked]>, Reshad <[email-masked]>, "
> [email-masked]" <[email-masked]>, "Srihari
> Raghavan (srihari)" <[email-masked]>, "Deepak Kumar (dekumar)" <
> [email-masked]>
>> I heard Greg agreed to use augment instead of schema mount, but he hope
>> to reuse the existing attributes defined in the technology specific models
>> as much as possible.
>>

---

From: wangzitao <[email-masked]>
Date: Tue, 18 Oct 2016 03:46:52 +0000

Hi Greg, Reshad and All,

The CL model can provide the common structure and built the relationship of different test points. And I agree to reuse existing attributes.

I believe the rational solution is use both BFD model and "ietf-connectioless-oam" as basis, augment the "ietf-connectionless-oam" model with bfd’s groupings.

Best Regards!
-Michael

发件人: Lime [mailto:[email-masked]] 代表 Reshad Rahman (rrahman)
发送时间: 2016年10月18日 9:50
收件人: Greg Mirsky; Qin Wu
抄送: Mahesh Jethanandani; [email-masked]; Srihari Raghavan (srihari); [email-masked]; Deepak Kumar (dekumar)
主题: Re: [Lime] schema mount vs augment

Hi all,

What we’ve been discussing in the context of LIME is whether BFD should instead augment/mount a LIME model where all of these objects are defined.

Regards,
Reshad.

Hi Qin,

Regards, Greg

Con: doesn’t support specific model to be mounted under a mount point

We see a lot of limitations of for the current schema mount, which is pretty much premature, introduces a nested root, support mount base
ietf-yang-library but doesn’t support specific model to be mounted under specific mount point.
I heard Greg agreed to use augment instead of schema mount, but he hope to reuse the existing attributes defined in the technology specific models as much as possible.
I think this issue can be addressed by defining more reusable grouping to include these existing attributes in the technology specific model and CL base model reuse these grouping.

-Qin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 21 Oct 2016 21:20:40 +0000

Hi all,

I know we've discussed this a few times but let's have a meeting specific to this topic.

10 am eastern (7 am pacific) seems to be the "best" time, I am available Oct 26, 27, 28.

Regards,
Reshad.

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 17, 2016 at 10:36 PM
To: Reshad <[email-masked]<mailto:[email-masked]>>
Cc: Qin Wu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Srihari Raghavan (srihari)" <[email-masked]<mailto:[email-masked]>>, "Deepak Kumar (dekumar)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lime] schema mount vs augment

Hi Reshad, et. al,
well, that is definitely not what I've suggested and if that is what the authors of the LIME CL OAM YANG model propose, then I cannot support that. I believe that LIME must not define protocol specific data model but abstract to the level of Test Point and OAM function, i.e.on-demand connectivity verification, proactive continuity check.

Regards, Greg

On Mon, Oct 17, 2016 at 6:50 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Regards,
Reshad.

Hi Qin,

Regards, Greg

-Qin

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 21 Oct 2016 14:58:21 -0700

Hi Reshad,
great, I'm absolutely for the call. I'm available on any of these days,
time is not a problem.

Regards,
Greg

On Fri, Oct 21, 2016 at 2:20 PM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Hi all,
>
> I know we’ve discussed this a few times but let’s have a meeting specific
> to this topic.
>
> 10 am eastern (7 am pacific) seems to be the “best” time, I am available
> Oct 26, 27, 28.
>
> Regards,
> Reshad.
>
>
> To: Reshad <[email-masked]>
> Cc: Qin Wu <[email-masked]>, "[email-masked]" <[email-masked]>, Mahesh
> Jethanandani <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Srihari Raghavan (srihari)" <
> [email-masked]>, "Deepak Kumar (dekumar)" <[email-masked]>
>
> On Mon, Oct 17, 2016 at 6:50 PM, Reshad Rahman (rrahman) <
> [email-masked]> wrote:
>
>> Hi all,
>>
>> indeed, I don't have strong feelings towards any of methods -
>> augmentation or mount. We, BFD YANG team, worked with TE Tunnel YANG mode
>>> In Tuesday interim meeting this week, one issue we discussed is about
>>> how to apply CL model to other technology specific models, two approaches
>>> were proposed, the advantage and disadvantages between these two approach
>>> are compared:
>>>
>>> *Augment:*
>>>
>>> *Pro: *mature, supported by YANG 1.0,1.1, allow one model is extended
>>> to support technology specific
>>>
>>> *Con:* N/A
>>>
>>> *Schema Mount:*
>>>
>>> I think this issue can be addressed by defining more reusable grouping
>>> to include these existing attributes in the technology specific model and
>>> CL base model reuse these grouping.
>>>
>>>
>>>
>>> -Qin
>>>

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Sat, 22 Oct 2016 02:51:05 +0000

Hi Reshad,

Can you please take a look at section 5 of the draft where Michale added
I will join the meeting as per my outlook availability.

Thanks,
Deepak

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 21, 2016 at 2:58 PM
To: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Cc: Qin Wu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Srihari Raghavan (srihari)" <[email-masked]<mailto:[email-masked]>>, dekumar <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lime] schema mount vs augment

Hi Reshad,
great, I'm absolutely for the call. I'm available on any of these days, time is not a problem.

Regards,
Greg

On Fri, Oct 21, 2016 at 2:20 PM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

I know we’ve discussed this a few times but let’s have a meeting specific to this topic.

10 am eastern (7 am pacific) seems to be the “best” time, I am available Oct 26, 27, 28.

Regards,
Reshad.

Hi Reshad, et. al,

Regards, Greg

Regards,
Reshad.

Hi Qin,

Regards, Greg

-Qin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 26 Oct 2016 14:34:14 +0000

Hi all,

Section 5 shows how BFD or LSP-Ping could augment YANG model. I think the contention is not how we can do this but whether we should do this.

Regards,
Reshad.

From: "Deepak Kumar (dekumar)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 21, 2016 at 10:51 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>, Reshad <[email-masked]<mailto:[email-masked]>>
Cc: Qin Wu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Srihari Raghavan (srihari)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Lime] schema mount vs augment

Hi Reshad,

Thanks,
Deepak

Hi Reshad,

Regards,
Greg

Regards,
Reshad.

Hi Reshad, et. al,

Regards, Greg

Regards,
Reshad.

Hi Qin,

Regards, Greg

-Qin

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 26 Oct 2016 07:57:36 -0700

Hi Reshad,
I agree with your assessment of the current version and that is what I've
commented about during the adoption call of the CL OAM model. I believe
that the model itself must demonstrate how BFD YANG model is related and
instead of referencing BFD-related RFCs have the existing BFD model. Now,
given the decision to split this model, I don't know whether it is helpful
to discuss the current version rather than wait for two new model to be
published. And as we're on the topic of separating configuration and
operational models, shouldn't the same be considered for the
connection-oriented OAM model? Should this be discussed in all groups
working on OAM models, e.g. IPPM, MPLS, BFD?

Regards,
Greg

On Wed, Oct 26, 2016 at 7:34 AM, Reshad Rahman (rrahman) <[email-masked]>
wrote:

> Hi all,
>
> Section 5 shows how BFD or LSP-Ping could augment YANG model. I think the
> contention is not how we can do this but whether we should do this.
>
> Regards,
> Reshad.
>
> From: "Deepak Kumar (dekumar)" <[email-masked]>
> To: Greg Mirsky <[email-masked]>, Reshad <[email-masked]>
> [email-masked]>
> To: "Reshad Rahman (rrahman)" <[email-masked]>
> [email-masked]>, dekumar <[email-masked]>
> On Fri, Oct 21, 2016 at 2:20 PM, Reshad Rahman (rrahman) <
>>> augmentation or mount. We, BFD YANG team, worked with TE Tunnel YANG
>>> mode <https://tools.ietf.org/html/draft-ietf-teas-yang-te-03>l and,
>>> Reshad, please correct if I'm wrong, agreed to augment BFD model in TE LSP.
>>> I believe that since BFD exists in the context of an object, e.g. MPLS-TE
>>> LSP or IP interface, YANG model of OAM for connectionless network would
>>> augment models of these objects and, consequently, BFD YANG model.
>>>
>>> Regards, Greg
>>>

---

From: wangzitao <[email-masked]>
Date: Thu, 27 Oct 2016 03:27:26 +0000

Dear All,

Here I’d like to refer the lime’s charter to demonstrate why we need this common model,
  The absence of a common approach to OAM management has made it difficult for operators to:
  - Suppress large numbers of unnecessary alarms and notifications related to defects and failures arising in lower layers and visible in each higher layer
  - Quickly identify root causes of network failures
  - Coordinate end-to-end performance measurement with the results of performance monitoring at different layers in the network
  - Correlate defects, faults, and network failures between the different layers to improve efficiency of defect and fault localization and provide better OAM visibility.
CL model can provide the common structure and built the relationship with different “test-points”.  It can help user to quickly identify network failures, correlate defects, etc.

In my understanding, the technology specific models (like BFD, etc) can exist as standalone models, and they also can cooperated with lime model to address above questions.
Users can choose to use those technology specific model separately. Or to augment the lime model with technology specific details to support LIME scenarios.

And to avoid redefining those technology specific attributes, we propose to reuse the groupings defining in the technology specific models.
And the solution is demonstrated in the section 5.

Best Regards!
-Michael
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2016年10月26日 22:58
收件人: Reshad Rahman (rrahman)
抄送: Deepak Kumar (dekumar); wangzitao; Qin Wu; [email-masked]; Mahesh Jethanandani; [email-masked]; Srihari Raghavan (srihari)
主题: Re: [Lime] schema mount vs augment

Hi Reshad,
I agree with your assessment of the current version and that is what I've commented about during the adoption call of the CL OAM model. I believe that the model itself must demonstrate how BFD YANG model is related and instead of referencing BFD-related RFCs have the existing BFD model. Now, given the decision to split this model, I don't know whether it is helpful to discuss the current version rather than wait for two new model to be published. And as we're on the topic of separating configuration and operational models, shouldn't the same be considered for the connection-oriented OAM model? Should this be discussed in all groups working on OAM models, e.g. IPPM, MPLS, BFD?

Regards,
Greg

On Wed, Oct 26, 2016 at 7:34 AM, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Regards,
Reshad.

Hi Reshad,

Thanks,
Deepak

Hi Reshad,

Regards,
Greg

Regards,
Reshad.

Hi Reshad, et. al,

Regards, Greg

Regards,
Reshad.

Hi Qin,

Regards, Greg

-Qin

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 26 Oct 2016 21:48:04 -0700

Hi Michael,
some notes:

   - I believe that Alarm Indication Suppression depends not on existence
   of Common OAM model but on establishing relationship between OAM
   layers/levels, support of AIS protocol and coordination of timers among OAM
   layers.
   - "quickly" is not quantitative metric. I think that the OAM models may
   help automate defect localization and characterization which, likely, will
   be faster than human can do it.
   - I think that it is more correlation, not coordination. Yes, using OAM
   models likely to help localize not only faults but congestion spots that
   cause performance degradation.
   - Yes, per above but for that Common OAM model, I believe, should be
   more abstract then what we have today in CO and CL models.

Regards,
Greg

On Wed, Oct 26, 2016 at 8:27 PM, wangzitao <[email-masked]> wrote:

>   - Suppress large numbers of unnecessary alarms and notifications related
> to defects and failures arising in lower layers and visible in each higher
> layer
>
>   - Coordinate end-to-end performance measurement with the results of
> performance monitoring at different layers in the network
>
>   - Correlate defects, faults, and network failures between the different
> layers to improve efficiency of defect and fault localization and provide
> better OAM visibility.
>
> CL model can provide the common structure and built the relationship with
> different “test-points”.  It can help user to quickly identify network
> failures, correlate defects, etc.
>
>
>
> In my understanding, the technology specific models (like BFD, etc) can
> exist as standalone models, and they also can cooperated with lime model to
> address above questions.
>
> Users can choose to use those technology specific model separately. Or to
> augment the lime model with technology specific details to support LIME
> scenarios.
>
>
>
> And to avoid redefining those technology specific attributes, we propose
> to reuse the groupings defining in the technology specific models.
>
> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2016年10月26日 22:58
> *收件人:* Reshad Rahman (rrahman)
> *抄送:* Deepak Kumar (dekumar); wangzitao; Qin Wu; [email-masked]; Mahesh
> Jethanandani; [email-masked]; Srihari Raghavan (srihari)
> *主题:* Re: [Lime] schema mount vs augment
>
>
>
> Hi Reshad,
>
> On Wed, Oct 26, 2016 at 7:34 AM, Reshad Rahman (rrahman) <
> *From: *"Deepak Kumar (dekumar)" <[email-masked]>
> *Date: *Friday, October 21, 2016 at 10:51 PM
> *To: *Greg Mirsky <[email-masked]>, Reshad <[email-masked]>
> *Cc: *Qin Wu <[email-masked]>, "[email-masked]" <[email-masked]>,
> Mahesh Jethanandani <[email-masked]>, "
> Raghavan (srihari)" <[email-masked]>
>
> *Subject: *Re: [Lime] schema mount vs augment
>
>
>
> Hi Reshad,
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Friday, October 21, 2016 at 2:58 PM
> *To: *"Reshad Rahman (rrahman)" <[email-masked]>
> *Cc: *Qin Wu <[email-masked]>, "[email-masked]" <[email-masked]>,
> Mahesh Jethanandani <[email-masked]>, "
> Raghavan (srihari)" <[email-masked]>, dekumar <[email-masked]>
> *Subject: *Re: [Lime] schema mount vs augment
>
>
>
> Hi Reshad,
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, October 17, 2016 at 10:36 PM
> *To: *Reshad <[email-masked]>
> *Cc: *Qin Wu <[email-masked]>, "[email-masked]" <[email-masked]>,
> Mahesh Jethanandani <[email-masked]>, "
> *Subject: *Re: [Lime] schema mount vs augment
>
>
>
> Hi Reshad, et. al,
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Monday, October 17, 2016 at 6:45 PM
> *To: *Qin Wu <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Mahesh Jethanandani <
> *Subject: *Re: [Lime] schema mount vs augment
>
>
>
> Hi Qin,
>