Subject: Re: [PWE3] WG Poll on draft-jin-pwe3-cbit-negotiation-03.txt ( comment )

From: [email-masked]
Date: Thu, 3 Mar 2011 23:41:00 +0800

Luca,
After discussing with the authors, we decide to add the wait for label 
release before sending label request, this wouldn't harm and bring some 
secure.

Then are you OK with the following text?

When Local PE changes its control word from NOT PREFERRED to PREFERRED and 
only if it already received the remote label mapping message with C-bit=0, 
additional procedure will be added as follow:
-i Local PE MUST send a label withdraw message to remote PE if it has 
previously sent a label mapping, and wait until receiving a label release 
from the remote PE.
-ii Local PE MUST send a label request message to remote PE, and wait 
until receiving a label mapping message containing the remote PE 
configured control word setting.
-iii After receiving remote PE label mapping with control word setting, 
Local PE MUST follow procedures defined in [RFC4447] section 6 when 
sending it's label mapping message.

Correspondingly, the modified procedure of PE in figure 1 will be as 
follows:

1. PE2 changes locally configured control word to PREFERRED. 
2. PE2 will then send label withdraw message to PE1. 
3. PE1 MUST send label release in reply to label withdraw message from 
PE2. 
4. Upon receipt of Label release message from PE1, PE2 MUST send label 
request messages to PE1 although it already received the label mapping 
with C-bit=0. 
5. PE1 MUST 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. 

It is to be noted that the above assume that PE1 is configured to support 
CW, however in step 5 if PE1 doesn't support CW, PE1 would send the label 
mapping message with C-bit =0, this would result in PE2 in step 7 sending 
a label mapping with C-bit=0 as per [RFC4447] CW negotiation procedure.

Thanks
Lizhong

------------send by Luca 
Martini-------------------------------------------
Matthew & Andy,

Although I support clarifying this procedure , I believe this document
needs some work.
In section 3 for example :

   When Local PE changes its control word from NOT PREFERRED to
   PREFERRED and only if it already received the remote label mapping
   message with C-bit=0, additional procedure will be added as follow:

         -i. Local PE sends label withdraw message to the remote if it
             already sends label mapping message, for it has changed its
             control word parameter.

        -ii. Local PE MUST send a label request messages to peer PE to
             get peer's configured control word parameter before sending
             new label mapping message to peer PE.

       -iii. After receiving the new label mapping message from peer PE
             and updating the remote label binding information, the
             Local PE should send label mapping to peer PE according to
             procedures defined in [RFC4447].

What does the item i) mean ? the English is not clear.
Why does the PE have to do ii) ?

All we really need is a statement on how the c-bit negotiation state
machine can be reset if one end has changed "his mind" .

Can we fix this document before  issuing the -00 WG draft version ?

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.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 7 Mar 2011 10:52:22 -0500

Lizhong,

There's been a lot of support for WG adoption of this draft. Please
update the draft to -04 to reflect the discussion on the list (before
the window closes in a week) and we'll announce the adoption in
Prague, followed by having you issue the WG version of the draft.

Thanks,
Andy

On Thu, Mar 3, 2011 at 10:41 AM,  <[email-masked]> wrote:
> -ii Local PE MUST send a label request message to remote PE, and wait until
> receiving a label mapping message containing the remote PE configured
> control word setting.
> Local PE MUST follow procedures defined in [RFC4447] section 6 when sending
> it's label mapping message.
>
> 3. PE1 MUST send label release in reply to label withdraw message from PE2.
> request messages to PE1 although it already received the label mapping with
> C-bit=0.
> 5. PE1 MUST send label mapping message with C-bit=1 again to PE2 (Note: PE1
> MUST send label mapping with locally configured CW parameter).
> 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.
> mapping message with C-bit =0, this would result in PE2 in step 7 sending a
> label mapping with C-bit=0 as per [RFC4447] CW negotiation procedure.
>
> Thanks
> Lizhong
>
>
> ------------send by Luca Martini-------------------------------------------
> Matthew & Andy,
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>
>

---

From: Luca Martini <[email-masked]>
Date: Mon, 07 Mar 2011 12:35:08 -0700

Sorry for the late response , comments below:
Luca

On 03/03/11 08:41, [email-masked] wrote:
> release before sending label request, this wouldn't harm and bring
> some secure.
>
> When Local PE changes its control word from NOT PREFERRED to PREFERRED
> and only if it already received the remote label mapping message with
> C-bit=0, additional procedure will be added as follow:
> previously sent a label mapping, and wait until receiving a label
> release from the remote PE.
> -iii After receiving remote PE label mapping with control word
> setting, Local PE MUST follow procedures defined in [RFC4447] section
> 6 when sending it's label mapping message.
>
Ok the above text is fine.
However you need to address the case when the Local PE changes its
control word from  PREFERRED to NOT PREFERRED as well.

> 5. PE1 MUST 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.
No, the above procedure will result in a LDP error and session shutdown.
In LDP you  cannot "update" the FEC.  In step 5 PE1 can only send the
label mapping message it has previously sent. So PE1 cannot change the
C-Bit without first issuing a label withdraw.

