Subject: RESEND RE: Control protocol draft - section 5.3.1 change t o PW status.

From: "David Allan" <[email-masked]>
Date: Thu, 24 Feb 2005 07:33:41 -0500

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

---

From: [email-masked]
Date: Thu, 24 Feb 2005 16:18:00 -0000

Tom...IMO this statement does nothing to help IETFs stature as a body
producing standards operators can confidently rely on.  Simply being
backwards compatible with already implemented stuff (as a direct
consequence of 'rough consensus and running code') that is obviously not
correct is no excuse.  Your argument boils down to saying ' we won't do
anything about it until its proved broken' is not acceptable IMO....esp
when it obviously not right in the 1st place.  Just look at what
happened with OAM.  2+ years ago I can recall being clearly told this
was not required....then operational experience showed otherwise....now
its too late to properly get the base protocol structures/net-arch
right...so we are required (no choice) to accept more fixes.

It really is not good enough IMO.

regards, neil

> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: 24 February 2005 15:54
> To: David Allan
> Cc: 'Mustapha Aissaoui'; 'Luca Martini'; Harrison,N,Neil,IKM1 
> R; [email-masked]'
> Subject: Re: RESEND RE: [PWE3] Control protocol draft - 
> section 5.3.1 change t o 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).
> >
> 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,
> >>> yes. This is correct, then the remote end would 
> re-generate the AIS 
> >>> alarm.
> >>>
> >>> 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.
> >>>
> >>>
> Remember that 
> >>> this is a MUST implement, therefore this is what is going to be
> >>> used by ALL
> >>> PWE3 implementations.
> >>>
> they must 
> >>> be working fine with just the label withdraw method.
> >>>>> defect in some client layer link connection.  Just 
> think if we did
> >>> this for
> >>>>>> 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:
> >>>>>>
> >>>>>> [email-masked] https://www1.ietf.org/mailman/listinfo/pwe3
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Luca Martini <[email-masked]>
Date: Thu, 24 Feb 2005 10:25:01 -0700

Neil,

Right now , the design gives you exactly what you require. Disabling 
backward compatibility does not help you in any way.
However it will make it very likely that implementations will ignore 
this text , and keep the backward compatibility. In which case this text 
will be changed back anyway at the proposed standard review time.
Right now I do not see a consensus to remove the backward status 
messaging compatibility. I would like to hear from the rest of the WG, 
including most of the contributors to these documents.
We have gone past last call , and at last call we had the PW status 
messaging as strongly RECOMMENDED only. The AD asked me to change it to 
a MUST. The label withdraw method was always a MUST. So if we had a 
problem with this text it should have been argued at , or before last 
call . Not now.

Luca

[email-masked] wrote:

>>>>>>label withdrawal is to be avoided as much as possible is 
>>>>>>            
>>>>>>
>>because it 
>>    
>>
>>>>>>want to have the network react to some unstable CPE or 
>>>>>>            
>>>>>>
>>L2 network 
>>    
>>
>>>>>>condition.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>I suggest that regardless of the PW status method used, 
>>>>>>            
>>>>>>
>>a label is 
>>    
>>
>>>>>>In the new PW status design, described here , the  PW is 
>>>>>>            
>>>>>>
>>not "taken 
>>    
>>
>>>>>>>One should NEVER take down a server layer trail in 
>>>>>>>              
>>>>>>>
>>response to a 
>>    
>>
>>>>>>>> CE-facing interface state. The PW label should not be 
>>>>>>>>                
>>>>>>>>
>>withdrawn  
>>    
>>
>>>>>>>> is strongly RECOMMENDED that the PW status signaling 
>>>>>>>>                
>>>>>>>>
>>procedures 
>>    
>>
>>>>>>>>the PW configuration is deleted entirely). Using the 
>>>>>>>>                
>>>>>>>>
>>procedures 
>>    
>>
>>>>>>>>Please let me know if you have any comments about this 
>>>>>>>>                
>>>>>>>>
>>text. Luca
>>    
>>