Subject: [Gen-art] Gen-art last call review of draft-ietf-pwe3-cbit-negotiation-04

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Jun 2012 13:12:17 +0100

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. 

Please resolve these comments along with any other Last Call comments 
you may receive. 

Document: draft-ietf-pwe3-cbit-negotiation-04.txt
Reviewer: Elwyn Davies
Review Date: 19 June 2012
IETF LC End Date: 15 June 2012
IESG Telechat date: 21 June 2012

Summary: 
Not ready. The proposal for the NOT PREFERRED to PREFERRED transition
case does not appear to be compatible with the existing RFC 4447
standard in the way stated and there are a number of other minor issues.
The draft is also in need of an editing pass by an author whose mother
tongue is English as there are parts where the syntax is misleading
rather than just clumsy.

Apologies for the late submission of the review.

Major issues: 
s3: The discussion of the NOT PREFERRED to PREFERRED transition case
(buried at the end of s3 - causing me to ask 'what about this case?'
during reading of s2 and most of s3)  implies that some existing RFC
4447 procedure applies. Clearly, if the PW is not using the control word
then there is nothing to do.  On the other hand, inspection of s6.2 of
RFC4447 indicates that once the two PEs have agreed on c = 1, 'setup is
complete' and Label Mapping messages would therefore be
'unexpected' (see item '-i' in second set of bullets in s6.2 of RFC
4447). So, what procedure is to be used? And what implications does this
have for backwards compatibility?  Wouldn't it be generally simpler to
apply the PREFERRED to NOT PREFERRED mechanism to all case?

Minor issues: 
s3: Has there been any discussion on possible race conditions?  Changing
the configuration value during the message exchange strikes me as
dangerous - it is probably sufficient to note that changes should be
suppressed during the Label Mapping message exchange but I am not
totally sure about this.

s3, bullet '-i':  I completely misparsed this section on first reading
and I am still not absolutely sure what message sequence is being
specified.  Working back from later sections I *think* that the
intention is:
IF Mapping sent THEN { send Withdraw; send Release;}
Wait to receive Release
The implication at present is that a Mapping might not have been sent
and then only a Release is needed: is this a possibility? Please
clarify.
The picture in Appendix A suffers from the same problem.

s3, discussion of multi-segment PWs: The statement that S-PE's SHOULD
assume an initial passive role seems to have several problems:
- Does this mean that changing the configuration of an S-PE would not
provoke the new mechanisms?
- The passive role situation is only specified for some sorts of linked
FECs in RFC 6073 - what about other cases?
- What are the consequences for ignoring the SHOULD in this case? (I
have to say I am unsure that RFC 6073 deals with this problem either.)

Nits/editorial comments: 
General: In RFC 4447, the label message names use title case (e.g.,
Label Mapping).  For consistency this should be followed throughout this
document.
 
Abstract:  Should not contain references.  Best to give full title of
RFC and number in round brackets.
Abstract: s/problem of control/ the problem with control/ (if there is
just one)
Abstract: The second two sentences say the same thing in different ways 
OLD
   Based on the problem analysis, a
   message exchanging mechanism is introduced to solve this control word
   negotiation issue.  This document is to update [RFC4447] control word
   negotiation mechanism.
NEW
Based on the problem analysis, this document introduces a modified message exchange 
sequence updating the control word negotiation mechanism in RFC 4447.

This issue also applies to s1.

s1: Subtle distinction - this is a practical problem with the mechanism defined in RFC 4447 rather 
than the abstract problem of how to do control word negotiation:
 s/the problem of control word negotiation/problems identified in the control word negotiation/

s1: Expand acronym PW.

s2: Expand acronym PE.
s2, 2nd sentence: s/configurable/configured/
s2, 3rd and 4th sentences: I *think* this text is trying to say: 
  The intention of the control word negotiation is that the control word
will be used when both endpoints are configured with control word usage
PREFERRED.  However if one endpoint is initially configured with control
word usage NOT PREFERRED but later changes to PREFERRED, a PW between
the endpoints will not transition to usage of the control word as
explained below. 

s2, bullet #2: s/PE1 send label mapping with C bit=0 finally./ultimately
PE1 sends a Label Mapping message with the C bit set to 0./

s2, bullet #4: s/send label withdraw/send a Label Withdraw/

