Subject: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 19 Oct 2010 11:31:09 -0700

This email starts a two week working group last call on
draft-ietf-pwe3-redundancy-bit-03.txt.

Note that changes may be required to this draft as a result of the
comments received on draft-ietf-pwe3-redundancy-03.txt. If so, I would
like to ask the authors to post these changes to the pwe3 list as last
call comments on draft-ietf-pwe3-redundancy-bit-03.txt, and the actual
changes will be made following the end of the last call.

The draft can be found at
http://tools.ietf.org/html/draft-ietf-pwe3-redundancy-bit-03

Please post any comments to the PWE3 list.

This WG last call closes on Tuesday, November 2.

Note that since Matthew is a co-author of this document, Andy will act
as document shepherd.

Regards,
Matthew and Andy

---

From: Robert Rennison <[email-masked]>
Date: Fri, 29 Oct 2010 16:59:31 -0400

Praveen, Mustapha,   

Lots of very useful functionality can be added with the use of this additional bit, and its companion switchover bit. 

Overall a nicely written document, I appreciated the examples in the appendix to illustrate how this could be used.

My main comments regard the descriptions of what the active/standby bit represents. 

For a given PW there are actually two states. The configured/ desired state and the actual operational state. In some cases the draft could be perhaps more explicit in pointing this out or pointing out whether we are signalling and actual vs. a desired state, since the usage varies depending on the mode.

Section 5.1
-----------

For example the draft states

"
5.1. Independent Mode: 

   PW endpoint nodes independently select which PW they intend to make 
   active and which PWs they intend to make standby. They advertise the 
   corresponding Active/Standby forwarding state for each PW. Each PW 
   endpoint compares local and remote status and uses the PW that is 
   operationally UP at both endpoints and that shows Active states at 
   both the local and remote endpoint.
"

I'd suggest  changing this to .... They advertizes the corresponding _desired_ Active/Standby Forwarding states....

Upon first reading the wording of corresponding had me thinking they advertized the states corresponding to their actual operations states not to their desired states. One quickly figures out thing would not work in this case and hence the meaning must be of the  corresponding desired states but I'd like to save this headache for future readers.

The definition  following is in the same section 5.1  and is somewhat unclear/inaccurate , 

The draft states 
"
o Active State                                                  

   A PW is considered to be in Active state when the PW labels are 
   exchanged between its two endpoints, and the status bits exchanged 
   between the endpoints indicate the PW is UP and Active at both 
   endpoints. In this state user traffic can flow over the PW in both 
   directions. 
"
1.	It's  self referential/recursive, stating that Active state (of the PW)  depends on both ends indicating Active state (of the PW)
2.	This is inaccurate since the status bits are not indicating that the PW is UP and Active at both ends they are really indicating that the PW is UP and each end has a desire or preference for the PW to be active.

If  the wording is changed to reflect the point made in #2 then the objection  raised in #1 is retracted since the definition is no longer recursive.

Section 5.2  Master/Slave mode is much clearer about what is being signaled.

Section 6
----------

In Section 6 PW State Transition Signalling Procedures first paragraph

"
6. PW State Transition Signaling Procedures  

   This section describes the extensions to PW status signaling and the  processing rules for these extensions. It defines a new "PW  
   preferential forwarding" bit Status Code that is to be used with the   PW Status TLV specified in RFC 4447 [2]. The PW preferential 
   forwarding bit, when set, is used to signal the Standby state of the   PW by one PE to the far end PE.
"

The last sentence is inaccurate since this statement is not mode specific, it's true for the Master end of Master/Slave but not in general.

Perhaps change to  

The PW preferential forwarding bit, when set, is used to signal either the Preferred or Actual  Active/Standby state of the 
  PW by one PE to the far end PE. The actual semantics of the Value being signaled vary according to whether the PW is acting in a Master/Slave or independent mode.

Section 6.2.1 State Machine
-----------------------------

It may be clearer to have two separate state machines one for Active/Standby and one for Independent mode.

Regarding the existing single state machine it's not clear what the state transition is for a PW endpoint in independent mode.

Is it to be assumed that all of these event block apply to an endpoint in independent mode ?

Under The active State 2nd event,   "Receive preferential forwarding bit set (slave)  Action: Stop forwarding over PW"

If we were in independent mode there would be additional work to determine if there were any alternative PWs with PW signaled at both ends, i.e. run the algorithm for picking a new  Active  PW. This is not called out.

Editorial/ Nits
----------------

The  name "preferential forwarding status bit" is misleading since in the Master mode It's  not  indicating the preferred PW to forward on, It's an order, this is the one to use. While in Independent mode it is indicating a preference.
Perhaps dropping the word preferential and calling it the  "forwarding status bit" maybe clearer.

Consider consistent use of Active vs. active.

Cheers

Rob Rennison

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Andrew G. Malis
> Sent: Tuesday, October 19, 2010 2:31 PM
> To: [email-masked]
> Subject: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3