[mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules

Mach Chen <mach.chen@huawei.com> Fri, 29 August 2014 09:18 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5569F1A06E7 for <mpls@ietfa.amsl.com>; Fri, 29 Aug 2014 02:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level:
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 3LkSnIZda3AM for <mpls@ietfa.amsl.com>; Fri, 29 Aug 2014 02:18:11 -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 6387E1A0478 for <mpls@ietf.org>; Fri, 29 Aug 2014 02:18:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIV99868; Fri, 29 Aug 2014 09:18:09 +0000 (GMT)
Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 Aug 2014 10:18:08 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.57]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Fri, 29 Aug 2014 17:18:01 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org" <draft-ietf-mpls-tp-oam-id-mib@tools.ietf.org>
Thread-Topic: Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules
Thread-Index: AQHPvSsIjXcmgWC890WmwTUyRwbbOJvnTCuw
Date: Fri, 29 Aug 2014 09:18:00 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25DA8E575@SZXEMA510-MBX.china.huawei.com>
References: <53F5CA67.9070500@pi.nu>
In-Reply-To: <53F5CA67.9070500@pi.nu>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/ioQH2x6hi5LR3R3f0T27m9pbCtg
Cc: "<mpls-ads@tools.ietf.org>" <mpls-ads@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] Shepherd review of draft-ietf-mpls-tp-oam-id-mib//RE: Shepherds for MPLS MIB modules
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Aug 2014 09:18:12 -0000

Hi Authors/Editors,

I am assigned as Shepherd for draft-ietf-mpls-tp-oam-id-mib, the WG chairs and Shepherd are working on the publication of draft-ietf-mpls-tp-oam-id-mib.

I have reviewed version 05 of the draft, here are my comments and some questions, please consider.  

1. 
Extract the acronym when first use, for example, LSP in the Introduction, and it's not necessary to extract an acronym when each uses, for example, MPLS in section 1 and section 3.2 .

2. 
In RFC6370, it defines MPLS-TP point-to-point Tunnels identifiers, MPLS-TP co-routed and associated bidirectional MPLS LSPs identifiers, MPLS-TP Pseudowires Identifiers and Section Identifiers. And in Section 5 of RFC6370, there are some text that describes the difference between "MPLS tunnel" and "MPLS LSP". In this draft, there are many usages of "tunnel" in section 4, 5 and 6, and actually it should be "LSP". I know that sometimes people alternatively use tunnel and LSP, but it's better to use the term in an accurate way hence to reduce the confusion. 

In addition, based on the mplsOamIdMegServicePointerType (only lsp, pw and section listed), it implies that the MPLS-TP point-to-point Tunnels identifiers are actually precluded in this document. Is my understanding right? If so, it needs look through the document and refine the text to state it clearly. 

Here are some example that may need updates:

Section 4.

OLD:
"
The MIB module supports configuration of OAM identifiers for
         point-to-point, co-routed bidirectional, associated
         bidirectional MPLS tunnels and MPLS Pseudowires.
"
NEW:
"
The MIB module supports configuration of OAM identifiers for
         MPLS-TP co-routed bidirectional LSPs, associated
         bidirectional LSPs, Sections and Pseudowires.
"

Section 5.

s/...configurations for MPLS Tunnels and Pseudowires/...configurations for MPLS-TP LSPs, Sections and Pseudowires

Section 5.1

s/...for MPLS tunnels and pseudowires./...for MPLS-TP LSPs, Sections and Pseudowires.

Section 6

s/...MPLS co-routed bidirectional tunnel/...MPLS-TP co-routed bidirectional LSP

s/...co-routed MPLS tunnel are illustrated here/...MPLS-TP co-routed bidirectional LSP are illustrated here

3.

For mplsOamIdMeTable, since this is the identifier MIB, why do we needthe following items?
       mplsOamIdMeProactiveOamPhbTCValue = 0,
       mplsOamIdMeOnDemandOamPhbTCValue  = 0,

It seems that they should not belong to this MIB, maybe better in other MIB.

4.

mplsOamIdMegPathFlow OBJECT-TYPE
          SYNTAX        INTEGER {
                          unidirectionalPointToPoint (1),
                          coRoutedBidirectionalPointToPoint (2),
                          associatedBidirectionalPointToPoint (3),
                          unidirectionalPointToMultiPoint (4)

Seems RFC6370 does not define how to identify a unidirectionalPointToMultiPoint path, and from the Introduction of this document, the P2MP seems not be included.

5.

mplsOamIdMegSubOperStatus OBJECT-TYPE
          SYNTAX       BITS {
                        megDown (0),
                        meDown (1),
                        oamAppDown (2),
                        pathDown (3)
                       }
               The bit 0 (megDown) indicates the MEG is down.
               The bit 1 (meDown) indicates the ME table is
               down.
               The bit 2 (oamAppDown) indicates that the
               OAM application has notified that the entity (LSP or PW)
               monitored by this MEG is down. Currently, BFD is the
               only supported OAM application.
               The bit 3 (pathDown) indicates that the underlying
               LSP or PW is down."

I am not sure what's the mean of "down" here, especially the mean of "MEG is down", "ME table is down" and "LSP and PW is down"?

6.

mplsOamIdMeServicePointer OBJECT-TYPE

          SYNTAX        RowPointer
          MAX-ACCESS    read-create
          STATUS        current
          DESCRIPTION
            "This variable represents a pointer to the MPLS-TP
             transport path. This value MUST point at an entry in the
             mplsTunnelEntry if mplsOamIdMegServicePointerType
             is configured as lsp (1) or at an entry in the pwEntry if
             mplsOamIdMegServicePointerType is configured
             as pseudowire (2).

How about mplsOamIdMegServicePointerTypesection is configured as section (3)?

And draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtEntry for MPLS-TP tunnels and pwExtEntry for MPLS-TP PWs, should the above mplsTunnelEntry and pwEntry be changed to mplsTunnelExtEntry and pwExtEntry?

7.
mplsOamIdMegServicePointerType OBJECT-TYPE

          SYNTAX        INTEGER {
                            lsp (1),
                            pseudowire (2),
                            section (3)
                        }
          MAX-ACCESS    read-create
          STATUS        current
          DESCRIPTION
            "Indicates the service type for the MEG.
             If the service type indicates lsp, the service pointer
             in mplsOamIdMeTable points to an entry in
             the mplsTunnelTable [RFC3812].

Since draft-ietf-mpls-tp-te-mib-08 defines mplsTunnelExtTable for MPLS-TP Tunnels and Pws, should the above mplsTunnelTable be mplsTunnelExtTable and reference be draft-ietf-mpls-tp-te-mib-08?


Best regards,
Mach

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: Thursday, August 21, 2014 6:31 PM
> To: mpls@ietf.org
> Cc: mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN (MARTIN); Joan Cucchiara;
> Mach Chen; <mpls-ads@tools.ietf.org>
> Subject: Shepherds for MPLS MIB modules
> 
> Working Group,
> 
> We have for some time been looking for someone to help us shepherding our
> MIB modules. I'm happy to announce that Mach Chen and Young Lee has agreed
> to help us.
> 
> Please help Mach and Young as they start working with the documents.
> 
> We've assigned Mach as Shepherd for draft-ietf-mpls-tp-oam-id-mib.
> 
> Further shepherd assignments will be done as soon as the details are sorted out.
> 
> 
> /Loa
> for the mpls wg chairs
> --
> 
> 
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64