[OPSAWG] draft-mizrahi-opsawg-oam-overview-00

Ron Bonica <rbonica@juniper.net> Tue, 20 October 2009 19:24 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: opsawg@core3.amsl.com
Delivered-To: opsawg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D593928C138 for <opsawg@core3.amsl.com>; Tue, 20 Oct 2009 12:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5hLPYl8d2aq for <opsawg@core3.amsl.com>; Tue, 20 Oct 2009 12:24:43 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id D51613A68D0 for <opsawg@ietf.org>; Tue, 20 Oct 2009 12:24:39 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSt4Of36jdaYkGafTH8EmLjttKY7+aZQ8@postini.com; Tue, 20 Oct 2009 12:24:51 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Oct 2009 12:24:28 -0700
Received: from [172.28.134.12] (172.28.134.12) by p-emfe01-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Oct 2009 15:24:27 -0400
Message-ID: <4ADE0E6A.1030206@juniper.net>
Date: Tue, 20 Oct 2009 15:24:26 -0400
From: Ron Bonica <rbonica@juniper.net>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: "opsawg@ietf.org" <opsawg@ietf.org>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [OPSAWG] draft-mizrahi-opsawg-oam-overview-00
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2009 19:24:44 -0000

Tal,

What is the intent of this document? If it is merely to exchange
information between SDO's, that's fine. However, I think that you could
take this document a step further. You could use this document to frame
a conversation about which OAM capabilities the IETF should develop and
which they should avoid.

For example, in Section 3.2.4, you distinguish between a failure, a
fault and a defect. In a connection oriented-environment, like SONET,
where bandwidth is reserved even when it is not being used, it makes
sense to manage all three. It also makes sense for the OAM mechanism to
be built into the protocol, as they are in SONET.

However, it is possible that neither assumption is true for
statistically multiplexed, connectionless environments like IP or
Ethernet. If you want to broaden the scope of your document, you might
want to explore these issues.

                                  Ron
                                 /speaking as individual contributor




>
> 	Title           : An Overview of Operations,
> Administration, and Maintenance (OAM) Mechanisms
> 	Author(s)       : T. Mizrahi
> 	Filename        : draft-mizrahi-opsawg-oam-overview-00.txt
> 	Pages           : 22
> 	Date            : 2009-10-07
>
> Operations, Administration, and Maintenance (OAM) is a general term
> that refers to detecting and reporting link failures. OAM mechanisms
> have been defined for various layers in the protocol stack, and are
> used with a variety of protocols.
>
> This document presents an overview of the OAM mechanisms that have
> been defined and are currently being defined by the IETF, as well as
> a comparison to other OAM mechanisms that have been defined by the
> IEEE and ITU-T.