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@xxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxx mailing lists by 2014-04-09. Exceptionally, comments may be
>> sent to iesg@xxxxxxxx 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@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
> --
> Thanx and BR,
> yaacov
>
> Still looking for new opportunity
>
> _______________________________________________
> mpls mailing list
> mpls@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/mpls
>