Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard

Yaacov Weingarten <wyaacov@gmail.com> Wed, 26 March 2014 21:08 UTC

Return-Path: <wyaacov@gmail.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 BA61C1A03CC; Wed, 26 Mar 2014 14:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 IrFO9Gk7gQsK; Wed, 26 Mar 2014 14:08:39 -0700 (PDT)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6C48E1A0220; Wed, 26 Mar 2014 14:08:39 -0700 (PDT)
Received: by mail-qg0-f41.google.com with SMTP id i50so1630880qgf.28 for <multiple recipients>; Wed, 26 Mar 2014 14:08:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qep14cLXBpjnq7wlNQkWau72Ysy1lHS2JTdCmujAhSw=; b=A7gRyvH4EMXvRZilmALxIOSWN8HkfDD0WDRR6yRRKVx0ptrYM1tuWmsgoY1y7VJ5X3 yZ8mw75CllYi1rLOJ+FEFjIm5cRJl6irDHZBGbmVX0G0xdopEufJ6RF+Nj96UziBDBK1 jmJnA7cKx9kkjjx8okO4xD0BmZ/JzSrCs5pzmeTSN6GWmwaQe8UG3Mq/Nh6bM1z2MIAO P083vYuwJSY62V3ttpLJV9faWfHNxZ9ReUuvuCI4VynUMGED67isBRQ2sMzyYtkkvq/H ydwO+c8zDtmAL0sNnQEsWAf3DJRwQ6gqJwP2cn3ceS/zGqLgm/EwiEEvm/ejzqbnSVrO me5A==
MIME-Version: 1.0
X-Received: by 10.224.75.5 with SMTP id w5mr32527594qaj.52.1395868117663; Wed, 26 Mar 2014 14:08:37 -0700 (PDT)
Received: by 10.224.173.2 with HTTP; Wed, 26 Mar 2014 14:08:37 -0700 (PDT)
In-Reply-To: <20140326195717.26906.70350.idtracker@ietfa.amsl.com>
References: <20140326195717.26906.70350.idtracker@ietfa.amsl.com>
Date: Wed, 26 Mar 2014 23:08:37 +0200
Message-ID: <CAM0WBXWAm8mAAAXKxNaCi+x3O7hfPr_U5_bcvzWZKYExCUSiAA@mail.gmail.com>
From: Yaacov Weingarten <wyaacov@gmail.com>
To: ietf@ietf.org
Content-Type: multipart/alternative; boundary="001a11c357c24e84d804f588df64"
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/LZMe2z3eGladQ4i2bw-uacy6AkU
Cc: mpls@ietf.org, IETF-Announce <ietf-announce@ietf.org>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard
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, 26 Mar 2014 21:08:43 -0000

Hi,

Some comments and nits regarding this draft:

1. The Abstract states "This document contains four updates to", whereas
the first statement of the Introduction states "This document contains
firve updates to" -  so aside from the spelling mistake please align the
two statements to the correct number of updates.

2. Section 5 is very confusing to me -
       a. My understanding was that the PSC Control Logic always receives
two inputs - one local and one remote and decides on the the next state
based upon these two inputs and the current state of the Control Logic as
defined in the FSM. You, however, state that you need to explain how the
Control Logic should react to different inputs. After explaining, the two
cases of different inputs, you then state that the reaction to these inputs
is already covered in RFC6378, and what needs to be clarified is the
recovery from the input that was defining the current state! Not sure what
you really meant to say, but it would help if you gave a consistent message
throughout as to what needs to be clarified!
     b. At some point you state that the Control Logic should remember the
last received local and remote inputs for reevaluation when the driving
input is cleared. But then you go and prove that this is not necessarily
true, since the inputs may change during the interim (went from R(LO) to
R(SF-W)). Therefore, I think that the correct interpretation should be
based on the two current inputs as provided by the Local Request Logic and
Remote Input. What may need to be corrected is that each of these two units
should persist their latest outputs to continue to be provided as input to
the Control Logic.
     c. Your first example, (in the third paragraph) describes two FS
inputs (a "local" and "remove" [should be changed to "remote"]) to the
Control Logic, but then in the fifth paragraph it is a "local SF" that is
driving the state. Please change this to "local FS".

Hope these help,
yaacov


On Wed, Mar 26, 2014 at 9:57 PM, The IESG <iesg-secretary@ietf.org> wrote:

>
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> - 'Updates to MPLS Transport Profile Linear Protection'
>   <draft-ietf-mpls-psc-updates-03.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2014-04-09. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>    This document contains four updates to the Protection State
>    Coordination (PSC) logic defined in RFC6378, "MPLS Transport Profile
>    (MPLS-TP) Linear Protection" . Two of the updates correct existing
>    behavior.  The third clarifies a behavior which was not explained in
>    the RFC, and the fourth adds rules around handling capabilities
>    mismatches.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-mpls-psc-updates/ballot/
>
> No IPR declarations have been submitted directly on this I-D.
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>



-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*