Subject: Re: [PWE3] Control Word Problem in RFC4447

From: venkatesan mahalingam <[email-masked]>
Date: Tue, 20 Jul 2010 18:23:53 +0530

*Hi,*
*PE2 should send the label WR message for label advertised and label release
message for the PW label received from peer PE1 upon PW is re-signalled with
CW PREFERRED at PE2.*
**
*I think, this will solve the problem stated by you.*
**
*Thanks,*
*Venkat.*

   - *To*: Alexander Vainshtein <Alexander.Vainshtein at
ecitele.com<[email-masked]>>

   - *Subject*: Re: [PWE3] Control Word Problem in RFC4447
   - *From*: lizhong.jin at zte.com.cn <[email-masked]>
   - *Date*: Tue, 20 Jul 2010 18:49:16 +0800
   - *Cc*: "pwe3 at ietf.org <[email-masked]>" <pwe3 at
ietf.org<[email-masked]>>,
   "lmartini at cisco.com <[email-masked]>" <lmartini at
cisco.com<[email-masked]>>,
   "erosen at cisco.com <[email-masked]>" <erosen at
cisco.com<[email-masked]>>,
   "andrew.g.malis at verizon.com <[email-masked]>"
<andrew.g.malis
   at verizon.com <[email-masked]>>
   - *Delivered-to*: pwe3 at core3.amsl.com <[email-masked]>
   - *In-reply-to*: <A3C5DF08D38B6049839A6F553B331C76D37FFF5663 at
   ILPTMAIL02.ecitele.com<[email-masked]>>

   - *List-archive*: <http://www.ietf.org/mail-archive/web/pwe3>
   - *List-help*:
<mailto:[email-masked]?subject=help<[email-masked]?subject=help>>

   - *List-id*: Pseudo Wires Edge to Edge <pwe3.ietf.org>
   - *List-post*: <mailto:[email-masked] <[email-masked]>>
   - *List-subscribe*: <https://www.ietf.org/mailman/listinfo/pwe3>, <
   mailto:[email-masked]?subject=subscribe<[email-masked]?subject=subscribe>>

   - *List-unsubscribe*: <https://www.ietf.org/mailman/listinfo/pwe3>, <
   mailto:[email-masked]?subject=unsubscribe<[email-masked]?subject=unsubscribe>>

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

Hi Sasha,
Yes, the previous PW will be tear-down which is caused by PE2 sending
withdraw of PW. But PE1 will not withdraw the PW label in this case, and PE2
will retain the label advertised by PE1. This is because PW setup mechanism
uses liberal label retention mode.
PE2 will negotiate the CW according to the previous CW (=0) advertised by
PE1. Then PE2 will send label mapping with CW=0.

BR
Lizhong

Alexander Vainshtein <Alexander.Vainshtein at ecitele.com> wrote on
2010-07-20 18:20:23:

> Lizhong and all,
> AFAIK, C-bit is part of the PW FEC element (both PW ID FEC (128) and
> Generalized PE FEC (129)).
> As a consequence, changing local preference for CW at one of the end
> points results, first of all, in tear-down of the previous PW. After
> that new PW will be set up  using new set of CW preferences.
>
> Does this address your problem?
>
> Regards,
>      Sasha
>
> From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On Behalf
Of
> lizhong.jin at zte.com.cn
> Sent: Tuesday, July 20, 2010 12:02 PM
> To: lmartini at cisco.com
> Cc: pwe3 at ietf.org; erosen at cisco.com; andrew.g.malis at verizon.com
> Subject: [PWE3] Control Word Problem in RFC4447
>
>
> Dear Luca and all,
> In RFC4447, each PW endpoint have the capability of being
> configurable with a parameter that specifies whether the use of the
> control word is PREFERRED or NOT PREFERRED. This kind of mechanism
> will not work in one use case:
> PE1-----------PE2
> 1. Initially, PE1 CW is PREFERRED, and PE2 CW is NOT PREFERRED.
> 2. The negotiation result of PW CW is not supported, and PE1 send
> label mapping with CW=0 finally.
> 3. Then PE2 changes its CW configuration to PREFERRED.
> 4. According to the CW negotiation mechanism, the received label
> mapping from PE1 signals CW=0, then PE2 still send label mapping with
CW=0.
> 5. The negotiation result of PW CW is still not supported, but the
> CW configuration on both PE1 and PE2 is PREFERRED.
>
> Did I miss something important in this RFC? I can not work out this
> puzzle for the above use case.
>
> What's worse, it seems difficult to solve this problem for SS-PW and
> MS-PW based on current CW negotiation mechanism, unless we change
> the CW to be not configurable, and default value is PREFERRED which
> can be degraded to NOT PREFERRED by negotiation automatically.
>
> BR
> Lizhong
>
> --------------------------------------------------------
> 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.

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

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: [email-masked]
Date: Tue, 20 Jul 2010 22:22:02 +0800

