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

Loa Andersson <loa@pi.nu> Fri, 04 March 2016 02:38 UTC

Return-Path: <loa@pi.nu>
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 3761C1B2F16 for <mpls@ietfa.amsl.com>; Thu, 3 Mar 2016 18:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 mzsCmJkmC22D for <mpls@ietfa.amsl.com>; Thu, 3 Mar 2016 18:38:26 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A393C1B2F02 for <mpls@ietf.org>; Thu, 3 Mar 2016 18:38:26 -0800 (PST)
Received: from [192.168.1.13] (unknown [49.149.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 48F871802BEB; Fri, 4 Mar 2016 03:38:20 +0100 (CET)
To: Stewart Bryant <stewart.bryant@gmail.com>, "Bocci, Matthew (Nokia - GB)" <matthew.bocci@nokia.com>, "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>
References: <D2F0A46F.93408%matthew.bocci@nokia.com> <56D84D82.9080709@gmail.com>
From: Loa Andersson <loa@pi.nu>
Message-ID: <56D8F513.2030303@pi.nu>
Date: Fri, 04 Mar 2016 10:38:11 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56D84D82.9080709@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/sEwyJXCL5yCOBqw4OEtPVIyhaVQ>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [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: Fri, 04 Mar 2016 02:38:29 -0000

Authors,

We have enough mpls-rt reviews in now. Could you please check if there
is anything that you want to change in the draft, before starting the
working group document adoption poll.

/Loa

On 2016-03-03 22:43, Stewart Bryant wrote:
> I was also selected as an MPLS Review team reviewer.
>
> The document is well written and should be adopted by the WG.
>
> As part of the WG process there needs to be independent confirmation
> that if put into an arbitrary state, the state machine unconditionally
> migrates to the correct state, and hence that the state machine is
> unconditionally correct. That way we can be sure that no further
> changes will be needed to address "all problematic changes@
>
> - Stewart
>
> Stewart
>
> On 22/02/2016 11:41, Bocci, Matthew (Nokia - GB) wrote:
>> 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
>>
>>
>> _______________________________________________
>> mpls mailing list
>> mpls@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls