Re: [Time] YANG models for OAM

Qin Wu <bill.wu@huawei.com> Wed, 09 July 2014 01:28 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: time@ietfa.amsl.com
Delivered-To: time@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E381A01E8; Tue, 8 Jul 2014 18:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level:
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-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 6U2Jd5AeAQnb; Tue, 8 Jul 2014 18:28:02 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67EC01A01E5; Tue, 8 Jul 2014 18:28:00 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJT65169; Wed, 09 Jul 2014 01:27:58 +0000 (GMT)
Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 9 Jul 2014 02:27:55 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.155]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 9 Jul 2014 09:27:52 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>, "time@ietf.org" <time@ietf.org>
Thread-Topic: YANG models for OAM
Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9QABY9lIA=
Date: Wed, 9 Jul 2014 01:27:51 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8458087D@nkgeml501-mbs.china.huawei.com>
References: <FBEA3E19AA24F847BA3AE74E2FE193562EE91CDA@xmb-rcd-x08.cisco.com> <B8F9A780D330094D99AF023C5877DABA84549D17@nkgeml501-mbs.china.huawei.com> <FBEA3E19AA24F847BA3AE74E2FE193562EEC1E8B@xmb-rcd-x08.cisco.com> <B8F9A780D330094D99AF023C5877DABA84580501@nkgeml501-mbs.china.huawei.com> <FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77@xmb-rcd-x08.cisco.com>
In-Reply-To: <FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77@xmb-rcd-x08.cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.180]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8458087Dnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/time/4OCnPZboqoUc3XgiyEmJsPxJuRc
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "'sfc@ietf.org'" <sfc@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, "trill@ietf.org" <trill@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
Subject: Re: [Time] YANG models for OAM
X-BeenThere: time@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Transport Independent OAM in Multi-Layer network Entity \(TIME\) discussion list." <time.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/time>, <mailto:time-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/time/>
List-Post: <mailto:time@ietf.org>
List-Help: <mailto:time-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/time>, <mailto:time-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jul 2014 01:28:11 -0000

Hi, Tissa:
I don’t think the idea you proposed have any inconsistency with what we are proposing in draft-ww-opsawg-multi-layer-oam-02. But looks like we are debating something,:)
You and us are both looking for OAM consolidation in the management, in addition, we are looking for OAM consolidation in the data plane.
Please see my reply inline below.

Regards!
-Qin
发件人: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
发送时间: 2014年7月8日 22:48
收件人: Qin Wu; time@ietf.org
抄送: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; opsawg@ietf.org
主题: RE: YANG models for OAM

Hi Qin

May be a point is missed here.


1.       Thought SFC can go up and down on layers, what controls that behavior ? Is’nt it the Service header ?
[Qin]: It is possible, but who control that behavior, it is the management plane, the management plane need to interact with different layer OAM in the data plane or
Management plane need to interact with OAM protocol that is defined for SFC at the top of layer 3.


2.       Is the OAM comes down to fault isolation, verification , monitoring etc for the specified SH ?
[Qin]: Not clear whether SH is the only approach. OAM information can be put into BDF protocol or Generic TLV as well.

Like discussed before (many times) exact en-cap is less important what is important is to have a model that define OAM framework and scope. CFM to my opinion do an excellent job in defining what is needed. Hence the choice of a similar model for the YANG Model.

[Qin]: We are on the same page, but isn’t more straightforward and reasonable to define Generic OAM framework separated from Yang Data model for Generic OAM.
That’s what we like to propose in the draft-ww-opsawg-multi-layer-oam-02. Developing separate Architecture and Framework from Transport Independent OAM Problem statement draft.
Generic OAM framework should also allow more interaction between data plane and management plane and more interworking between different layer OAM protocol.

You have noted BFD and CFM are similar because they have similar set of timers. That is a wrong comparison. Have similar set of timers does not make two protocols the same.

[Qin]: That’s not what we are proposing, we hope in the management plane there is some common components or elements that can be used by not only BFD, but also CFM.

What makes them is what framework they follows.  We have used key word CFM here loosely. Though we borrow lots of concepts form CFM there are things that needed to be revisited.

I have requested presentation slots in nvo3 and NETMOD working groups and will be going through in details how each one of the technologies map to YANG model presented here.