Hi Venkat,
Sounds reasonable, but PE2 can not identify whether it is necessary to 
send the release message. It is not correct for PE2 to send release 
message for all cases. I mean PE2 should send release message only for 
this special case, but it can not identify this case (PE1 CW is PREFERRED, 
but send mapping with CW=0).

BR
Lizhong

venkatesan mahalingam <[email-masked]> wrote on 2010-07-20 20:53:53:

> Hi,
> PE2 should send the label WR message for label advertised and label 
> release message for the PW label received from peer PE1 upon PW is 
> re-signalled with CW PREFERRED at PE2.
>  
> I think, this will solve the problem stated by you.
>  
> Thanks,
> Venkat.
> To: Alexander Vainshtein <Alexander.Vainshtein at ecitele.com> 
> Subject: Re: [PWE3] Control Word Problem in RFC4447 
> From: lizhong.jin at zte.com.cn 
> Date: Tue, 20 Jul 2010 18:49:16 +0800 
> Cc: "pwe3 at ietf.org" <pwe3 at ietf.org>, "lmartini at cisco.com" <
> lmartini at cisco.com>, "erosen at cisco.com" <erosen at cisco.com>, "
> andrew.g.malis at verizon.com" <andrew.g.malis at verizon.com> 
> Delivered-to: pwe3 at core3.amsl.com 
> In-reply-to: <A3C5DF08D38B6049839A6F553B331C76D37FFF5663 at 
> ILPTMAIL02.ecitele.com> 
> List-archive: <http://www.ietf.org/mail-archive/web/pwe3> 
> List-help: <mailto:[email-masked]?subject=help> 
> List-id: Pseudo Wires Edge to Edge <pwe3.ietf.org> 
> List-post: <mailto:[email-masked]> 
> List-subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <
> mailto:[email-masked]?subject=subscribe> 
> List-unsubscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <
> mailto:[email-masked]?subject=unsubscribe> 
> 
> Hi Sasha, 
> Yes, the previous PW will be tear-down which is caused by PE2 
> sending withdraw of PW. But PE1 will not withdraw the PW label in 
> this case, and PE2 will retain the label advertised by PE1. This is 
> because PW setup mechanism uses liberal label retention mode. 
> PE2 will negotiate the CW according to the previous CW (=0) 
> advertised by PE1. Then PE2 will send label mapping with CW=0. 
> 
> BR 
> Lizhong 
>   
> 
> > From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] 
> On Behalf Of 
CW=0. 
system.
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.

--------------------------------------------------------
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: Alexander Vainshtein <[email-masked]>
Date: Tue, 20 Jul 2010 17:36:52 +0300

Lizhong,
IMHO PE2 should send a Label Release message to PE1 (for a PW label it received from PE1 for a given PW FEC) every time it sends a Label Withdraw message to PE1 for the PW label it has advertized to it (for the matching PW FEC), i.e. every time it decides to tear-down a PW.

It is not clear, however, whether 4447 mandates that.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 20, 2010 5:22 PM
To: venkatesan mahalingam
Cc: Alexander Vainshtein; [email-masked]
Subject: Re: [PWE3] Control Word Problem in RFC4447

Hi Venkat,
Sounds reasonable, but PE2 can not identify whether it is necessary to send the release message. It is not correct for PE2 to send release message for all cases. I mean PE2 should send release message only for this special case, but it can not identify this case (PE1 CW is PREFERRED, but send mapping with CW=0).