s2, bullet #5: s/the received/the previously received/, 
s/indicates C bit=0/carried the C bit set to 0/, 
s/send label mapping with C bit=0/send a label mapping message with the
C bit set to 0/

s3: It would be much clearer if s3 was divided into 3 sub-sections
(possibly reordered):
- PREFERRED to NOT PREFERRED transition
- NOT PREFERRED to PREFERRED transition
- Multi-segment case (which should refer to both previous cases)
The pointer to the diagram in Appendix A could usefully occur in the
introduction to s3.  If this was adopted s3.1 could either be a fourth
sub-section or a sub-sub-section of the PREFERRED to NOT PREFERRED
section.

s3, Various acronyms need expanding: FEC, T-PE, S-PE

s3, para 1: s/adding label request/adding a new label request/

s3 bullets '-i' to '-iii': s/Local PE/The local PE/, s/remote PR/the
remote peer PE/.  Also a more usual labeling of the bullets would be
appropriate (e.g., just i, ii and iii).

s3, para 2: s/When Local/When the local/,
s/the remote label mapping message with C bit=0, additional procedure
will be added as follow:/a label mapping message from the PW peer with
the C bits set to 0, the following additional procedure will be acrried
out:/
 
s3, bullet '-i': s/wait until receiving a label release/wait until it
has received a Label Release message/ (but general clarification and
rewording needed - see issues section above).

s3, bullet '-ii':
OLD:
      Local PE MUST send a label request message to remote PE, and
      wait until receiving a label mapping message containing the remote
      PE locally configured preference for use of control word.
NEW:
      The local PE MUST send a Label Mapping message to the peer PE with the
      C bit set to 1, and then wait until a Label Mapping message is received 
      containing the peer's current configured preference for usage of the 
      control word.

s3, para sfter item '-iii': s/successfully/has successfully/
The following implies that there is memory of previous action although
the label binding has been destroyed. Better would be:
OLD:
>    ...and removed the remote label binding, it MUST reset
>    its use of control word with the locally configured preference, and
>    send label mapping as a response of label request with locally
>    configured preference for use of control word.
NEW:
...and removed the remote label binding, subsequent Label Requests will
naturally be treated as new requests and processed as described in
Section 6 of RFC 4447.

s3, discussion of multi-segment PWs: s/case for T-PE is same./case for a
T-PE operates similarly./

s3, last para/Appendix A:  The diagram doesn't cover the PREFERRED to
NOT PREFERRED transition.

s3.1: The wording in this section is generally  rather 'loose'.  A more
formal style would be helpful.

---

From: Lizhong Jin<[email-masked]>
Date: Tue, 19 Jun 2012 21:48:26 +0800

Hi Elwyn,
Thank you for the review. It seems you are reviewing v-03, not v-04, but 
some comments are for v-04. I am confused. See my reply inline below.

Regards
Lizhong

> tongue is English as there are parts where the syntax is misleading
[Lizhong] We have two editors, and both Raymond and I are editing this 
document. Hope the below reply will make it clear.
> apply the PREFERRED to NOT PREFERRED mechanism to all case?
[Lizhong] this draft is to solve the case to change a PW from c=0 to c=1, 
that means one PE should change its use of control word from NOT PREFERRED 
to PREFERRED. RFC4447 is already there and deployed, and the PE will not 
always send its locally configured preferrence according RFC4447, see PE1 
behavior in section 2 step 1&2. That's why we could not simply apply the 
mechanism at the end of section 3. Hope it is clear.

> suppressed during the Label Mapping message exchange but I am not
[Lizhong] The message would be processed in sequence in TCP-based LDP 
session. I do not see a problem here. But we do have a note in section 3 
for multi-segment PW for sequence processing.

> The picture in Appendix A suffers from the same problem.
[Lizhong] Adrian raise the same comment, and I change it as below:
       -i.  PE MUST send a Label Release message to remote PE. If a PE
            has previously sent a Label Mapping message to a remote PE, 
            it MUST also send a Label Withdraw message to the remote PE, 
            and wait until it receives a Label Release message from the
            remote PE.

> have to say I am unsure that RFC 6073 deals with this problem either.)
[Lizhong] we follow RFC6073, and passive role is only applied for the PW 
FEC, other cases are out of scope. SHOULD means highly recommended. We do 
not meet any problem when implementing RFC6073. Do you suggest to change 
this to MUST? 

