Subject: [Rtg-yang-coord] hopefully a simple question

From: Loa Andersson <[email-masked]>
Date: Sun, 26 Oct 2014 11:14:29 +0100

Folks,

I have what I hope is a simple question, and that it will only reveal
that I'm not up to speed on yang.

I trying to figure out the relationship between the generic yang models
in e.g. draft-tissa-lime-yang-oam-model and the specific models we do
for different variants of e.g. mpls oam.

I guess we have a structure more or less like this

mpls
  |
  |- ldp
  |   |-ldp oam
  |
  |- rsvp-te
  |   |
  |   |- rsvp-te oam
  |
  |- lsp ping
  |   |
  |   |- lsp ping oam
  |
  |- etc

Where does the generic work fit in?

/Loa
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Gregory Mirsky <[email-masked]>
Date: Sun, 26 Oct 2014 18:50:32 +0000

Hi Loa,
I think that your question is not simple at all and it would be a great to discuss how Generic OAM proposal is related to MPLS OAM at the meeting.
Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing networks.

	Regards,
		Greg
-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Sunday, October 26, 2014 3:14 AM
To: [email-masked]; [email-masked]
Subject: [Rtg-yang-coord] hopefully a simple question

Folks,

I have what I hope is a simple question, and that it will only reveal that I'm not up to speed on yang.

I trying to figure out the relationship between the generic yang models in e.g. draft-tissa-lime-yang-oam-model and the specific models we do for different variants of e.g. mpls oam.

mpls
  |
  |- ldp
  |   |-ldp oam
  |
  |- rsvp-te
  |   |
  |   |- rsvp-te oam
  |
  |- lsp ping
  |   |
  |   |- lsp ping oam
  |
  |- etc

/Loa
-- 

_______________________________________________
Rtg-yang-coord mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Oct 2014 00:03:20 -0000

The intention of LIME (who knows whether it is achievable?) is to produce a
single YANG module that provides a generic way in to OAM across all IETF
technologies. 

There are certainly a number of core concepts, configurable items, and
reportable things that can be stated in a technology independent way.

LIME has as a deliverable a set of applicability statements showing how the
generic module is applied to different IETF OAM technologies.

I should not be surprised if technology-specific modules are also required. I
think LIME hopes that these will build on the generic module and not reinvent. I
assume this will be through augmentation. And I assume the work will be done by
the WGs that own the technologies (where those WGs exist).

I don't think I understand your tree. Why would "RSVP-TE OAM" live under rsvp-te
under mpls? The OAM is going to be standard mpls oam, but the concepts (MIPs,
MEPs, on/off, failure found, etc.) are general.

Adrian

> From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
> Gregory Mirsky
> Sent: 26 October 2014 18:51
> To: Loa Andersson; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Rtg-yang-coord] hopefully a simple question
> 
> Hi Loa,
> I think that your question is not simple at all and it would be a great to
discuss
> how Generic OAM proposal is related to MPLS OAM at the meeting.
> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, Segment
> Routing (as far as transport layer for the latter two) OAMs but one MPLS OAM
> with extensions/special cases for IP/MPLS, MPLS-TP and Segment Routing
> networks.
> 
> 	Regards,
> 		Greg
> I have what I hope is a simple question, and that it will only reveal that I'm
not up
> to speed on yang.
> 
> I trying to figure out the relationship between the generic yang models in
e.g.
> draft-tissa-lime-yang-oam-model and the specific models we do for different
> variants of e.g. mpls oam.
>

---

From: Tom Taylor <[email-masked]>
Date: Sun, 26 Oct 2014 20:15:38 -0400

This might be a good time to remind/alert people about the liaison 
statement received from the MEF regarding 
draft-tissa-lime-yang-oam-model.  It can be found at

https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef-netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf

  Tom Taylor

On 26/10/2014 8:03 PM, Adrian Farrel wrote:
>> Loa Andersson

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Oct 2014 00:34:15 -0000

[Adding Netmod, but removing MPLS]

A good pointer, Tom, thanks.

The liaison seems to request review and feedback, but I don't see a response
from Netmod and it looks like the MEF Technical Committee is meeting today and
in the next few days. 

I think that if LIME had existed at the time the liaison arrived, it is probable
that it would also have been a recipient. 

We should certainly strive to work with MEF and build on existing work.

Adrian

