[secdir] secdir review of draft-ietf-mpls-tp-oam-analysis-08

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Sat, 24 March 2012 06:12 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555FC21F867B for <secdir@ietfa.amsl.com>; Fri, 23 Mar 2012 23:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Level:
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjPvIZUkRlIy for <secdir@ietfa.amsl.com>; Fri, 23 Mar 2012 23:12:13 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A307321F85CE for <secdir@ietf.org>; Fri, 23 Mar 2012 23:12:13 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEQ65725; Sat, 24 Mar 2012 02:12:13 -0400 (EDT)
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 23:11:02 -0700
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 23:10:59 -0700
Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.214]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Sat, 24 Mar 2012 14:10:55 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-mpls-tp-oam-analysis@tools.ietf.org" <draft-ietf-mpls-tp-oam-analysis@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-mpls-tp-oam-analysis-08
Thread-Index: AQHNCYTfIZ8uMvCtg0mge42m/0NwfQ==
Date: Sat, 24 Mar 2012 06:10:55 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A80C900009@szxeml526-mbx.china.huawei.com>
References: <CAFOuuo5TLJpkwrej_J06mKTH2Y70yF-rvYDn2x06QQJFmCpA6g@mail.gmail.com>
In-Reply-To: <CAFOuuo5TLJpkwrej_J06mKTH2Y70yF-rvYDn2x06QQJFmCpA6g@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.246.127]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [secdir] secdir review of draft-ietf-mpls-tp-oam-analysis-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Mar 2012 06:12:14 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Some comments which may not be from security aspects only are below.

1) One missing OAM function

I compared the OAM functions listed in this draft and those required in RFC5860 and find out one OAM function named Client Failure Indication (Section 2.2.10 of [RFC 5860]) is missing. I cannot see a reason for this. Since this is an informational analysis document, it is recommended to give a whole view. Specific clarifications are appreciated in the document. 

2) Lack of analysis about the compatibility with existing tools

It is said in this document that compatibility with the existing tools has been maintained. But there is no detailed analysis which IMHO might be of great interest to the industry and should form an important part of this analysis document.


3) 1.1 Scope

In the middle of this section, under the "three objectives", the first bullet reads  

   o  The OAM toolset should be developed based on existing MPLS
      architecture, technology, and toolsets.

However, in the following paragraph it is written as

   o  ITU-T OAM for Ethernet toolset as defined in [Y.1731].  This has
      been used for functionality guidelines for the performance
      measurement tools that were not previously supported in MPLS.

There seem to be conflicts between the objective (should...existing MPLS....) and the toolset development (...tools...not...supported in MPLS). [RFC 5860] says that "...the MPLS-TP design, SHOULD as far as reasonably possible, reuse existing MPLS standards." which looks more appropriate to me as the objective. Please clarify this point.


4) 1.1 Scope

The third one of the "three objectives" in this draft reads 

   o  The OAM toolset developed for MPLS based transport networks needs
      to be fully inter-operable with existing MPLS OAM tools as
      documented in [RFC 5860].

I may be wrong but I find [RFC 5860] only requires OAM interoperability between distinct domains (w/wo IP capabilities). The original description is as follows:

   It is REQUIRED that OAM interoperability is achieved between distinct
   domains materializing the environments described in Section 2.1.4.
 
My understanding of the "OAM interoperability" mentioned here refers to MPLS-TP OAM interoperable in different domains, but not MPLS-TP OAM and MPLS OAM interoperability. 


5) MPLS-TP v.s. MPLS based transport networks
The draft uses both "MPLS-TP" and "MPLS based transport networks". E.g. is it "MPLS-TP OAM" or OAM toolset developed for MPLS based transport networks? 
Are they the same? Or what is the relationship between them?


Tina