Re: [PWE3] more comments on draft-jin-pwe3-cbit-negotiation-03

[[e-mail]]

Hi Luca,
Thank you for the comments. 

If I understand correctly, we have discussed the possible race conditions 
in rare cases before, which is raised by Spike. And if we assume that the 
remote T-PE possiblly receive label request before label withdraw in MS-PW 
case, then local T-PE sends label request after receiving label release 
will not solve the issue.
T-PE1-------S-PE2-------S-PE3------T-PE4
If T-PE4 is the local T-PE, and send label withdraw to S-PE3; S-PE3 will 
recieve the label withdraw, reply with label release and send label 
withdraw to upstream; then T-PE4 will send label request to S-PE3. But if 
S-PE will not process the message by sequence (for example, S-PE2 receive 
label withdraw, delay to reply with label release and send label withdraw 
upstream, receive and process label request and send label request to 
upstream, then reply with label release and send label withdraw upstream), 
it is still possible for T-PE1 to receive label request before label 
withdraw in above MS-PW case.

Then we make one requriement for the message processing on S-PE to avoid 
such race condition in the draft section 3 paragraph 6: As local T-PE will 
send label withdraw before sending label request to remote peer, the S-PE 
MUST send the label withdraw upstream before it advertises the label 
request. Since TCP is as sequence transmission protocol, we require the 
S-PE to process the LDP message by: first received, first processed, which 
I think complys with possiblly most current implementation. When S-PE 
receive the label withdraw, it should process this message to send a label 
release as a response and a label withdraw to upstream S-PE/T-PE, then 
process the next LDP message, e.g, the label request message. By applying 
such behavior, the race condition can be avoided. However, it would be 
more secure to require PE to send label request after receiving label 
release.

Other comments, please see in line below.

Regards
Lizhong


-------send by Luca 
Martini----------------------------------------------------
Authors,

In section 3 on page 4 is the following text :

"The procedure of PE1 and PE2 for the case in figure 1 should be as
   follows:

       1. PE2 changes locally configured control word to PREFERRED.

       2. PE2 will then send label withdraw message to PE1.

       3. PE2 MUST send label request messages to PE1 although it
          already received the label mapping with C-bit=0.

       4. PE1 will send label release in reply to label withdraw message
          from PE2.

       5. PE1 will send label mapping message with C-bit=1 again to PE2
          (Note: PE1 MUST send label mapping with locally configured CW
           parameter).

       6. PE2 receives the label mapping from PE1 and updates the remote
          label binding information.  PE2 MUST wait for PE1 label
          binding before sending its label binding with C-bit set, only
          if it previously had a label binding with C-bit = 0 from PE1.

       7. PE2 will send label mapping to PE1 with C-bit=1.
"

First of all the steps above are asynchronous, so it seems that step 4
should appear before step 3 or the old label mapping might be sent.
Step 5 is in response to step 3 , but that is not clear from the above 
list.
[Lizhong] if agree, according to the explanation at the beginning of this 
email, we could swap step 3 and 4 for more secure. And yes, step 5 should 
be detailed to explicitly say the response of step 3.

Also what happens if PE1 cannot support the CW ?  The above descriptions
assumes PE1 can support the CW.
[Lizhong] the above description is the example of figure 1. We can add a 
sentance after the example as: If PE1 does not support the CW, following 
the above procedure, PE2 will receive the label mapping from PE1 with 
C-bit=0, and send label mapping to PE1 with C-bit=0. The CW negotiation 
result is still right.

Also this label withdraw + label request procedure is fully backward 
compatible with previous implementations. The document should explain
this point.
[Lizhong] agree, and to added in the updated draft.
 
The label withdraw should really wait for the label release, as in the
case of MS-PWs , sending an immediate label request can cause a race
condition , and result in the wrong state.
[Lizhong] do you mean the label request should wait for the label release, 
not label withdraw? And explained at the beginning of this email. And I 
tend to add more detail to make it clear in section 3: when S-PE receive 
the label withdraw, it should process this message to send a label release 
as a response and a label withdraw to upstream S-PE/T-PE, then process the 
next receving LDP message, e.g, the label request message.


Thanks.
Luca
 
 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.