> Label Mapping).  For consistency this should be followed throughout this
[Lizhong] yes, and thank you and Adrian.
> RFC and number in round brackets.
[Lizhong] I removed brackets and do not intend to contain citations here. 
It seems the citations are generated automatically by IETF. Could the 
round brackets solve this? Or are you referring v-03?

> Abstract: s/problem of control/ the problem with control/ (if there is
[Lizhong] are you reviewing v-03 of the draft? In v-04, the abstract has 
been revised in v-04.

> This issue also applies to s1.
[Lizhong] are you reviewing v-03 of the draft? In v-04, the abstract has 
been revised in v-04.

> the control word negotiation/
[Lizhong] has been revised in v-04.
> s1: Expand acronym PW.
[Lizhong] has been revised in v-04.
> s2: Expand acronym PE.
[Lizhong] accept

> s2, 2nd sentence: s/configurable/configured/
[Lizhong] configurable is right.

> the endpoints will not transition to usage of the control word as
[Lizhong] no, the case is that operator deploys PW with control word used 
in the first phase. In the second phase, they want to upgrade their PW 
service to use control word. Two different deployment timeframes.

> PE1 sends a Label Mapping message with the C bit set to 0./
[Lizhong] accept
> s2, bullet #4: s/send label withdraw/send a Label Withdraw/
[Lizhong] accept
> s/send label mapping with C bit=0/send a label mapping message with the
[Lizhong] accept
> sub-section or a sub-sub-section of the PREFERRED to NOT PREFERRED
[Lizhong] PREFERRED to NOT PREFERRED does not introduce any new. 
Multi-segment case is fully inherited from single-segment case. It would 
be redundancy to have sub-sections here.

> s3, Various acronyms need expanding: FEC, T-PE, S-PE
[Lizhong] accept
> s3, para 1: s/adding label request/adding a new label request/
[Lizhong] much difference here?
> appropriate (e.g., just i, ii and iii).
[Lizhong] accept, and I do not see "remote PR".
> the C bits set to 0, the following additional procedure will be acrried
[Lizhong] accept
> rewording needed - see issues section above).
[Lizhong] do not see much difference here. Of couse the "label release" 
should be capitalized.
>       C bit set to 1, and then wait until a Label Mapping message 
isreceived 
>       containing the peer's current configured preference for usage of 
the 
[Lizhong] no, the procedure here is not right. The local PE MUST send a 
label request message, not label mapping.
> s3, para sfter item '-iii': s/successfully/has successfully/
[Lizhong] accept

> naturally be treated as new requests and processed as described in
[Lizhong] we got similar comments from Adrian, and will update this.

> T-PE operates similarly./
[Lizhong] accept
> NOT PREFERRED transition.
[Lizhong] no, there is a "no" branch under "NOT Preferred to Preferred" to 
cover "PREFERRED to NOT PREFERRED". Anyway, the diagram discription should 
be "NOT Preferred to Preferred" which is wrong in v-04.

> formal style would be helpful.
[Lizhong] this is a usecase to give an example, so we make it "loose".

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 19 Jun 2012 16:16:08 +0100

Hi, Lizhong.

On Tue, 2012-06-19 at 21:48 +0800, Lizhong Jin wrote:
> 
> Hi Elwyn, 
> Thank you for the review. It seems you are reviewing v-03, not v-04,
> but some comments are for v-04. I am confused.
Yes, I started reviewing v03 but had to stop because of other tasks and
came back to v04.  I though I had revisited all my old commnets and
updated them, but clearly not.
>  See my reply inline below. 
> 
> Regards 
> Lizhong 
>   
> 

