Subject: Re: Control protocol draft - section 5.3.1 change to PW st atus.

From: Luca Martini <[email-masked]>
Date: Fri, 18 Feb 2005 20:29:29 -0700

Busschbach, Peter B (Peter) wrote:

>  
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>>Luca Martini
>>Sent: Friday, February 18, 2005 10:51 AM
>>To: Kulkarni, Hrishikesh (Hrishikesh)
>>Cc: [email-masked]'; [email-masked]
>>Subject: Re: [PWE3] Control protocol draft - section 5.3.1 
>>change to PW
>>st atus.
>>
>>
>>Rishi,
>>
>>Please see my previous e-mail.
>>Additionally, yes I agree with you that the old label 
>>withdraw design is a problem. However this text clearly 
>>states that the new PW status TLV MUST be implemented, so 
>>this is what will be used if all PEs comply to this draft.
>>
>>    
>>
>
>Luca,
>
>To me it does not make sense that the draft states that PW Status TLV MUST be implemented, but also that "a simple label withdraw method MUST also be supported as a primitive means of signaling PW status"
>
>It is my understanding that the latter clause is added to ensure interoperability with legacy implementations. However, since the use of Status TLV is mandatory, those legacy implementations are clearly not compliant. The onus should be on the vendors of such equipment to make their products standards-compliant, not on new equipment to interwork with primitive implementations. 
>
>  
>
No, All SPs will tell you that they want an upgrade path that does not 
involve upgrading the complete network at once !
If we make it difficult to deploy PW status , it will not be deployed, 
and other means that are easier to deploy will be used instead.
If it  really does not cost too much to be backward compatible, then we 
should be.

Luca

>Peter
>
>
>  
>
>>Luca
>>
>>
>>
>>Kulkarni, Hrishikesh (Hrishikesh) wrote:
>>
>>    
>>
>>>I agree with the workings/recommendations of OSI model and 
>>>      
>>>
>>the server-client
>>    
>>
>>>architecture 
>>>used in networks
>>>
>>>so let me rephrase the question:
>>>In case of N:1 ATM pwe3, Multiple CE-side facing interfaces could
>>>communicate
>>>over a single pwe3. So do you recommend sending label 
>>>      
>>>
>>withdraw if one 
>>    
>>
>>>of the ce-side facing interface is administered down?
>>>
>>>also,
>>>"
>>>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.
>>>"
>>>
>>>looks like this text is saying, bring up the "server" layer 
>>>      
>>>
>>when "client"
>>    
>>
>>>layer is active.
>>>
>>>I am really interested in knowing, the PW status management 
>>>      
>>>
>>in case of N:1 
>>    
>>
>>>and 1:1 PWE3. Please help clarify.
>>>
>>>
>>>Rishi
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: [email-masked] 
>>>>        
>>>>
>>[mailto:[email-masked]]On Behalf Of
>>    
>>
>>>>[email-masked]
>>>>Sent: Friday, February 18, 2005 1:48 PM
>>>>To: [email-masked]; [email-masked]
>>>>Subject: RE: [PWE3] Control protocol draft - section 5.3.1 
>>>>change to PW
>>>>status.
>>>>
>>>>
>>>>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.
>>>>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
>>
>>    
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sat, 19 Feb 2005 15:58:11 -0500

Peter,

Luca is right on this point - there has to be a smooth migration available 
for the installed base, which is quite considerable at this point., or 
carriers will never upgrade to the RFC-compliant release.  He's not 
suggesting that we continue to use label withdraw indefinitely.

Cheers,
Andy

---------

At 2/18/2005 08:29 PM -0700, Luca Martini wrote:
>>To me it does not make sense that the draft states that PW Status TLV 
>>MUST be implemented, but also that "a simple label withdraw method MUST 
>>also be supported as a primitive means of signaling PW status"
>>
>>It is my understanding that the latter clause is added to ensure 
>>interoperability with legacy implementations. However, since the use of 
>>Status TLV is mandatory, those legacy implementations are clearly not 
>>compliant. The onus should be on the vendors of such equipment to make 
>>their products standards-compliant, not on new equipment to interwork 
>>with primitive implementations.
>>
>If we make it difficult to deploy PW status , it will not be deployed, and 
>other means that are easier to deploy will be used instead.