ietf
[Top] [All Lists]

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

2014-03-27 12:26:21
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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2014-04-09. Exceptionally, comments 
may be
sent to iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls




-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*
<Prev in Thread] Current Thread [Next in Thread>
  • Re: [mpls] Last Call: <draft-ietf-mpls-psc-updates-03.txt> (Updates to MPLS Transport Profile Linear Protection) to Proposed Standard, Yaacov Weingarten <=