> [Lizhong] this draft is to solve the case to change a PW from c=0 to
> c=1, that means one PE should change its use of control word from NOT
> PREFERRED to PREFERRED. RFC4447 is already there and deployed, and the
> PE will not always send its locally configured preferrence according
> RFC4447, see PE1 behavior in section 2 step 1&2. That's why we could
> not simply apply the mechanism at the end of section 3. Hope it is
> clear. 
There are two issues here:
- Clarity: RFC 4447 does not have any discussion of what might happen if
the configuration value changes.  The draft focusses on on transition
direction but does not mention the other except for one paragaph right
at the end of s3.  It is therefore reasonable that somebody looking at
this draft would wonder 'what about the other transition direction?'.
Whether or not anything needs to be done it would save people wondering
if you put in a sentence in the introduction to explain that the other
direction is not (or is) a problem.
- Technical: The paragraph in s3 implies that the PREFERRED to NOT
PREFERRED direction will result in some part of the RFC 4447 protocol
being (re-)invoked.  What part is not made very clear.  As far as I can
see sending more messages other than Label Release or Label Withdraw for
this PW is not part of the RFC 4447 protocol and hence will cause an
error.  Alternatively if it isn't reinvoked, the PW will continue to use
control words.  Please explain what is going on here.  The fact that RFC
4447 has been deployed doesn't explain what is going on.
> session. I do not see a problem here. But we do have a note in section
> 3 for multi-segment PW for sequence processing. 
There are several network round trips in the message exchanges.  The
protocol and the configuration mechanism in a PE are potentially
separate threads.  There is scope, depending on the implementation, for
the user at the 'remote' PE to change the configuration during the
message exchange making for a potential race condition.
>             and wait until it receives a Label Release message from
What does it send first if both must be sent?  The text in the rest of
the document implies withdraw then release.  This new text sort of
implies release then withdraw but isn't really clear.
> [Lizhong] we follow RFC6073, and passive role is only applied for the
> PW FEC, other cases are out of scope. 
Why? This needs an explanation. Also this doesn't cover the point about
whether reconfig of an S-PE is allowed and how this squares with the
passive role.
> SHOULD means highly recommended. We do not meet any problem when
> implementing RFC6073. Do you suggest to change this to MUST? 
Whenever a specification includes a 'SHOULD' the question arises of what
alternatives there might be and what is the reason for preferring the
suggested solution.  In the original setup, it is fairly clear that life
is easier letting setup progress from  one end to the other (although
this is not spelt out - I would have argued for this had  I reviewed the
doc).  For the configuration change this is less obvious.  Regarding the
point about reconfig of the  S-PE, it is going to make life more
complicated if the S-PE has to tell the T-PE to be active so it can be
passive.  I would therefore argue that probably the notion of passivity
is irrelevant to the transition use case.  Whether it should be SHOULD
or MUST is therefore moot.

> [Lizhong] I removed brackets and do not intend to contain citations
> here. It seems the citations are generated automatically by IETF.
> Could the round brackets solve this? Or are you referring v-03? 
(leftover from 03)
> [Lizhong] are you reviewing v-03 of the draft? In v-04, the abstract
> has been revised in v-04.
(leftover from 03)
> [Lizhong] are you reviewing v-03 of the draft? In v-04, the abstract
> has been revised in v-04.
(leftover from 03)
> [Lizhong] has been revised in v-04.
yes.
> [Lizhong] has been revised in v-04.
Not as far as I can see.
> [Lizhong] configurable is right. 
Leave that one to the RFc Editor.
> [Lizhong] no, the case is that operator deploys PW with control word
> used in the first phase. In the second phase, they want to upgrade
> their PW service to use control word. Two different deployment
> timeframes.
That is what my sentence says.
> Multi-segment case is fully inherited from single-segment case. It
> would be redundancy to have sub-sections here. 
I disagree strongly.  The multi-segment case affects the other RFC and
needs to be made to stand out so that implementors can see where the
changes occur.  The PREFERRED to NOT PREFERRED case also ought to be
separated whether or not I am right about this case. 
> [Lizhong] much difference here?
Yes. How it reads in English.  There are many missing definite articles
and indefinite articles that make the text read very badly for a native
English speaker.  I understand that this is a very difficult aspect for
someone who has a first language that does not employ articles in the
way that English does.
> [Lizhong] accept, and I do not see "remote PR".
should have been 'remote PE'.
> [Lizhong] do not see much difference here. Of couse the "label
> release" should be capitalized.
Your form implies that that the action can occur as soon as the message
starts to be received (as in 'the radio is receiving a programme').
This is not the case - the action can occur only when the whole message
has been received.  
> [Lizhong] no, the procedure here is not right. The local PE MUST send
> a label request message, not label mapping.
Try:
The local PE MUST send a Label Request message to the peer PE  and then
wait until a Label Mapping message is received containing the peer's
current configured preference for usage of the control word. 
> [Lizhong] no, there is a "no" branch under "NOT Preferred to
> Preferred" to cover "PREFERRED to NOT PREFERRED". Anyway, the diagram
> discription should be "NOT Preferred to Preferred" which is wrong in
> v-04. 
> 
> >

