[mpls] MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt

"Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com> Mon, 22 February 2016 11:41 UTC

Return-Path: <matthew.bocci@nokia.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 E71981B30BB for <mpls@ietfa.amsl.com>; Mon, 22 Feb 2016 03:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TrOQuAczwU_u for <mpls@ietfa.amsl.com>; Mon, 22 Feb 2016 03:41:40 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3701B2C07 for <mpls@ietf.org>; Mon, 22 Feb 2016 03:41:40 -0800 (PST)
Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 282D533DB2F78; Mon, 22 Feb 2016 11:41:36 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u1MBfb1S018842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Feb 2016 11:41:38 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u1MBfbYV019454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Feb 2016 12:41:37 +0100
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.15]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 22 Feb 2016 12:41:37 +0100
From: "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>
To: "draft-ryoo-mpls-tp-aps-updates@tools.ietf.org" <draft-ryoo-mpls-tp-aps-updates@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Thread-Topic: MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.txt
Thread-Index: AQHRbWX8AuFUvi2J6ESORq47kaDMwg==
Date: Mon, 22 Feb 2016 11:41:36 +0000
Message-ID: <D2F0A46F.93408%matthew.bocci@nokia.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <50D8308367B53542802B94F389564F63@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/CzdA1zpgpjNamF13nSnOl6qkiGU>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] MPLS-RT review of draft-ryoo-mpls-tp-aps-updates-02.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: <https://mailarchive.ietf.org/arch/browse/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, 22 Feb 2016 11:41:43 -0000

Authors

I have been selected as an MPLS Review team reviewer for
draft-ryoo-mpls-tp-aps-updates-02.txt.

In general, I think the draft is technically sound and it is useful to
provide clarification to sections of RFC7271 if it is the case that this
is actually causing confusion to implementers. However, I would encourage
the working group to think about how widely implemented and deployed
RFC7271 is before progressing this work, since spending working group time
on something that is not being widely implemented does not seem useful.

Minor Comments/Nits
‹‹‹‹‹‹‹‹‹‹‹‹‹‹
4.1 
<https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.1>
.  Initialization Behavior

   This section defines initialization behavior that is not described in
   [RFC7271 <https://tools.ietf.org/html/rfc7271>].

MB> It is a little unclear if this is adding a new INIT state to the state
machine that you can transit to from one or more other states, or if this
is just stating initial conditions before APS becomes operational. Please
can you clarify?

4.2 
<https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.2>
.  State Transition Modification

   In addition to the initialization behavior described in Section 4.1
<https://tools.ietf.org/html/draft-ryoo-mpls-tp-aps-updates-02#section-4.1>
,
   four cells of remote state transition table need to be changed to
   make two end nodes converged after initialization.

MB> s/four cells of remote state/ four cells of the remote state
MB> s/two end nodes converged / two end nodes converge


 Best regards

Matthew