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

From: Raymond Key <[email-masked]>
Date: Fri, 13 Aug 2010 11:19:14 +1000

I fully agree with Tom. From a network operator perspective, "Simple" is of critical importance.

Raymond Key 

> Thomas D. Nadeau <[email-masked]> wrote:
> 
> 
>      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:
> 
> > 
> > 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:
> > 
> >> > [email-masked] wrote:
> >> > 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?
> >> > 
> >> >   
> >> > 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
> >> > 
> > 
> >> > BR
> >> > Lizhong
> >> >  
> >> > 
> >> > venkatesan mahalingam <[email-masked]> wrote on 2010-07-22 
> 03:26:19:
> >> > 
> >> >   
> >> > 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.
> >> > 2010/7/21 <[email-masked]>
> >> > 
> >> > 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. 
> >> > 2010/7/21 <[email-masked]>
> >> > 
> >> > 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. 
> >> >   
> >> >   
> >> > 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-2020: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 
> >> >   
> >> > 
> >> > 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 
> >> >   
> >> >             
> >> > 
> >> > -- 
> >> > Best Regards,
> >> > Venkatesan Mahalingam.
> >> >       
> >> > --------------------------------------------------------
> >> > 
> >> >     
> >> > 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.
> >> >     
> >> > 
> >> > 
> >> > --------------------------------------------------------
> >> > 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.
> >> >   
> >> > 
> >> > 
> >> > _______________________________________________
> >> > pwe3 mailing list
> >> > [email-masked]
> >> > https://www.ietf.org/mailman/listinfo/pwe3
> >> >   
> > 
> > --------------------------------------------------------
> > 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.
> > 
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pwe3