Re: [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

Huub van Helvoort <huubatwork@gmail.com> Mon, 07 January 2013 21:35 UTC

Return-Path: <huubatwork@gmail.com>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607BA21F88F5; Mon, 7 Jan 2013 13:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhm4V6JzJx-z; Mon, 7 Jan 2013 13:35:27 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D03B521F872E; Mon, 7 Jan 2013 13:35:26 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id r3so10734202wey.3 for <multiple recipients>; Mon, 07 Jan 2013 13:35:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pNezEYCkc6lw8sgzwQ/6zusZaaHO4Dnm0p4uIs9Kg5w=; b=o/J1Q1qodV8FRkpNMzdbbhQLHNFEjN6Z7R1x4B8+6QX3SJP7UnuYCzjltOtzkRPDSg xemFyWSjglab+LKboN8X7LPjUs/+044MznXRZJkuKJyFTD7idezrX+a0s8BYkD/f2TUY 4NLEbvWWS10musqkekOd3y4MzRIcmHsZb9n3Ls3iDZtnZq/rD/evmScfWvUkB6LG02Kj UtIssGZWsnTEkHZkWmmiYw9yq/xFUJ4AQb4iwDo+GYLvxfWgONSvOZUD3cHfPeBSCSHn g1lizPnh9pspgWtqwEd+ynWOEhMuCiX3kODngG/4n8wZjOjQlC713u2P/SOC5l+IZC42 qzhw==
X-Received: by 10.180.93.133 with SMTP id cu5mr11354095wib.32.1357594525855; Mon, 07 Jan 2013 13:35:25 -0800 (PST)
Received: from McAsterix.local (dhcp-077-250-051-060.chello.nl. [77.250.51.60]) by mx.google.com with ESMTPS id p2sm15582525wic.7.2013.01.07.13.35.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Jan 2013 13:35:25 -0800 (PST)
Message-ID: <50EB3F9C.7010605@gmail.com>
Date: Mon, 07 Jan 2013 22:35:24 +0100
From: Huub van Helvoort <huubatwork@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Greg Mirsky <gregimirsky@gmail.com>
References: <CD08F2D5.6DC40%nabil.n.bitar@verizon.com> <CD0C3AE6.6E673%nabil.n.bitar@verizon.com> <CA+RyBmWWUQ+y7Mc1nG3+KndXCytfUkQqnNTg4ezpK2JcGyiCuQ@mail.gmail.com>
In-Reply-To: <CA+RyBmWWUQ+y7Mc1nG3+KndXCytfUkQqnNTg4ezpK2JcGyiCuQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "pwe3@ietf.org" <pwe3@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "dinmohan@hotmail.com" <dinmohan@hotmail.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: huubatwork@gmail.com
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2013 21:35:28 -0000

Hello Nabil,

Greg is almost right.

RDI == Remote Defect Indication

This is the abbreviation used in IEEE 802.1ag, Y.1731, G.707, G.8121
and rfc6428.

Regards, Huub.
====

> can we avoid different interpretation of the same abbreviation (RDI):
>
> RDI   Remote Defect Indication for Continuity Check Message
>
> RDI   Reverse Defect Indication
>
> AFAIK, the latter form is the interpretation used by both IEEE 802.1ag
> and Y.1731. How useful is the first form?
>
> Regards,
>
> Greg
>
>
>
> On Fri, Jan 4, 2013 at 8:17 AM, Bitar, Nabil N
> <nabil.n.bitar@verizon.com <mailto:nabil.n.bitar@verizon.com>> wrote:
>
>     Hi Dave,
>     Related to abbreviations comment below and to be clearer, I renamed
>     the original terminology section to "Abbreviations and Terminology".
>     I also created a subsection called "Abbreviations" ,and
>     "Terminology" became the second subsection.  Here iis how the edits look
>
>
>       3. Abbreviations and Terminology____
>
>
>         3.1. Abbreviations____
>
>     AISAlarm Indication Signal____
>
>     ACAttachment Circuit____
>
>     BFDBidirectional Forwarding Detection____
>
>     CCContinuity Check____
>
>     CCMContinuity Check Message____
>
>     CECustomer Equipment____
>
>     CVConnectivity Verification____
>
>     E-LMI Ethernet Local Management Interface____
>
>     EVCEthernet Virtual Circuit____
>
>     LDPLabel Distribution Protocol____
>
>     LoSLoss of Signal____
>
>     MAMaintenance Association____
>
>     MDMaintenance Domain____
>
>     MEMaintenance Entity____
>
>     MEGMaintenance Entity Group____
>
>     MEPMaintenance End Point____
>
>     MIPMaintenance End Point____
>
>     MPLSMultiprotocol Label Switching____
>
>     MS-PW Multi-Segment Pseudowire____
>
>     NSNative Service____
>
>     OAMOperations, Administration, and Maintenance____
>
>     PEProvider Edge____
>
>     PSNPacket Switched Network____
>
>     PWPseudowire____
>
>     RDIRemote Defect Indication for Continuity Check Message____
>
>         RDI   Reverse Defect Indication
>
>     S-PESwitching Provider Edge____
>
>     TLVType Length Value____
>
>     T-PETerminating Provider Edge____
>
>     __ __
>
>
>         3.2. Terminology____
>
>     This document uses the following terms with corresponding
>     definitions: ____
>
>     - MD Level:Maintenance Domain (MD) Level which identifies a value in
>     the range of 0-7 associated with Ethernet OAM frame. MD Level
>     identifies the span of the Ethernet OAM frame.____
>
>     - MEP:Maintenance End Point is responsible for origination and
>     termination of OAM frames for a given MEG.____
>
>     - MIP: Maintenance Intermediate Point is located between peer MEPs
>     and can process OAM frames but does not initiate or terminate them.____
>
>     Further, this document also uses the terminology and conventions
>     used in [RFC6310].____
>
>
>
>     Thanks,
>
>     Nabil