BR
Lizhong

venkatesan mahalingam <[email-masked]> wrote on 2010-07-20 20:53:53:

> > mapping from PE1 signals CW=0, then PE2 still send label mapping with CW=0.

---

From: [email-masked]
Date: Wed, 21 Jul 2010 08:40:08 +0800

Hi Sasha,
In RFC4447 section 3, it is said "LDP’s "liberal label retention" mode 
SHOULD be used". That means PE2 should not send a label release in this 
case.
What's more, let's assume PE2 sends a label release to PE1, then in normal 
LDP procedure [RFC5036], PE1 can not send label mapping which is triggered 
by label release. If we change this process, more problem may be brought 
out which we may have not seen. For example, PE2 may release PW label 
because of lack of label resource, then it is not correct for PE1 to send 
label mapping again to PE2.

BR
Lizhong

Alexander Vainshtein <[email-masked]> wrote on 
2010-07-20 22:36:52:

> Lizhong,
> IMHO PE2 should send a Label Release message to PE1 (for a PW label 
> it received from PE1 for a given PW FEC) every time it sends a Label
> Withdraw message to PE1 for the PW label it has advertized to it 
> (for the matching PW FEC), i.e. every time it decides to tear-down a PW.
> 
> Sounds reasonable, but PE2 can not identify whether it is necessary 
> to send the release message. It is not correct for PE2 to send 
> release message for all cases. I mean PE2 should send release 
> message only for this special case, but it can not identify this 
> case (PE1 CW is PREFERRED, but send mapping with CW=0). 
> 
> BR 
> Lizhong 
> 
> 
> 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.
system.
system.

---

From: venkatesan mahalingam <[email-masked]>
Date: Wed, 21 Jul 2010 17:33:58 +0530

Hi,
Ok, can we think of initiating the label WR message at PE1 upon receiving
the label WR message from PE2 for PW FEC?

Thanks,
Venkat.
2010/7/21 <[email-masked]>

> by label release. If we change this process, more problem may be brought out
> which we may have not seen. For example, PE2 may release PW label because of
> lack of label resource, then it is not correct for PE1 to send label mapping
> again to PE2.
>
> BR
> Lizhong
>
>
> > > ILPTMAIL02.ecitele.com <http://ilptmail02.ecitele.com/>>

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: [email-masked]
Date: Wed, 21 Jul 2010 20:35:20 +0800

Hi Venkat,
Sending label WR by PE1 still can not solve the problem. Because it is 
possible that before PE2 receiving the label WR from PE1, it may already 
send out the new label mapping with CW=0 to PE1.

From my perspective, we should change the CW to be not configurable, and 
default value is PREFERRED which can be degraded to NOT PREFERRED by 
negotiation automatically. Another solution is changing current CW 
negotiation mechanism, which seems a bit difficult for current RFC.

BR
Lizhong

venkatesan mahalingam <[email-masked]> wrote on 2010-07-21 20:03:58:

> Hi,
> Ok, can we think of initiating the label WR message at PE1 upon 
> receiving the label WR message from PE2 for PW FEC?
>  
> Thanks,
> Venkat.
> In RFC4447 section 3, it is said "LDP’s "liberal label retention" 
> mode SHOULD be used". That means PE2 should not send a label release
> in this case. 
> What's more, let's assume PE2 sends a label release to PE1, then in 
> normal LDP procedure [RFC5036], PE1 can not send label mapping which
> is triggered by label release. If we change this process, more 
> problem may be brought out which we may have not seen. For example, 
> PE2 may release PW label because of lack of label resource, then it 
> is not correct for PE1 to send label mapping again to PE2. 
> 
> BR 
> Lizhong 
>   
>

---

From: venkatesan mahalingam <[email-masked]>
Date: Thu, 22 Jul 2010 00:56:19 +0530

