RE: [nvo3] YANG models for OAM

"O'Connor, Don" <don.oconnor@us.fujitsu.com> Fri, 01 August 2014 20:08 UTC

Return-Path: <don.oconnor@us.fujitsu.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFA71ABC74; Fri, 1 Aug 2014 13:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7eXYO4DbZTr; Fri, 1 Aug 2014 13:08:24 -0700 (PDT)
Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F201A0467; Fri, 1 Aug 2014 13:08:23 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.01,781,1400043600"; d="scan'208,217"; a="52769688"
Received: from rchexhcp1.fnc.net.local ([168.127.134.75]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 01 Aug 2014 15:08:23 -0500
Received: from RCHEXMBP1.fnc.net.local ([169.254.2.63]) by RCHEXHCP1.fnc.net.local ([168.127.134.75]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 15:08:22 -0500
From: "O'Connor, Don" <don.oconnor@us.fujitsu.com>
To: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>, Tissa Senevirathne <tissasenevirathne@yahoo.com>, Greg Mirsky <gregimirsky@gmail.com>
Subject: RE: [nvo3] YANG models for OAM
Thread-Topic: [nvo3] YANG models for OAM
Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAoWIbcAAAE6agAACU5iwAAR6gcAAAadH3A=
Date: Fri, 1 Aug 2014 20:08:22 +0000
Message-ID: <7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6@RCHEXMBP1.fnc.net.local>
References: <FBEA3E19AA24F847BA3AE74E2FE193562EE91CDA@xmb-rcd-x08.cisco.com> <CA+RyBmVyzyL5XQezXU+EaGLRGieDmzvgnkZVWqNGxB5b7jPZnQ@mail.gmail.com> <1406847186.16320.YahooMailNeo@web162805.mail.bf1.yahoo.com> <7DFA7869D33BD44A9A84BA24AD75BDE6D9E4645D@RCHEXMBP1.fnc.net.local> <FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1B@xmb-rcd-x08.cisco.com>
In-Reply-To: <FBEA3E19AA24F847BA3AE74E2FE193562EEE0F1B@xmb-rcd-x08.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [168.127.136.253]
x-tm-as-product-ver: SMEX-10.2.0.3176-7.500.1018-20854.002
x-tm-as-result: No--51.982500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7DFA7869D33BD44A9A84BA24AD75BDE6D9E46AA6RCHEXMBP1fncnet_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/mwBhuLdPykGfy-bAnojSeanU2fM
X-Mailman-Approved-At: Mon, 04 Aug 2014 01:58:51 -0700
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "trill@ietf.org" <trill@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 20:08:27 -0000

Tissa

The MEF standards apply to the Ethernet Service Layer of Carrier Ethernet Services. Are the IDs in your email constrained to layers below the Ethernet Service Layer for Carrier Ethernet Service? Or are they not applicable to Carrier Ethernet Service?

Regards

Don

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Thursday, July 31, 2014 6:49 PM
To: O'Connor, Don; Tissa Senevirathne; Greg Mirsky
Cc: l2vpn@ietf.org; opsawg@ietf.org; nvo3@ietf.org; netmod@ietf.org; trill@ietf.org
Subject: RE: [nvo3] YANG models for OAM

Don

I am aware of that, but this is different, MEF YANG model is specifically for Ethernet and structure does not allow to bring different addressing schemes other than MAC address. Additionally the proposed standard allow to add flow entropies and facilitate nested OAM between different technologies. You may have to read in to the details to see the actual differences.

From: O'Connor, Don [mailto:don.oconnor@us.fujitsu.com]
Sent: Thursday, July 31, 2014 4:32 PM
To: Tissa Senevirathne; Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org<mailto:l2vpn@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; netmod@ietf.org<mailto:netmod@ietf.org>; trill@ietf.org<mailto:trill@ietf.org>
Subject: RE: [nvo3] YANG models for OAM

Tissa, Greg, all

Metro Ethernet Forum has already standardized Yang Modules for Ethernet Service OAM Performance Monitoring and Fault Management. Please see MEF 38 and 39

http://metroethernetforum.org/carrier-ethernet/technical-specifications

Regards

Don

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Tissa Senevirathne
Sent: Thursday, July 31, 2014 5:53 PM
To: Greg Mirsky; Tissa Senevirathne (tsenevir)
Cc: l2vpn@ietf.org<mailto:l2vpn@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; netmod@ietf.org<mailto:netmod@ietf.org>; trill@ietf.org<mailto:trill@ietf.org>
Subject: Re: [nvo3] YANG models for OAM

Greg

Yes it is, generic YANG model steup the base framework. It can be extended to add tools as well as other elements as well technology deviations. Alarms etc either be part of this document will be a separate document that specifies them. That is the reason we have designed the model as modular as possible and extensible as possible.

Please let us know if any of the parts are not extensible or not modular enough.

Thanks
Tissa

On Thursday, July 31, 2014 3:17 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Tissa, authors, et. al,
I've read documents and would like to clarify scope of these documents. OAM is not limited to ping and traceroute functions. It even not limited to continuity check. And in connectionless networks there would not be connectivity verification. And the performance measurement is the big part of OAM as well as protection coordination, defect alarms, and etc. Hence my question, is it in plans of the authors to address all of OAM in respective documents?
Regards,
Greg

On Tue, Jun 10, 2014 at 12:03 PM, Tissa Senevirathne (tsenevir) <tsenevir@cisco.com<mailto:tsenevir@cisco.com>> wrote:
All

We have published YANG model for OAM. #1 draft below place the generic framework for OAM, that can be augmented for different technologies. #2 and #3 are application of the concept to NVO3 and TRILL,

1.      http://datatracker.ietf.org/doc/draft-tissa-netmod-oam/
2.      http://datatracker.ietf.org/doc/draft-tissa-nvo3-yang-oam/
3.      http://datatracker.ietf.org/doc/draft-tissa-trill-yang-oam/

Please review and share your comments

Thanks
Tissa



_______________________________________________
nvo3 mailing list
nvo3@ietf.org<mailto:nvo3@ietf.org>
https://www.ietf.org/mailman/listinfo/nvo3