Subject: RE: RESEND RE: Control protocol draft - section 5.3.1 chan ge to PW status.

From: "David Allan" <[email-masked]>
Date: Thu, 24 Feb 2005 12:15:00 -0500

FYI, would also apply to unstructured TDM...and Ethernet 802.1ag/Y.17ethoam,
SATOP I believe would also prefer the PW be held up to maintain clock
synch... 

Dave

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]] 
> Sent: Thursday, February 24, 2005 12:09 PM
> To: Mustapha Aissaoui
> Cc: 'Thomas D. Nadeau'; Allan, David [CAR:NS00:EXCH]; 
> [email-masked]; [email-masked]
> Subject: Re: RESEND RE: [PWE3] Control protocol draft - 
> section 5.3.1 change to PW status.
> 
> 
> Mustapha Aissaoui wrote:
> 
> >Tom,
> >I am not not suggesting to remove the label withdrawal method. My 
> >suggestion is to withdraw a label when the AC's 
> administrative status 
> >is DOWN but not when its operational status is DOWN. In the latter 
> >case, keeping the label will allow the transparent tunneling of 
> >received or locally generate AIS/RDI over the PW to the remote PE.
> >
> >  
> >
> I never heard of ethernet AIS/RDI ...... , or HDLC AIS/RDI  
> .... Are you talking about making an exception for the ATM 
> case only ? I think that the rest of the WG might be able to 
> accept that just for 
> ATM. In which case we would put some text in the ATM draft , in the 
> service specific section.
> 
> Luca
> 
> 
> >Mustapha.
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >Thomas D. Nadeau
> >Sent: Thursday, February 24, 2005 10:54 AM
> >To: David Allan
> >Cc: [email-masked]'; [email-masked]'; 'Luca Martini'; 
> >'Mustapha Aissaoui'
> >Subject: Re: RESEND RE: [PWE3] Control protocol draft - 
> section 5.3.1 
> >change to PW status.
> >
> >
> >
> >  
> >
> >> I've never been happy with label withdraw, esp. when 
> either  AIS or 
> >>RDI termination at a PE is indicative of an AC fault  and if not 
> >>ignored, withdrawl on RDI will ultimately lock  down the PW (as 
> >>withdrawl escalates all faults to AIS at the far AC).
> >>
> >> I would agree with Mustapha's concerns, backwards  
> compatibility with 
> >>somthing that is broken is not really a good idea.
> >>    
> >>
> >
> >	I have to disagree and agree with Luca's original 
> assertion. There are 
> >too many deployments in the field that are working just fine to 
> >disallow this as an option going forward.  Ultimately folks 
> may choose 
> >to not configure this behavior once all of the status signaling is 
> >implemented, but we should not preclude those that are working today 
> >and want to keep with what they have.
> >
> >	--Tom
> >
> >
> >
> >
> >  
> >
> >> cheers
> >> Dave
> >>
> >>    
> >>
> >>>>>Luca,
> >>>>>However, it all appears that if the label withdraw PW status
> >>>>>          
> >>>>>
> >>>>method is
> >>>>        
> >>>>
> >>>>>used, then a label is withdrawn if say a AIS cell is
> >>>>>          
> >>>>>
> >>>>received from the
> >>>>        
> >>>>
> >>>>>local ATM network or LMI indicated a fault. Am I wrong?
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>yes. This is correct, then the remote end would 
> re-generate the AIS 
> >>>>alarm.
> >>>>
> >>>>        
> >>>>
> >>>>>Also, how should we interpret the new text? Initially, you
> >>>>>          
> >>>>>
> >>>advertize
> >>>      
> >>>
> >>>>>the label regardless of the state of AC. Then, if the PW status 
> >>>>>negotiation results in the use of the label withdraw PW
> >>>>>          
> >>>>>
> >>>>status method,
> >>>>        
> >>>>
> >>>>>would you immediately withdraw the label because the AC is
> >>>>>          
> >>>>>
> >>>>not active?
> >>>>        
> >>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>That would be my understanding. Some state needs to be 
> kept for this 
> >>>>PW, for the life of the LDP session, to indicate that the PW uses 
> >>>>label withdraw method.
> >>>>
> >>>>
> >>>>        
> >>>>
> >>>>>I would like to see a simplification to the procedures. The
> >>>>>          
> >>>>>
> >>>>reason why
> >>>>        
> >>>>
> >>>>>label withdrawal is to be avoided as much as possible is 
> because it 
> >>>>>confuses a fault condition with an adiministrative
> >>>>>          
> >>>>>
> >>>>operation. We do not
> >>>>        
> >>>>
> >>>>>want to have the network react to some unstable CPE or 
> L2 network 
> >>>>>condition.
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>For this reason we have PW status TLV infrastructure. 
> Remember that 
> >>>>this is a MUST implement, therefore this is what is going 
> to be used 
> >>>>by ALL
> >>>>PWE3 implementations.
> >>>>
> >>>>        
> >>>>
> >>>>>I suggest that regardless of the PW status method used, 
> a label is 
> >>>>>withdrawan only if the user configures the AC administrative
> >>>>>          
> >>>>>
> >>>>state to
> >>>>        
> >>>>
> >>>>>DOWN. Any other fault condition should raise an alarm to the
> >>>>>          
> >>>>>
> >>>>management
> >>>>        
> >>>>
> >>>>>system but should not cause a label withdrawal.
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>This would break any status notification.
> >>>>The intent is not to break current deployments. After all 
> they must 
> >>>>be working fine with just the label withdraw method. Whether this 
> >>>>text is there or not , the implementations will implement label 
> >>>>withdraw anyway. We all agree that if there is no label 
> >>>>advertisement the PW is down. That is the main point.
> >>>>Why are you so keen in disabling the backward compatibility ?
> >>>>I would like this standard to be implemented, not the old
> >>>>draft-martini.
> >>>>
> >>>>Luca
> >>>>
> >>>>        
> >>>>
> >>>>>Mustapha.
> >>>>>
> >>>>>-----Original Message-----
> >>>>>From: [email-masked] [mailto:[email-masked]]
> >>>>>          
> >>>>>
> >>>>On Behalf Of
> >>>>        
> >>>>
> >>>>>Luca Martini
> >>>>>Sent: Friday, February 18, 2005 10:45 AM
> >>>>>To: [email-masked]
> >>>>>Cc: [email-masked]
> >>>>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1
> >>>>>          
> >>>>>
> >>>>change to PW
> >>>>        
> >>>>
> >>>>>status.
> >>>>>
> >>>>>[email-masked] wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>Luca asked:  Please let me know if you have any comments
> >>>>>>            
> >>>>>>
> >>>about this
> >>>      
> >>>
> >>>>>>text.
> >>>>>>
> >>>>>>Question:  Is there is any inference in this text (or
> >>>>>>            
> >>>>>>
> >>>other text in
> >>>      
> >>>
> >>>>>>this draft, or in any other draft for that matter) that a
> >>>>>>            
> >>>>>>
> >>>>PW must be
> >>>>        
> >>>>
> >>>>>>taken down in response to a failure on an AC?  If there is
> >>>>>>            
> >>>>>>
> >>>>then its wrong.
> >>>>        
> >>>>
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>In the new PW status design, described here , the  PW is 
> not "taken 
> >>>>>down ", but instead attachment circuit status is
> >>>>>          
> >>>>>
> >>>communicated to the
> >>>      
> >>>
> >>>>>remote end of the PW. So the answer is no. Example ATM AIS
> >>>>>          
> >>>>>
> >>>>alarm. The
> >>>>        
> >>>>
> >>>>>AIS OAM cells will be passed along the PW , additionally a
> >>>>>          
> >>>>>
> >>>PW status
> >>>      
> >>>
> >>>>>TLV "interface Receive Fault" will also be transmitted in
> >>>>>          
> >>>>>
> >>>>the control
> >>>>        
> >>>>
> >>>>>protocol.
> >>>>>
> >>>>>Luca
> >>>>>
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>>>One should NEVER take down a server layer trail in 
> response to a 
> >>>>>>defect in some client layer link connection.  Just 
> think if we did
> >>>>>>            
> >>>>>>
> >>>>this for
> >>>>        
> >>>>
> >>>>>>all nested layer networks right down to optics!
> >>>>>>
> >>>>>>regards, Neil
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>>>-----Original Message-----
> >>>>>>>From: [email-masked] [mailto:[email-masked]]
> >>>>>>>              
> >>>>>>>
> >>>>On Behalf
> >>>>        
> >>>>
> >>>>>>>Of Luca Martini
> >>>>>>>Sent: 17 February 2005 23:35
> >>>>>>>To: PWE3 WG (E-mail)
> >>>>>>>Subject: [PWE3] Control protocol draft - section 5.3.1
> >>>>>>>              
> >>>>>>>
> >>>>change to PW
> >>>>        
> >>>>
> >>>>>>>status.
> >>>>>>>
> >>>>>>>
> >>>>>>>In this section , we were asked to make the implementation
> >>>>>>>              
> >>>>>>>
> >>>>of the PW
> >>>>        
> >>>>
> >>>>>>>status messages/TLV mandatory.
> >>>>>>>Also all "CE-facing port" terminology will be changed to
> >>>>>>>              
> >>>>>>>
> >>>>"attachment
> >>>>        
> >>>>
> >>>>>>>circuit".
> >>>>>>>
> >>>>>>>5.3.1. Use of Label Mappings.
> >>>>>>>
> >>>>>>> The PEs MUST send PW label mapping messages to their
> >>>>>>>              
> >>>>>>>
> >>>>peers as soon
> >>>>        
> >>>>
> >>>>>>>as
> >>>>>>> the PW is configured and administratively enabled,
> >>>>>>>              
> >>>>>>>
> >>>regardless of
> >>>      
> >>>
> >>>>>>>the
> >>>>>>> CE-facing interface state. The PW label should not be 
> withdrawn 
> >>>>>>>unless the user administratively configures the
> >>>>>>>              
> >>>>>>>
> >>>>CE-facing interface
> >>>>        
> >>>>
> >>>>>>> down (or the PW configuration is deleted entirely). Using the 
> >>>>>>>procedures outlined in this section a simple label
> >>>>>>>              
> >>>>>>>
> >>>>withdraw method
> >>>>        
> >>>>
> >>>>>>> MAY also be supported as a primitive means of signaling
> >>>>>>>              
> >>>>>>>
> >>>>PW status.
> >>>>        
> >>>>
> >>>>>>>It
> >>>>>>> is strongly RECOMMENDED that the PW status signaling 
> procedures 
> >>>>>>>below  be fully implemented. In any case if the Label 
> mapping is 
> >>>>>>>not  available the PW MUST be considered in the down state.
> >>>>>>>
> >>>>>>>will change to:
> >>>>>>>
> >>>>>>>5.3.1. Use of Label Mappings.
> >>>>>>>The PEs MUST send PW label mapping messages to their peers
> >>>>>>>              
> >>>>>>>
> >>>>as soon as
> >>>>        
> >>>>
> >>>>>>>the PW is configured and administratively enabled,
> >>>>>>>              
> >>>>>>>
> >>>>regardless of the
> >>>>        
> >>>>
> >>>>>>>attachment circuit state. The PW label should not be
> >>>>>>>              
> >>>>>>>
> >>>>withdrawn unless
> >>>>        
> >>>>
> >>>>>>>the user administratively configures the CE-facing
> >>>>>>>              
> >>>>>>>
> >>>>interface down (or
> >>>>        
> >>>>
> >>>>>>>the PW configuration is deleted entirely). Using the 
> procedures 
> >>>>>>>outlined in this section a simple label withdraw method
> >>>>>>>              
> >>>>>>>
> >>>>MUST also be
> >>>>        
> >>>>
> >>>>>>>supported as a primitive means of signaling PW status. In
> >>>>>>>              
> >>>>>>>
> >>>>any case if
> >>>>        
> >>>>
> >>>>>>>the Label mapping is not available the PW MUST be
> >>>>>>>              
> >>>>>>>
> >>>>considered in the
> >>>>        
> >>>>
> >>>>>>>down state.
> >>>>>>>
> >>>>>>>Once, the PW status negotiation procedures are completed
> >>>>>>>              
> >>>>>>>
> >>>>and if they
> >>>>        
> >>>>
> >>>>>>>result in the use of the label withdraw method for PW status 
> >>>>>>>communication, the label withdraw PW status method MUST be
> >>>>>>>              
> >>>>>>>
> >>>>used. This
> >>>>        
> >>>>
> >>>>>>>will result in the PW label mapping message being
> >>>>>>>              
> >>>>>>>
> >>>>advertised only if
> >>>>        
> >>>>
> >>>>>>>the attachment circuit becomes active. The PW status signaling 
> >>>>>>>procedures described in this section MUST be fully implemented.
> >>>>>>>
> >>>>>>>
> >>>>>>>Please let me know if you have any comments about this 
> text. Luca
> >>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>pwe3 mailing list
> >>>>>>>[email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>              
> >>>>>>>
> >>>>>>_______________________________________________
> >>>>>>pwe3 mailing list
> >>>>>>[email-masked]
> >>>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>            
> >>>>>>
> >>>>>_______________________________________________
> >>>>>pwe3 mailing list
> >>>>>[email-masked]
> >>>>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>
> >>>>>
> >>>>>          
> >>>>>
> >>>>_______________________________________________
> >>>>pwe3 mailing list
> >>>>[email-masked]
> >>>>https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>
> >>>>
> >>>>        
> >>>>
> >>_______________________________________________
> >>pwe3 mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/pwe3
> >>    
> >>
> >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >
> >
> >_______________________________________________
> >pwe3 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/pwe3
> >  
> >
> 
>