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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]