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

From: Yaacov Weingarten <[email-masked]>
Date: Wed, 26 Mar 2014 23:08:37 +0200

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 <[email-masked]> 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
> [email-masked] mailing lists by 2014-04-09. Exceptionally, comments may be
> sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*