> From: Tom Taylor [mailto:[email-masked]]
> Sent: 27 October 2014 00:16
> To: [email-masked]; 'Gregory Mirsky'; 'Loa Andersson'; [email-masked];
Rtg-
> [email-masked]
> https://datatracker.ietf.org/documents/LIAISON/liaison-2014-07-31-mef-
> netmod-liaison-to-ietf-on-yang-service-oam-models-attachment-1.pdf
> 
>   Tom Taylor
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 27 Oct 2014 01:52:21 +0000

It is strange to subsume LDP OAM and RSVP-te OAM under MPLS OAM.
LDP OAM and RSVP-te OAM are not data plane OAM tools, rather than they are control plane maintenance tools.
When we talk about MPLS OAM , it is usually referred to data plane tools, i.e., LSP Ping OAM.
RFC7276 provides a good summarization for various OAM tools.

Secondly, I think if there are some sub-technologies that are under MPLS OAM, technology sub-types can augment
the base model with both technology type specifics and technology sub-type specifics,
i.e., use identity technology-types defined in the base model and technology sub type defined in the technology specific model
to identify specific sub- technology type within specific technology type.

Regards!
-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2014年10月26日 18:14
收件人: [email-masked]; [email-masked]
主题: [Lime] hopefully a simple question

Folks,

mpls
  |
  |- ldp
  |   |-ldp oam
  |
  |- rsvp-te
  |   |
  |   |- rsvp-te oam
  |
  |- lsp ping
  |   |
  |   |- lsp ping oam
  |
  |- etc

/Loa
-- 

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

---

From: Qin Wu <[email-masked]>
Date: Mon, 27 Oct 2014 02:13:31 +0000

Another liaison statement sent to IETF OPSarea on April 2014 before LIME is formed
https://datatracker.ietf.org/documents/LIAISON/liaison-2014-04-23-itu-t-sg-15-ops-ls-on-new-work-item-on-generic-information-model-for-management-of-transport-ne-attachment-1.pdf
It is related to ITU-T G.gim: generic protocol-neutral information model for transport network management.
Although it is not directly related to YANG data model work we are focusing on, I think we also need to consider this existing work.

Regards!
-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Adrian Farrel
发送时间: 2014年10月27日 8:34
收件人: 'Tom Taylor'
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Re: [Lime] [Rtg-yang-coord] hopefully a simple question

The liaison seems to request review and feedback, but I don't see a response from Netmod and it looks like the MEF Technical Committee is meeting today and in the next few days. 

I think that if LIME had existed at the time the liaison arrived, it is probable that it would also have been a recipient. 

Adrian