---

From: Lizhong Jin<[email-masked]>
Date: Wed, 20 Jun 2012 01:17:20 +0800

Hi Elwyn,
Thank you for the prompt reply. See inline below.

Lizhong

> direction is not (or is) a problem.
[Lizhong] accept. Add following:
When PE changes the preference for the use of control word from PREFERRED 
to NOT PREFERRED, it should follow [RFC4447], and there is no problem.

> 4447 has been deployed doesn't explain what is going on.
[Lizhong] now I understand you concern. The last sentance of s3 is not 
clear. How about the following:
In that case, local PE will always send Label Withdraw message if already 
sending Label Mapping message, and then send new Label Mapping message 
with C-bit value following the procedures defined in [RFC4447].

> message exchange making for a potential race condition. 
[Lizhong] we discussed the race condition on the PWE3 maillist from Spike, 
and for multi-segment PW, we add a note to ensure the sequence processing 
for implementation.

> implies release then withdraw but isn't really clear.
[Lizhong] both should be sent, and does not require the sending sequence. 
The two messages does not have dependence.

> or MUST is therefore moot.
[Lizhong] how about the following? Because we just refer to RFC6073, and 
does not add anything new.
An initial passive role is defined in [RFC6073] for S-PE.

> > [Lizhong] has been revised in v-04.
[Lizhong] write "pseudowire" directly in the text, not PW.

> That is what my sentence says.
[Lizhong] ok.

> separated whether or not I am right about this case. 
[Lizhong] how about only divide multi-segment? The case of PREFERRED to 
NOT PREFERRED case is only for reference, and the text is not many.
> someone who has a first language that does not employ articles in the
[Lizhong] ok
> should have been 'remote PE'.
[Lizhong] ok
> This is not the case - the action can occur only when the whole message
[Lizhong] ok, thanks.

> current configured preference for usage of the control word. 
[Lizhong] ok

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 21 Jun 2012 13:38:27 +0100

Hi, Lizhong.

I have removed the bits that we are agreed on to shorten the mail a bit.

I don't think we have converged just yet.

Regards,
Elwyn

On Wed, 2012-06-20 at 01:17 +0800, Lizhong Jin wrote:
> When PE changes the preference for the use of control word from
> PREFERRED to NOT PREFERRED, it should follow [RFC4447], and there is
> no problem. 

See below...
> In that case, local PE will always send Label Withdraw message if
> already sending Label Mapping message, and then send new Label Mapping
> message with C-bit value following the procedures defined in
> [RFC4447]. 

I think we have reached the heart of the issue here:  RFC 4447 does not
mention changing the control word configuration.  The combination of the
existing text in the draft and what you have just weittrn above
indicates that *in both transition directions* the PE changing
configuration notifies its peer by sending a Label Withdraw. It is not
immediately obvious to me that you could deduce this from RFC 4447 - if
it is then there needs to be a pointer to the relevant section in RFC
4447 to enlighten the ignorant like me.  Otherwise the PREFERRED to NOT
PREFERRED transition is *not* just 'follow the RFC 4447 procedures'.

If I now understand correctly, the situation is as follows:
- in both cases when there is a control word preference transition, send
a Label Withdraw.
- in the NOT PREFERRED to PREFERRED case send Label Release also (order
not important), wait for a responses from peer, then send Label Request
and negotiate use of control word using Label Mapping C bit as for a new
PW (might result in either using or not using control word depending on
state in peer).
- in the PREFERRED to NOT PREFERRED case, just negotiate C bit to 0
using Label Mapping - label will be maintained. [Need to check that RFC
4447 is expecting/will allow this sequence.]

If I have this straight, I think that the PREFERRED to NOT PREFERRED
case needs some more words in s3 and an introduction in s2. (And it
would be easier to understand with this case in a separate sub-section -
sorry to harp on about this).   