> It is to be noted that the above assume that PE1 is configured to
> support CW, however in step 5 if PE1 doesn't support CW, PE1 would
> send the label mapping message with C-bit =0, this would result in PE2
> in step 7 sending a label mapping with C-bit=0 as per [RFC4447] CW
> negotiation procedure.
>
What is needed is some way to send a message to the remote PE that the
C-bit negotiation procedure needs to be re-started.

Solution 1

one way to get this procedure working is to have PE2 release the label
mapping previously sent by PE1.
If you do this today, most implementations will simply go to a dead
state requiring operator intervention.
What should happen is that upon receiving the label release , PE1 should
withdraw it's label mapping , and reset the c-bit negotiation state
machine , and re-advertise the new label mapping restarting the
procedure described in rfc4447 from the beginning.

Solution 2

Whenever a PE withdraws a FEC mapping , the remote PE resets the C-bit
negotiation procedure. If this results in a different C-bit local value
then previously advertised , the local PE MUST go though a label
withdraw/label release/label advertisement cycle.

Both solutions above should work within the  LDP rules and are backward
compatible. I like solution 2 a bit better.

Luca

---

From: [email-masked]
Date: Wed, 9 Mar 2011 00:06:45 +0800

Luca,
Thank you for the comments. Please see my reply in line.

Regards
Lizhong

> control word from  PREFERRED to NOT PREFERRED as well.
[Lizhong] yes, and already addressed in section 3 at the beginning of 
page4 of this draft.

> C-Bit without first issuing a label withdraw.
[Lizhong] I don't think such procedure will result in a sesion down 
according to RFC5036. Actually, this is what we want to standardize for 
the PW-FEC processing, to add a way of updating PW-FEC. Another way to 
update PW-FEC is to let PE1 send label withdraw (maybe with wrong C-bit) 
before sending label mapping in step 5, as a reply to the label request. 
But this will lead to additional control message load and is not aligned 
with "receiving label request" behavior in A.1.1 in RFC5036, which makes 
us to abandon it.

> procedure described in rfc4447 from the beginning.
[Lizhong] This solution has been discussed before on PWE3 mail list (
http://www.ietf.org/mail-archive/web/pwe3/current/msg11484.html), and I 
also do not prefer this option.

> withdraw/label release/label advertisement cycle.
[Lizhong] Solution 2 has already been discussed before on mail list (
http://www.ietf.org/mail-archive/web/pwe3/current/msg11497.html), and also 
addressed in 00 version of this draft (
http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-00). 
Unfortunately, the mechanism can not work in MS-PW case.

> > 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.

---

From: Luca Martini <[email-masked]>
Date: Tue, 08 Mar 2011 13:40:13 -0700

On 03/08/11 09:06, [email-masked] wrote:
> according to RFC5036. Actually, this is what we want to standardize
> for the PW-FEC processing, to add a way of updating PW-FEC.
you cannot Just "update" a FEC , as it leads to confusion. The receiving
PE will not know how to handle the packet. The label MUST be released ,
and a new label advertised.
> Another way to update PW-FEC is to let PE1 send label withdraw (maybe
> with wrong C-bit) before sending label mapping in step 5, as a reply
> to the label request. But this will lead to additional control message
> load and is not aligned with "receiving label request" behavior in
> A.1.1 in RFC5036, which makes us to abandon it.
>
I do not see how the explanations in appendix A.1.1 in RFC5036 apply to
this problem.

> [Lizhong] This solution has been discussed before on PWE3 mail list
> (http://www.ietf.org/mail-archive/web/pwe3/current/msg11484.html), and
> I also do not prefer this option.
>
No I disagree with Sasha. A label release can be sent anytime , and that
is a local PE decision. Liberal label retention only implies that labels
are usually stored. A label release can be sent for many reasons , like
for example no more local memory available.

> [Lizhong] Solution 2 has already been discussed before on mail list
> (http://www.ietf.org/mail-archive/web/pwe3/current/msg11497.html), and
> also addressed in 00 version of this draft
> (http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-00).
Actually it works fine in the MS-PW case. S-PEs do not care how many
times the label is withdrawn and advertised.
This solution works perfectly fine within all existing LDP rules.

Luca

---

From: [email-masked]
Date: Thu, 17 Mar 2011 11:07:00 +0800

Hi Andy,
Thank you very much. We have uploaded the 04 version. Please get it from 
the following link:
http://tools.ietf.org/html/draft-jin-pwe3-cbit-negotiation-04.txt

Regards
Lizhong

> > release before sending label request, this wouldn't harm and bring 
some
> > When Local PE changes its control word from NOT PREFERRED to PREFERRED 
and
> > previously sent a label mapping, and wait until receiving a label 
release
> > -ii Local PE MUST send a label request message to remote PE, and wait 
until
> > -iii After receiving remote PE label mapping with control word 
setting,
> > Local PE MUST follow procedures defined in [RFC4447] section 6 when 
sending
PE2.
> > request messages to PE1 although it already received the label mapping 
with
> > 5. PE1 MUST send label mapping message with C-bit=1 again to PE2 
(Note: PE1
> > 6. PE2 receives the label mapping from PE1 and updates the remote 
label
> > It is to be noted that the above assume that PE1 is configured to 
support