Rtg-
> > The intention of LIME (who knows whether it is achievable?) is to 
> > produce a single YANG module that provides a generic way in to OAM 
> > across all IETF technologies.
> >
> > There are certainly a number of core concepts, configurable items, 
> > and reportable things that can be stated in a technology independent way.
> >
> > LIME has as a deliverable a set of applicability statements showing 
> > how the generic module is applied to different IETF OAM technologies.
> >
> > assume this will be through augmentation. And I assume the work will 
> > be done
> by
> > I don't think I understand your tree. Why would "RSVP-TE OAM" live 
> > under
> rsvp-te
> > under mpls? The OAM is going to be standard mpls oam, but the 
> > concepts
> (MIPs,
> >> From: Rtg-yang-coord [mailto:[email-masked]] On 
> >> Behalf Of Gregory Mirsky
> >> Personally, I think that there's no separate LDP, RSVP-TE or EVPN, 
> >> Segment Routing (as far as transport layer for the latter two) OAMs 
> >> but one MPLS
OAM
> >> with extensions/special cases for IP/MPLS, MPLS-TP and Segment 
> >> Routing networks.
> >>
> >> 	Regards,
> >> 		Greg
> >> I have what I hope is a simple question, and that it will only 
> >> reveal that
I'm
> >> draft-tissa-lime-yang-oam-model and the specific models we do for 
> >> different variants of e.g. mpls oam.
> >>

---

From: Qin Wu <[email-masked]>
Date: Mon, 27 Oct 2014 03:41:22 +0000

-----邮件原件-----
发件人: Tissa Senevirathne (tsenevir) [mailto:[email-masked]] 
发送时间: 2014年10月27日 11:01
收件人: Qin Wu; Loa Andersson; [email-masked]; [email-masked]
主题: RE: [Lime] hopefully a simple question

Thanks Qin for the spot on detail reply, 

Loa et.al 

Let me add on to what Qin stated. We need to approach this in top down manner. At the top of the layer is the base YANG model (aka Gen YANG)

What is presented in Tissa-yang is the fault management model, that is independent of the underlying OAM protocols. In designing the model we have used power of YANG so that every element is augmentable. 

[Qin]: Just want to stress the element is referred to every element inserted in the module hierarchy defined in RFC6020,not element or node in the tree mentioned below.
The tree mentioned below comprises a lot of nodes including root node, branch node, leaf node. Each node in this tree is data model, irrespective of whether it is
technology specific and technology independent.

E.g. instead of enums we use identiyrefs, instead of typedefs where applicable we use combination of choice/case statement. 

The idea is every branch in the data model is extensible.

[Qin]: Exactly, in a tree with root node, branch nodes and leaf nodes, all the branch nodes should only have one root node, if one node in the tree is extensible, this node MUST be a root node or a branch node. If the one node is not extensible, this node MUST be a leaf node.
Therefore technology specific data model can also be extensible as long as it is branch node in the tree.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 27 Oct 2014 08:43:35 -0400

> On Oct 26, 2014:8:34 PM, at 8:34 PM, Adrian Farrel <[email-masked]> wrote:
> 

	We have a draft response that we crafted and posted to the mailing list, but it seems never was sent out. I will post now to the list to see if there are any more comments.

> that it would also have been a recipient. 

	Should NETMOD respond since it was addressed to us or will LIME respond?

	--Tom

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 27 Oct 2014 03:00:48 +0000

Loa et.al 

What is presented in Tissa-yang is the fault management model, that is independent of the underlying OAM protocols. In designing the model we have used power of YANG so that every element is augmentable. E.g. instead of enums we use identiyrefs, instead of typedefs where applicable we use combination of choice/case statement. The idea is every branch in the data model is extensible.

Second layer is how this can be extended to other technologies. Ex. Are 
https://tools.ietf.org/html/draft-tissa-trill-yang-oam   
https://tools.ietf.org/html/draft-tissa-nvo3-yang-oam-00-00

The model proposed is equally applicable to RFC 4379 "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"

You have referred to MPLS LDP OAM, rsvp-te-oam and so on. These sound more of control plane aspects. Are there any publications that present MPLS LDP OAM, rsvp-te OAM, would like to take a look before comment.

Our objective here in Tissa-yang; is to create a YANG model that that covers existing OAM, and data model to be extensible for future extensions.

One of the key charter elements of LIME is to come up with Guidelines for OAM designers.  This is to guide future OAM designers to consider/compliant with the umbrella YANG model. 

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Sunday, October 26, 2014 6:52 PM
To: Loa Andersson; [email-masked]; [email-masked]
Subject: Re: [Lime] hopefully a simple question

Secondly, I think if there are some sub-technologies that are under MPLS OAM, technology sub-types can augment the base model with both technology type specifics and technology sub-type specifics, i.e., use identity technology-types defined in the base model and technology sub type defined in the technology specific model to identify specific sub- technology type within specific technology type.

Regards!
-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Loa Andersson
发送时间: 2014年10月26日 18:14
收件人: [email-masked]; [email-masked]
主题: [Lime] hopefully a simple question

Folks,

mpls
  |
  |- ldp
  |   |-ldp oam
  |
  |- rsvp-te
  |   |
  |   |- rsvp-te oam
  |
  |- lsp ping
  |   |
  |   |- lsp ping oam
  |
  |- etc

/Loa
--

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Mon, 27 Oct 2014 04:13:14 +0000

Thanks Adrian.

It is good to see MEF is interested,  both MEF and what is presented are using the same root model.

However, what is presented in Tissa-yang differs in,
1. It is not tied to Ethernet
2. All of the YANG structures have been revised to be augmentable

So, two YANG models are no longer identical, except they share the same root model.

When doing TRILL OAM we did a Liaison with IEEE 8021 committee and it was extremely productive and I am sure it will be like that with  Liaison with the MEF.

-----Original Message-----
From: Lime [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Sunday, October 26, 2014 5:34 PM
To: 'Tom Taylor'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lime] [Rtg-yang-coord] hopefully a simple question

Adrian

Rtg-
OAM
> >> Behalf Of Loa Andersson
I'm