> [Lizhong] we discussed the race condition on the PWE3 maillist from
> Spike, and for multi-segment PW, we add a note to ensure the sequence
> processing for implementation.
I look forward to the revised text.
> [Lizhong] both should be sent, and does not require the sending
> sequence. The two messages does not have dependence. 
In that case, it is important to say so.
> [Lizhong] how about the following? Because we just refer to RFC6073, and does not add anything new. 
I can't see that this really helps.
There are still two points at issue here:
- Why are the cases other than the one in RFC 4447 that refers to a
passive S-PE out of scope?  There aren't any statements to this effect
in the document.
- It is difficult for a S-PE that has its control word configuration
change to act passively.  If it is really passive than nothing will
happen until the label is withdrawn.  Otherwise it can't be descibed as
passive for this action.  The text in the current draft actually
describes what is specified in RFC 6073 when talking 'passive' rather
than explaining what happens when the control word configuration
changes.
> [Lizhong] write "pseudowire" directly in the text, not PW. 
There are lots of instances of PW still left in v04. Expand acronym =>
define what it means on first usage i.e pseudowire (PW).  Same for the
various other acronyms that aren't defined in the text.

> NOT PREFERRED case is only for reference, and the text is not many.
That is so, but it is a change of subject and the fact that it will then
be in the table of contents makes it easier for implementors to find the
relevant text.  I wouldn't call it 'redundant'.

> > > discription should be "NOT Preferred to Preferred" which is wrong in
Need to check it reflects the Label Withdraw message needed in the
PREFERRED to NOT PREFERRED case.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 21 Jun 2012 14:56:07 +0100

Bringing this to the attention of the PWE3 WG
since that need to know that this discussion is happening
and will have a view as to what is already well
known in terms of RFC4447 behavior and what
needs clarification via this draft.

Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Lizhong Jin<[email-masked]>
Date: Thu, 21 Jun 2012 22:43:54 +0800

Hi Elwyn,
Please see inline below.

Thanks
Lizhong

Elwyn Davies <[email-masked]> wrote 2012/06/21 20:38:27:

> > > > > 4447 procedure applies. Clearly, if the PW is not using the 
control
> > > > word
> > > > > then there is nothing to do.  On the other hand, inspection of 
s6.2
> > > > of
> > > > > RFC4447 indicates that once the two PEs have agreed on c = 1, 
'setup
> > > > is
> > > > > 4447). So, what procedure is to be used? And what implications 
does
> > > > this
> > > > > have for backwards compatibility?  Wouldn't it be generally 
simpler
> > > > to
[Lizhong] as an engineer, I interpret the configuration changing as 
deleting and configuring again. Control word configuration changing means 
deleting the old control word, and then configuring the new control word, 
that means deleting PW configuration, and configuring new PW configuration 
again. RFC4447 section 5.4.1 describe the procedure of PW deletion and 
configuration. When you apply the above procedure to PREFERRED to NOT 
PREFERRED transition, it works well, while for NOT PREFERRED to PREFERRED 
transition, there is a problem.
What if I add some description of the meaning of control word changing at 
the end of s3, so as to make it clear?

> sorry to harp on about this). 
[Lizhong] your above description is totally right. How about changing the 
end of s3 as below:
When Local PE changes the use of control word from PREFERRED to NOT 
PREFERRED, the local PE would be able to negotiate the Control Word to be 
not used by deleting the PW configuration with PREFERRED use of control 
word,  and configuring the PW again with NOT PREFERRED use of control 
word. All of these procedures have been defined in [RFC4447] section 
5.4.1.

> I look forward to the revised text.
[Lizhong] How about add the following in s3: for the local PE, before 
processing new configuration changing, the above message exchange process 
should be finished.

> > > >        -i.  PE MUST send a Label Release message to remote PE. If 
a
> > > > PE 
> > > >             has previously sent a Label Mapping message to a 
remote
> > > > PE, 
> > > >             it MUST also send a Label Withdraw message to the 
remote
> > > > PE, 
> > > >             and wait until it receives a Label Release message 
from
> In that case, it is important to say so.
[Lizhong] I will add a sentence in point "i" to say so. How about below:
Note: above Label Release message and Label Withdraw message sending does 
not require specific sequence.

> > > > > - Does this mean that changing the configuration of an S-PE 
would
> > > > not
[Lizhong] the passive role is not for any specific cases. The passive role 
is for the processing of message (e.g, label mapping, label request). I 
will explicitly say that in the section.

> than explaining what happens when the control word configuration
[Lizhong] the control word configuration changing talking about in this 
draft only happens on T-PE, not S-PE. The S-PE is a passive role for the 
message processing. I will make this clear in the draft.