Hi,
Yes, you are right. Your solution looks good but need to analyze more.
>From my perspective, we can try the below steps to solve this problem,
1. PE2 sends the label WR message to PE1 upon CW is changed from NOT
PREFERRED to PREFERRED
2. PE1 sends the label release message to PE2
3. PE2 sends the label mapping message with c=1 to PE1
4. PE1 looks up the value of CW (c=1) and checks against the capability, if
the CW is supported by the node PE1 then PE1   should re-signal i.e send
label WR message to withdraw the advertised PW label and then re-advertise
the new label mapping message with c=1 to PE2.

I think, RFC-4447 authors can comment better.

Thanks,
Venkat.

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: [email-masked]
Date: Fri, 23 Jul 2010 00:28:36 +0800

Hi Venkat and all,
It is out of control for step 2&3 which will happen earlier. If PE2 sends 
the label mapping before receiving release message, it will send label 
mapping with CW=0.
And yes, we need the comment from the author of RFC4447.

to Luca,
What's your comment about this problem?

BR
Lizhong

venkatesan mahalingam <[email-masked]> wrote on 2010-07-22 03:26:19:

> 4. PE1 looks up the value of CW (c=1) and checks against the 
> capability, if the CW is supported by the node PE1 then PE1   should
> re-signal i.e send label WR message to withdraw the advertised PW 
> label and then re-advertise the new label mapping message with c=1 to 
PE2.
> Sending label WR by PE1 still can not solve the problem. Because it 
> is possible that before PE2 receiving the label WR from PE1, it may 
> already send out the new label mapping with CW=0 to PE1. 
> 
> From my perspective, we should change the CW to be not configurable,
> and default value is PREFERRED which can be degraded to NOT 
> PREFERRED by negotiation automatically. Another solution is changing
> current CW negotiation mechanism, which seems a bit difficult for 
current RFC.

> > > venkatesan mahalingam <[email-masked]> wrote on

---

From: Luca Martini <[email-masked]>
Date: Fri, 23 Jul 2010 19:48:14 -0600

Lizhong,

I have been aware of this problem for many years. First you should note
that the CW negotiation was designed to support hardware that could not
support CW. Hardware is not supposed to change it's capabilities while
in operation.
Having said that, there is a possible solution , release the pe1 label
at pe2. Once PE1 receives a label release , it can reset the CW
negotiation process , and at it's own discretion re-advertise the label
mapping at a later time. ( ex. shut , no shut command on the AC )
This procedure is already allowed, within the LDP spec. Also this
problem is not a real issue in the real world , or we would have heard
about it 10 years ago from SPs.

I suppose that we could document this and other solutions that also
comply with the LDP spec, like using label request to fetch a FEC
mapping once it has been released, but as I mentioned above, this
problem has not been a significant issue.

Luca

