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

Eric Osborne <eric@notcom.com> Mon, 31 March 2014 19:06 UTC

Return-Path: <eric@notcom.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6D31A08B1 for <ietf@ietfa.amsl.com>; Mon, 31 Mar 2014 12:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 Z-0I4pwmeffn for <ietf@ietfa.amsl.com>; Mon, 31 Mar 2014 12:06:41 -0700 (PDT)
Received: from mail-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by ietfa.amsl.com (Postfix) with ESMTP id 518A01A6F32 for <ietf@ietf.org>; Mon, 31 Mar 2014 12:06:41 -0700 (PDT)
Received: by mail-yk0-f175.google.com with SMTP id 131so6521813ykp.6 for <ietf@ietf.org>; Mon, 31 Mar 2014 12:06:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6oVkf954FS6g/YDChMnhw43EIuwRNICTlr9T1IyWygI=; b=BoAEfvys+Tzb9gYeuUeDpvqAvQszv8wZy5+qw2BD6tCCwipI7SW0LJHlWDbmRzXjOi FCiRlLiOcYcBIkWe65RmRms+YOBArWpfKACQeBAfBzPIuiBWL7CaqKpMIE0nV26qcM5Y Dw22POWFLt7/MmlKxhlsaF8fCIYe4505za8edNS7IHZcRPwzKuPmH6vmfpsVzP48R0p3 uwG1pGM/a156D9HZBBu+C41D1kr8JvLrgjANF7NhGigjTOSskhjxIl/Yqn/DpySTtmBL o9oqz0h7WKudAJakDKWr7EOrCMdgvdWAcp70XOt9L53PI7qFXRoMnekSy0zuoFETrckk MP/A==
X-Gm-Message-State: ALoCoQkTziWPat2iUeF0YGVUh94rzNjGf5Ri2i8EDJ36ZYDUGcYpD83SZYKFaU5GA3B6vwSuMeWn
MIME-Version: 1.0
X-Received: by 10.236.139.70 with SMTP id b46mr39035035yhj.63.1396292797978; Mon, 31 Mar 2014 12:06:37 -0700 (PDT)
Received: by 10.170.60.5 with HTTP; Mon, 31 Mar 2014 12:06:37 -0700 (PDT)
In-Reply-To: <CAM0WBXWAm8mAAAXKxNaCi+x3O7hfPr_U5_bcvzWZKYExCUSiAA@mail.gmail.com>
References: <20140326195717.26906.70350.idtracker@ietfa.amsl.com> <CAM0WBXWAm8mAAAXKxNaCi+x3O7hfPr_U5_bcvzWZKYExCUSiAA@mail.gmail.com>
Date: Mon, 31 Mar 2014 15:06:37 -0400
Message-ID: <CA+97oKMnSJ2g+32OwrUHzSzCzaNtRRnXTMsJvHYbDgPsNF8GvA@mail.gmail.com>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard
From: Eric Osborne <eric@notcom.com>
To: Yaacov Weingarten <wyaacov@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/VKe0BVpGCA0S0_fNYkfBrLPgR5I
X-Mailman-Approved-At: Tue, 01 Apr 2014 08:09:03 -0700
Cc: "mpls@ietf.org" <mpls@ietf.org>, ietf@ietf.org, IETF-Announce <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Mar 2014 19:06:43 -0000

Hi Yaacov-

  Thanks for the review.  I'll fix the typos you point out in 1 and 2c.
As far as the non-typo bits:

----
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!
----

Section 5 clarifies the behavior when we have multiple simultaneous
requests from either the Local or Remote logic.  Consider the text
"In both cases the question is not how the PSC Control logic decides
which of these is the one it acts upon.....The point that this section
clears up is around what happens when the highest priority input goes
away.... A strict reading of the FSM would suggest that PSC transition
from PA:F:L into N, and at some future time (perhaps after the remote
request refreshes) PSC would transition from N to PA:F:R.  This is an
unreasonable behavior, as there is no sensible justification for a
node behaving as if things were normal (i.e. N   state) when it is
clear that they are not."

I've had multiple questions around this exact behavior offline, which
is the motivation for the clarification.  Nowhere in rfc6378 do we
make explicit that when a higher priority request goes away, the lower
priority request is evaluated.  A langauge-laywer interpretation of
rfc6378 could lead to incompatible implementations, and since the
behavior I spell out in section 5 is what a sensible implementation
would do anyways, the clarification just helps those who would work
strictly by the book.



---
     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.
----

If I disprove my thesis in the course of an example, it is purely by
accident.  I'm not sure I see where you're reading that, though.
Section 5's text that says "What should happen is that the PSC Control
logic should, upon removal of an input, immediately reevaluate all
other inputs to decide on the next course of action.  This requires an
implementation to store the most recent local and remote inputs
regardless of their eventual use as triggers for the PSC Control
Logic" says what I think you are asking for.  Right?  If that's not
sufficient, can you show me exactly where the misleading text is?





eric


On Wed, Mar 26, 2014 at 5:08 PM, Yaacov Weingarten <wyaacov@gmail.com> wrote:
> 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
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>