[Lizhong] accept

> > > > >   The intention of the control word negotiation is that the 
control
> > > > word
> > > > > will be used when both endpoints are configured with control 
word
> > > > usage
> > > > > s3, last para/Appendix A:  The diagram doesn't cover the 
PREFERRED
> > > > to
[Lizhong] ok, I could add Label Withdraw there.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 21 Jun 2012 16:08:37 +0100

Please can you continue this conversation with the PWE3
WG in the cc list so that it has the correct level of expert
oversight.

Thanks

Stewart

On 21/06/2012 15:43, Lizhong Jin wrote:
> > > > > > then there is nothing to do.  On the other hand, inspection 
> of s6.2
> > > > > of
> > > > > > RFC4447 indicates that once the two PEs have agreed on c = 
> 1, 'setup
> > > > > is
> > > > > > 4447). So, what procedure is to be used? And what 
> implications does
> > > > > this
> deleting and configuring again. Control word configuration changing 
> means deleting the old control word, and then configuring the new 
> control word, that means deleting PW configuration, and configuring 
> new PW configuration again. RFC4447 section 5.4.1 describe the 
> procedure of PW deletion and configuration. When you apply the above 
> procedure to PREFERRED to NOT PREFERRED transition, it works well, 
> while for NOT PREFERRED to PREFERRED transition, there is a problem.
> What if I add some description of the meaning of control word changing 
> at the end of s3, so as to make it clear?
>
> >
> [Lizhong] your above description is totally right. How about changing 
> the end of s3 as below:
> PREFERRED, the local PE would be able to negotiate the Control Word to 
> be not used by deleting the PW configuration with PREFERRED use of 
> control word,  and configuring the PW again with NOT PREFERRED use of 
> control word. All of these procedures have been defined in [RFC4447] 
> section 5.4.1.
>
> >
> > > > >
> > > > > >
> > > > > > Minor issues:
> processing new configuration changing, the above message exchange 
> process should be finished.
>
> > >
> > >
> > > > >
> > > > > >
> > > > >        -i.  PE MUST send a Label Release message to remote PE. 
> If a
> > > > > PE
> Note: above Label Release message and Label Withdraw message sending 
> does not require specific sequence.
>
> > >
> > > > >
> > > > > >
> [Lizhong] the passive role is not for any specific cases. The passive 
> role is for the processing of message (e.g, label mapping, label 
> request). I will explicitly say that in the section.
>
> [Lizhong] the control word configuration changing talking about in 
> this draft only happens on T-PE, not S-PE. The S-PE is a passive role 
> for the message processing. I will make this clear in the draft.
>
> > >

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 21 Jun 2012 15:09:13 +0000

Elwyn, Stewart and all,

I do not see any technical issues with the proposed solution for PREFERRED --> NOT PREFERRED configuration change in draft-ietf-pwe3-cbit-negotiation.
To the best of my understanding, it does not really require any additions to the procedures defined in RFC 4447 and would work like following:

1. I assume that originally the two PEs have agreed to use the CW. (If they didn't because the remote PE did not want to support it, there is nothing to re-negotiate).
2. Local PE (where the configuration of the PW endpoint has changed):
	- Sends a Label Withdraw message for its original PW label mapping (where C-bit has been set)
	- Waits for the Label Release acknowledging this Label Withdraw message as mandated by 5036
	- Sends a Label Mapping message with the C-bit cleared.
3. Remote PE, upon receiving the new Label Mapping with the C-bit cleared does what RFC 4447 says, namely:
	- Withdraws its original Label Mapping with C-bit 
	- Waits for Label Release acknowledging this withdrawal
	- Sends a new Label Mapping message with C-bit cleared to the Local PW.
4. At this moment re-negotiation is complete.

This said, adding an explicit description to the text could be useful. But IMHO this is an editorial issue, not a technical one.

My 2c,
     Sasha

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stewart Bryant
> Sent: Thursday, June 21, 2012 4:56 PM
> To: Elwyn Davies
> Cc: [email-masked]; General Area Review
> Team; Lizhong Jin; pwe3; [email-masked]
> Subject: Re: [PWE3] Gen-art last call review of draft-ietf-pwe3-cbit-
> negotiation-04
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.