>> venkatesan mahalingam <[email-masked]> wrote on 2010-07-21 
>>     
> 20:03:58:
>   
>>> Hi, 
>>>> (for the matching PW FEC), i.e. every time it decides to tear-down a 
>>>>         
> PW. 
>   
>>>>   
>>>>> PE2 should send the label WR message for label advertised and 
>>>>>           
> label 
>   
>>>>> Cc: "pwe3 at ietf.org" <pwe3 at ietf.org>, "lmartini at cisco.com" 
>>>>>           
> <
>   
>>>>> lmartini at cisco.com>, "erosen at cisco.com" <erosen at 
>>>>>           
> cisco.com>, "
>   
>>>>> this case, and PE2 will retain the label advertised by PE1. This 
>>>>>           
> is 
>   
>>>>> Alexander Vainshtein <Alexander.Vainshtein at ecitele.com> wrote 
>>>>>           
> on 
>   
>>>>> 2010-07-20 18:20:23:
>>>>>
>>>>>           
>>>>>> Lizhong and all, 
>>>>>> AFAIK, C-bit is part of the PW FEC element (both PW ID FEC (128) 
>>>>>>             
> and
>   
>>>>>> As a consequence, changing local preference for CW at one of the 
>>>>>>             
> end
>   
>>>>>> points results, first of all, in tear-down of the previous PW. 
>>>>>>             
> After
>   
>>>>>> Cc: pwe3 at ietf.org; erosen at cisco.com; andrew.g.malis at 
>>>>>>             
>> verizon.com
>>     
>>>>>> configurable with a parameter that specifies whether the use of 
>>>>>>             
> the 
>   
>>>>>> control word is PREFERRED or NOT PREFERRED. This kind of 
>>>>>>             
> mechanism 
>   
>>>>>> 2. The negotiation result of PW CW is not supported, and PE1 
>>>>>>             
> send 
>   
>>>>>> mapping from PE1 signals CW=0, then PE2 still send label mapping
>>>>>>             
>>>> with CW=0. 
>>>>         
>>>>>> 5. The negotiation result of PW CW is still not supported, but 
>>>>>>             
> the 
>   
>>>>>> Did I miss something important in this RFC? I can not work out 
>>>>>>             
> this 
>   
>>>>>> What's worse, it seems difficult to solve this problem for SS-PW 
>>>>>>             
> and
>   
>>>>>> MS-PW based on current CW negotiation mechanism, unless we 
>>>>>>             
> change 
>   
>>>>>> the CW to be not configurable, and default value is PREFERRED 
>>>>>>             
> which 
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Thu, 29 Jul 2010 06:01:48 +0800

Hi Luca,
As we discussed during IETF78, I want to share some of view on the list.
1. I partly agree that hardware is not supposed to change its 
capabilities. But RFC4447 says that CW is configurable.
2. "re-advertise the label mapping at a later time." is not a good 
solution, because you will never know how many time to be delayed.
3. Only two possible solution: 1. CW can not be configurable and with 
default value, 2. the CW negotiation mechanims MUST not be used.
 
I know it is hard to change a technology which has been deployed over more 
than 10 years. But at least, we should make our RFC correct from technical 
point of view. I hope RFC4447 will not lead to any misunderstanding for 
the industry.

As a summary for this technical discussion, RFC4447 does exist some 
problem, and I propose to make this problem clarification somewhere at 
IETF, or even update RFC4447. If there is not a suitable place, then mail 
list is the free place, which has been done now by me. :)

BR
Lizhong Jin

Luca Martini <[email-masked]> wrote on 2010-07-24 09:48:14:

> I have been aware of this problem for many years. First you should 
> note that the CW negotiation was designed to support hardware that 
> could not support CW. Hardware is not supposed to change it's 
> capabilities while in operation.
> Having said that, there is a possible solution , release the pe1 
> label at pe2. Once PE1 receives a label release , it can reset the 
> CW negotiation process , and at it's own discretion re-advertise the
> label mapping at a later time. ( ex. shut , no shut command on the AC )
> problem is not a real issue in the real world , or we would have 
> heard about it 10 years ago from SPs.
> 

system.
system.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 28 Jul 2010 19:13:45 -0400

I¹d agree with Lizhong Jin¹s points below. Releasing the label is not a
great option as it disrupts the service(s) using that PW.  This discussion
of whether or not to use the CW etc... and the confusion around how it
should be used (negotiated or not, whether to punt on the labels, etc...) is
just another example of why operators at the last PWE3 meeting voiced what
seemed like overwhelming support for making the  CW mandatory going forward.
If it is mandatory, then there is no confusion about whether or not it is
used; very simple. *)

    --Tom

On 7/28/10 6:01 PM, "[email-masked]" <[email-masked]> wrote:

> 1. I partly agree that hardware is not supposed to change its capabilities.
> But RFC4447 says that CW is configurable.
> 2. "re-advertise the label mapping at a later time." is not a good solution,
> because you will never know how many time to be delayed.
> 3. Only two possible solution: 1. CW can not be configurable and with default
> value, 2. the CW negotiation mechanims MUST not be used.
>  
> point of view. I hope RFC4447 will not lead to any misunderstanding for the
> industry. 
> 
> As a summary for this technical discussion, RFC4447 does exist some problem,
> and I propose to make this problem clarification somewhere at IETF, or even
> update RFC4447. If there is not a suitable place, then mail list is the free
> place, which has been done now by me. :)
> 
> BR 
> Lizhong Jin 
> 
> 
>> > In RFC4447 section 3, it is said "LDP¹s "liberal label retention"
> 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.