Re: [trill] YANG models for OAM

"Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com> Tue, 08 July 2014 14:48 UTC

Return-Path: <tsenevir@cisco.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9669E1B27B8; Tue, 8 Jul 2014 07:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.701
X-Spam-Level:
X-Spam-Status: No, score=-12.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 iYJXTFhfQFjo; Tue, 8 Jul 2014 07:48:02 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8F81A00F6; Tue, 8 Jul 2014 07:48:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33809; q=dns/txt; s=iport; t=1404830882; x=1406040482; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wLLnbtwHFbNeNu8dAqZU3DU1LBL/llCAAIZiu3LDLp0=; b=DNJRx3PeHQAnf5xOBERyaC9J4Hga7Fat1wcP/Bp04Hy4tZ4v8Nb2Mc0F hY5D1WAMIPrL0SgVyUWwzigw45y5KJ36XCRGJ+bzrVDmwcMatgjL3IoHk vkwo7Y+12e4WsFF98+N49G42BjcT4bfqBNvipnjmdK+Fe0JYrUSh6N2Bw s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtIHAMEDvFOtJV2a/2dsb2JhbABZgkdHUlqCb6wojhGBYIc/ARl8FnWEAwEBAQQtQQsQAgEGAg4DBAEBCxYBBgUCAjAUCQgBAQQBDQUIiDoNk1ScIQiZNxePERYbBgGCczqBFgWcPpJEg0NsgUQ
X-IronPort-AV: E=Sophos; i="5.01,625,1400025600"; d="scan'208,217"; a="59153805"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 08 Jul 2014 14:48:01 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s68Em0P1009340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Jul 2014 14:48:00 GMT
Received: from xmb-rcd-x08.cisco.com ([169.254.8.36]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 8 Jul 2014 09:48:00 -0500
From: "Tissa Senevirathne (tsenevir)" <tsenevir@cisco.com>
To: Qin Wu <bill.wu@huawei.com>, "time@ietf.org" <time@ietf.org>
Thread-Topic: YANG models for OAM
Thread-Index: Ac+E3qlMyPi638vnRGmjYh75Wx+edAATLCxAA6JRP1ABuzlT8AAF7c9Q
Date: Tue, 08 Jul 2014 14:47:59 +0000
Message-ID: <FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77@xmb-rcd-x08.cisco.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>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA84580501@nkgeml501-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.119.34]
Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EEC5C77xmbrcdx08ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/TIRSB3gCseSX4iucv6iQsr8-aws
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>
Subject: Re: [trill] YANG models for OAM
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jul 2014 14:48:05 -0000

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 ?

2.      Is the OAM comes down to fault isolation, verification , monitoring etc for the specified SH ?

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.

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. 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.

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, July 08, 2014 5:07 AM
To: Tissa Senevirathne (tsenevir); time@ietf.org
Cc: netmod@ietf.org; nvo3@ietf.org; trill@ietf.org; l2vpn@ietf.org; 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