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

From: Robert Rennison <[email-masked]>
Date: Wed, 2 Feb 2011 10:52:02 -0500

All,

Mustapha and I recently had some more correspondence on the redundancy-bit-draft. Matthew asked that since this was in a last call if we could
copy the comments to the list.

First Mustapha's response to me. Then in a follow up email, my response to Mustapha.

Cheers

Rob Rennison

------------------------------------------------------------------

-----Original Message-----
From: Aissaoui, Mustapha (Mustapha) [mailto:[email-masked]]
Sent: Friday, January 28, 2011 5:30 PM
To: Robert Rennison
Cc: Muley, Praveen V (Praveen); Bocci, Matthew (Matthew); Aissaoui, Mustapha (Mustapha)
Subject: RE: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt

Hi Rob,
See below for some elements of response to your comments indexed by "MA>".

Let me know what you think.

Regards,
Mustapha.

-----Original Message-----
From: Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, January 18, 2011 2:35 PM
To: Robert Rennison
Cc: Muley, Praveen V (Praveen); Bocci, Matthew (Matthew)
Subject: RE: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt

Hi Rob,
I apologize but I did not have a chance to look into them with more details. As you guessed, I was swamped with work lately so the update of the IETF drafts took a hit :-)

I will get back to you shortly with my proposal how to address them.

Thank you again for the review.

Mustapha.

-----Original Message-----
From: Robert Rennison [mailto:[email-masked]]
Sent: Tuesday, January 18, 2011 2:29 PM
To: Aissaoui, Mustapha (Mustapha)
Cc: Muley, Praveen V (Praveen)
Subject: FW: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt

Mustapha,

I'm not sure if you have tried to follow up with me and I've perhaps lost or mis-filtered your email or if like many you were too swamped and this fell into the cracks.

I should have "pinged" you sooner.

Hopefully we can discuss some of the points I made.

I've pasted them in this email at the very bottom for easy reference.

Cheers

Rob Rennison

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Tuesday, November 02, 2010 1:25 PM
To: Andrew G. Malis; [email-masked]
Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt

Thanks Andy. We will with Rob to address his comments.

Mustapha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew G. Malis
Sent: Tuesday, November 02, 2010 12:54 PM
To: [email-masked]
Subject: Re: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt

This completes the working group last call, with one set of comments received. Authors, please work with Rob to resolve the comments and post an updated draft to be forwarded to the IESG.

Thanks,
Andy

On Tue, Oct 19, 2010 at 2:31 PM, Andrew G. Malis <[email-masked]> wrote:
> 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
>
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

-----------------------

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.

MA> Yes, we should clarify that. I would however like to keep referring to the new bit as the "preferential forwarding status bit" because it has been there for years and in implementations. I know that in Master/Slave mode it is not exactly a preference as you mentioned further below but I think this is further explained in that section. See below for the proposed changes to the state definitions.

---------------------------------------------------------

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.

MA> Here is my proposal for this paragraph:
"
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 preferential forwarding status for each PW. Each PW endpoint compares local and remote status bits and uses the PW that is operationally UP at both endpoints and that advertised Active preferential forwarding status at both the local and remote endpoints.
In this mode of operation, the preferential forwarding status indicates the prefered forwarding state of each endpoint and the actual forwarding state of the PW is the result of the comparison of the local and remote forwarding status bits.
"

---------------------------------------------------------

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.

MA> Making the same change here would give this:
"
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 operationally UP and its preferential forwarding status is Active at both endpoints. In this state user traffic can flow over the PW in both directions.
"

Also, making the change to the definition of the Standby state would yield this:
"
o       Standby State
A PW is considered to be in Standby state when the PW labels are exchanged between its two endpoints, but the status bits exchanged indicate the PW preferential forwarding status is Standby at one or both endpoints. In this state the endpoints MUST NOT forward data traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and received in order to test the liveliness of standby PWs. If the PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be flushed when it transitions to Standby state according to the procedures in RFC4762 [3] and [9].
"

Finally, here are the changes to the introduction and the state definitions for the Master/Slave mode:
"
5.2. Master/Slave Mode:
One endpoint node of the redundant set of PWs is designated the Master and is responsible for selecting which PW both endpoints must use to forward user traffic.
The Master indicates the forwarding state in the Active/Standby status bit. The other endpoint node, the Slave, MUST follow the decision of the Master node based on the received status bits. In other words, the preferential forwarding status bit sent by the Master node indicates the actual forwarding state of the PW at the Master node.
"