[Qin]: That would be a very good survey, in my opinion, before going there, isn’t more nice to have a gap analysis document to
a .Identify technology dependent and independent component
b.  analyze and understand the different motivations and opportunities for optimisation of OAM in different technology networks,
and the trade-offs between those optimisations and the overall advantage of a generic OAM mechanism.

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); time@ietf.org<mailto:time@ietf.org>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; trill@ietf.org<mailto:trill@ietf.org>; l2vpn@ietf.org<mailto:l2vpn@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: YANG models for OAM

Hi, Tissa:
There are many options for SFC OAM, BFD extension, Generic Header extension, Generic TLV extension.
Unlike other existing OAM protocols, mechanisms and tools, SFC need to address OAM for the technology that is above layer 3.
SFC haven’t developed OAM protocol yet at the top of layer 3.

Before they developing OAM protocol, they need to figure out whether they need to develop technology dependent OAM protocol,
Or technology independent OAM protocol since SFC OAM and Overlay OAM share a lot of similarities(e.g., both can use overlay technology to stitch a set of overlay node or service node to form the end to end path). Why not build one protocol to support both?

That’s why we bring up transport independent OAM covering various heterogeneous network technologies and propose to consolidate OAM in both
Management plane and data plane.
http://tools.ietf.org/html/draft-ww-opsawg-multi-layer-oam-02
http://tools.ietf.org/html/draft-king-opsawg-time-multi-layer-oam-use-case-01.txt

Regarding flow-entropy, why not reuse entropy mechanisms in the existing underlying transport. How is flow entropy different from ECMP choice you proposed in the draft.
If my understanding is correct, IEEE 802.1ag only support Equal Cost Tree (ECT) mechanism instead of ECMP, IEEE802.1Qbp support ECMP,
Are you proposing to combine ECT supported by IEEE 802.1ag with ECMP supported by IEEE 802.1Qbp and use them together at the same time in the same network?

Also BFD and IEEE 802.1ag CFM share a lot of commonality, e.g., CCM-interval, BFD interval. If we integrate them together, we really need to think about how to integrate them together in the management plane. Is there any common component we can define for both? How we define these component and make them more extensible.

Regards!
-Qin
发件人: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com]
发送时间: 2014年6月30日 0:20
收件人: Qin Wu; time@ietf.org<mailto:time@ietf.org>
抄送: netmod@ietf.org<mailto:netmod@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; trill@ietf.org<mailto:trill@ietf.org>; l2vpn@ietf.org<mailto:l2vpn@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: RE: YANG models for OAM

Hi Qin

There are several way this is applicable to SFC


1.       SFC is underlayer independent , which means it can have all sorts of encap types underneath, the model presented in tissa-netmod-oam, address exactly that issue. Instead of re-inventing and re-implementing various different OAM the draft propose to integrate them at the management layer.

2.       In this draft we define a flow-entropy as an opaque element that each of the technology type can specify and include. If we look at draft-quinn-sfc-nsh-02.txt, it define a block that specifies SFC. SFC version of YANG  can specify this as part of its flow entropy. The beauty is that it is all up to the technology to specify that (size and shape is technology dependent) and base model is still intact.

With the above in mind , can you please review draft-tissa-netmod-oam and see it is flexible and extensible enough to for the purpose. If things are missing we can add and extend.

I have requested netmod WG chairs for a presentation slot for further discussion of the draft.

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, June 10, 2014 9:22 PM
To: Tissa Senevirathne (tsenevir); time@ietf.org<mailto:time@ietf.org>
Cc: netmod@ietf.org<mailto:netmod@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; trill@ietf.org<mailto:trill@ietf.org>; l2vpn@ietf.org<mailto:l2vpn@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>
Subject: RE: YANG models for OAM

Hi, Tissa:
Thanks for initiating discussion on this topic.
Unified OAM for multi-Layer network is a good idea to me.
draft-ww-opsawg-multi-layer-oam-00 we proposed in opsawg laid out the an initial description of the problem.
The question to draft-tissa-netmod-oam is
I am wondering how this generic Yang Model can be applied to SFC environment?
How do you support the case where two endpoints support different layer OAM or doesn’t support any OAM at that layer.

BTW: I have cc’ed time mailing list since I believe this mailing list is purposed to look for generic and integrated OAM covering various heterogeneous networking technologies.
Regards!
-Qin
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Tissa Senevirathne (tsenevir)
发送时间: 2014年6月11日 3:03
收件人: netmod@ietf.org<mailto:netmod@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; trill@ietf.org<mailto:trill@ietf.org>; l2vpn@ietf.org<mailto:l2vpn@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>
主题: [netmod] YANG models for OAM

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