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

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

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: 27 October 2014 00:16
> To: [email-masked]; 'Gregory Mirsky'; 'Loa Andersson'; [email-masked];
Rtg-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Rtg-yang-coord] hopefully a simple question
> 
> 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:
> > 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
> >
> >> -----Original Message-----
> >> 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
> >> -----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.
> >>
> >> 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
> >>
> >> _______________________________________________
> >> Rtg-yang-coord mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >>
> >> _______________________________________________
> >> Rtg-yang-coord mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >

---

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.
> >
I
reinvent. I
> >> 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
> >> From: Rtg-yang-coord [mailto:[email-masked]] On 
> >> Behalf Of Loa Andersson
I'm
> >> draft-tissa-lime-yang-oam-model and the specific models we do for 
> >> different variants of e.g. mpls oam.
> >>

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

---

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-
I
reinvent. I
OAM
I'm

---

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