Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt

Lucy yong <lucy.yong@huawei.com> Wed, 06 May 2015 22:39 UTC

Return-Path: <lucy.yong@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 CED331B29F6 for <mpls@ietfa.amsl.com>; Wed, 6 May 2015 15:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 b85MzVenyUHb for <mpls@ietfa.amsl.com>; Wed, 6 May 2015 15:39:21 -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 2AEBE1ACD9F for <mpls@ietf.org>; Wed, 6 May 2015 15:39:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSF46823; Wed, 06 May 2015 22:39:19 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 May 2015 23:39:18 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Wed, 6 May 2015 15:39:07 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: "draft-mirsky-mpls-residence-time@tools.ietf.org" <draft-mirsky-mpls-residence-time@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Thread-Topic: MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt
Thread-Index: AQHQhky7CoX4gxzfLUGxZrSN4qgSRZ1vhCDw
Date: Wed, 06 May 2015 22:39:07 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D5716838F@dfweml701-chm>
References: <55473BCB.70709@pi.nu>
In-Reply-To: <55473BCB.70709@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.151.10]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/PIACoq8nnFJizCn7NwRBkyCt1Dw>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] MPLS_RT review of draft-mirsky-mpls-residence-time-06.txt
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: Wed, 06 May 2015 22:39:23 -0000

Hi All,

I reviewed draft-mirsky-mpls-residence-time as the member of MPLS Review Team and have the following comments:

is the document coherent?

Yes. It specifies how MPLS supports residence time measurement. 

is it useful (ie, is it likely to be actually useful in operational networks)?

The document claims that such measurement can improve the accuracy of clock synchronization across the network. I am not an operator and author and not sure how useful this feature provides compared to the complexity adding to. 

is the document technically sound? 
Yes. The draft provides a detail solution in control plane and data plane to achieve this purpose.

is the document ready to be considered for WG adoption?
Yes. The document states the problem clearly and provides a solution to address this problem.  

IMHO:  after adopting it as the WG draft, the WG should further evaluate if control plane and data plane solution can be simplified. The areas may be considered:
1) Do we have to use IGP to announce node RTM capability? Can RSVP-TE resolve the issue by itself?
2) Will possible to enhance RRO to serve RSO purpose instead of carrying both RRO and RSO in the message?
3) Since this feature is designed for the LSP that is used for clock synchronization, such LSPs are not majority, so it should be option in LSP setup. Make that very clear.
4) two-step clock mode is quite complex. The description in Section 7 is not clear to me why this mode is necessary. 

Regards,
Lucy