Re: [mpls] MPLS-RT Review of draft-fbb-mpls-tp-p2mp-framework-05

<kenji.fujihira.dj@hitachi.com> Mon, 03 September 2012 10:18 UTC

Return-Path: <kenji.fujihira.dj@hitachi.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE22921F8505 for <mpls@ietfa.amsl.com>; Mon, 3 Sep 2012 03:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.09
X-Spam-Level:
X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 dr9O2Mm7rO87 for <mpls@ietfa.amsl.com>; Mon, 3 Sep 2012 03:18:57 -0700 (PDT)
Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1295C21F8504 for <mpls@ietf.org>; Mon, 3 Sep 2012 03:18:57 -0700 (PDT)
Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id DC1B933CC7; Mon, 3 Sep 2012 19:18:55 +0900 (JST)
Received: from mfilter03.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id q83AItHI018834; Mon, 3 Sep 2012 19:18:55 +0900
Received: from vshuts3.hitachi.co.jp (vshuts3.hitachi.co.jp [10.201.6.72]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id q83AIsnb014351; Mon, 3 Sep 2012 19:18:55 +0900
X-AuditID: b753bd60-955d6ba000000c4c-f3-50448408c015
Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 8353D77427E; Mon, 3 Sep 2012 19:18:48 +0900 (JST)
Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id q83AIms28954854; Mon, 3 Sep 2012 19:18:48 +0900
Message-Type: Multiple Part
MIME-Version: 1.0
Message-ID: <XNM1$6$0$0$$9$1$2$A$2007350U504483e1@hitachi.com>
Content-Type: text/plain; charset="ISO-2022-JP"
To: draft-fbb-mpls-tp-p2mp-framework@tools.ietf.org
From: kenji.fujihira.dj@hitachi.com
Date: Mon, 03 Sep 2012 19:18:37 +0900
Priority: normal
Importance: normal
X400-Content-Identifier: X504483E100000M
X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28120903191809SUW]
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org
Subject: Re: [mpls] MPLS-RT Review of draft-fbb-mpls-tp-p2mp-framework-05
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 03 Sep 2012 10:18:57 -0000

Hi, authors and chairs.

As the MPLS-RT process, I've reviewed draft-fbb-mpls-tp-p2mp-framework-05.

a. Is the document coherent?
It is almost coherent. I have two comments.

- Section 7. (Network Management)
I think the following description should be moved from section 7 to section 4 (OAM).
"Packet Loss and Delay Measurement for
 MPLS Networks [RFC6374] already considers the P2MP case and it is not
 thought that any change is needed to the MPLS-TP profile of [RFC6374]
 [RFC6375]."

- Section 1.2. (Terminology)
I suppose PM is "Performance Monitoring", not "Performance Measurement",
referring to RFC5921, 5951 and 6371.

b. Is it useful (ie, is it likely to be actually useful in operational networks)?
I believe this draft is useful. If possible, comments from operators will help.

c. Is the document technically sound?
My concern is 1:n protection. 
As addressed in section 6, it needs further discussion.
Relating to this point, it will be valuable if the draft lists up protection types
P2MP MAY support (for example, partial tree protection as addressed in section 6).

The other descriptions are clear and well aligned with referred RFCs. 

d. Is the document ready to be considered for WG adoption?
IMO, it's better to close my comments above on section 7 before WG adoption.

Best Regards,
Kenji.


>Kenji, Jia, Dave;
>
>You have been selected as an MPLS Review team reviewers for
>draft-fbb-mpls-tp-p2mp-framework-05.txt
>
>Note to authors: You have been CC壇 on this email so that you can know
>that this review is going on. However, please do not review your own
>document.
>
>Reviews should comment on whether the document is coherent, is it useful
>(ie, is it likely to be actually useful in operational networks), and is
>the document technically sound?  We are interested in knowing whether
>the document is ready to be considered for WG adoption (ie, it doesn稚
>have to be perfect at this point, but should be a good start).
>
>Reviews should be sent to the document authors, WG co-chairs and
>secretary, and CC壇 to the MPLS WG email list. If necessary, comments
>may be sent privately to only the WG chairs.
>
>Are you able to review this draft by Sep 3, 2012?
>
>Thanks, Loa
>(as MPLS WG chair)
>-- 
>
>
>Loa Andersson                         email: loa.andersson@ericsson.com
>Sr Strategy and Standards Manager            loa@pi.nu
>Ericsson Inc                          phone: +46 10 717 52 13
>                                              +46 767 72 92 13
>