"
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 at both endpoints, and the preferential forwarding status at the Master endpoint is Active. In this state user traffic can flow over the PW in both directions.

o       Standby State
A PW is considered to be in Standby state when the PW labels are exchanged between its two endpoints, and the status bits exchanged between the endpoints indicate the preferential forwarding status at the Master endpoint is Standby. In this state the endpoints MUST NOT forward data traffic over the PW but MAY allow PW OAM packets, e.g., VCCV, to be sent and received. If the PW is a spoke in H-VPLS, any MAC addresses learned via the PW SHOULD be flushed when it transitions to Standby state according to the procedures in RFC4762 [3] and [9].
"
---------------------------------------------------------

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.
MA> Good suggestion. I included this change.

-----------------------------------------------

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.
MA> The state machine is exclusively for the Master/Slave mode as indicated by its sub-section numbering.

Is it to be assumed that all of these event block apply to an endpoint in independent mode ?
MA> One can attempt to write a similar state machine for the independent mode. But it will be fairly simple since the behavior is symmetric. The Master/Slave is asymmetric.

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.
MA> In fact, that algorithm will also exist in the Master/Slave mode. The slave can see more than one PW with Active state and it must handle it properly. It is not shown for simplicity.

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.
MA> As explained earlier, I would like to keep it.

Consider consistent use of Active vs. active.
MA> Will do, thanks.

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
>
> 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
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Robert Rennison <[email-masked]>
Date: Wed, 2 Feb 2011 10:55:41 -0500

My Comments on Mustapha's comments.  Looks like we are in sync.

Cheers

Rob

-----Original Message-----
From: Robert Rennison 
Sent: Tuesday, February 01, 2011 12:05 PM
To: 'Aissaoui, Mustapha (Mustapha)'
Cc: Muley, Praveen V (Praveen); Bocci, Matthew (Matthew)
Subject: RE: [PWE3] WG last call for draft-ietf-pwe3-redundancy-bit-03.txt

Mustapha,

Thank you for understanding and addressing my comments, my comments on your comments below preceded by [RobR]

Cheers

Rob Rennison

-----------------------

Praveen, Mustapha,   

[RobR] I've grown used to the term preferential forwarding status bit, it's also how I tend to think of it, since the majority of use-cases are in the independent mode, so I agree, let's live with the slight inconsistency when in Master/Slave mode.

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

"
5.1. Independent Mode: 

MA> Here is my proposal for this paragraph:
"
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 preferential forwarding status for each PW. Each PW endpoint compares local and remote status bits and uses the PW that is operationally UP at both endpoints and that advertised Active preferential forwarding status at both the local and remote endpoints. 
In this mode of operation, the preferential forwarding status indicates the prefered forwarding state of each endpoint and the actual forwarding state of the PW is the result of the comparison of the local and remote forwarding status bits.
"
[RobR] This looks good, much clearer (fix typo in preferred ==> preferred).  One subtle related point that is brought out in one of the examples, PE-2 in Fig 15-1, but could perhaps be clarified here is that a given endpoint _may_ choose to indicate active on all of its PWs and effectively let the far end pick which PW to make active. Just an observation/food for thought, could be left alone.

The draft states
"
o Active State                                                  

[RobR] Looks good.

[RobR] Looks good.
[RobR] Looks good.
[RobR] Looks good.

o	Standby State
[RobR] Looks good.

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

"

Perhaps change to  

[RobR] Thanks

Regarding the existing single state machine it's not clear what the state transition is for a PW endpoint in independent mode.
MA> The state machine is exclusively for the Master/Slave mode as indicated by its sub-section numbering.
[RobR] I had not caught that subtlety, maybe make the title  "Master/Slave Mode State machine"
One other minor point, within the description of the state machine the description uses the specific bit values i.e "Transmit PW preferential forwarding bit set", whereas throughout the rest of the text the use of an enumerated means of description is used i.e. Active/Standby, perhaps better to stay consistent to this than to talk about whether the bit is set or not, saves the reader reverting to doing inversion in his her head. Minor point only.

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.
MA> In fact, that algorithm will also exist in the Master/Slave mode. The slave can see more than one PW with Active state and it must handle it properly. It is not shown for simplicity. 
[RobR] Ok, point conceded, the state machine is not meant to be a full description but merely a starting point.

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

Cheers

Rob Rennison