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

From: "Kulkarni, Hrishikesh (Hrishikesh)" <[email-masked]>
Date: Fri, 18 Feb 2005 12:24:34 +0530

See comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Luca Martini
> Sent: Friday, February 18, 2005 5:05 AM
> 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.
> 

The label withdrawal should not be dependent on the state of the CE-facing
interface.
take for example N:1 ATM pwe3. Ckts from various CE-facing interface can
come
into a single N:1 ATM pwe3.

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

Again, in case of N:1 ATM pwe3, one ckt going active or inactive 
should not trigger label advertise or label withdrawals, since there 
are many other ckts going over the pwe3. 

My request is to spell the above procedures separately for 1:1 
and N:1 pwe3.

rishi

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

---

From: "Kulkarni, Hrishikesh (Hrishikesh)" <[email-masked]>
Date: Fri, 18 Feb 2005 15:06:34 +0530

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

> [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
> 
> > 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.
> > 
> > 
> > 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 
> > 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.
> > 
> > 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 
> > in this section MUST be fully implemented.
> > 
> > 
> > Please let me know if you have any comments about this text. Luca
> >

---

From: Luca Martini <[email-masked]>
Date: Fri, 18 Feb 2005 08:40:38 -0700

Rishi,

I just spotted another problem, the text "CE- facing interface down" is incorrect.I had already replaced it with 
"attachment circuit". This should resolve your concern.
Also note that the specific status definition for ATM is specified in the ATM draft.

Current text is :

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

Luca

---

From: Shahram Davari <[email-masked]>
Date: Fri, 18 Feb 2005 08:03:14 -0800

Luca,

I think these two statements are contradicting each other:

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

2) This will result in the PW label mapping message being advertised only if the attachment circuit becomes active.

I think the second statement should be change to:

"This will result in the PW label mapping message being advertised only if the CE-facing interface is up and the PW is enable".

Yours,
-Shahram

> Sent: Thursday, February 17, 2005 6:35 PM
> To: PWE3 WG (E-mail)

---

From: Shahram Davari <[email-masked]>
Date: Fri, 18 Feb 2005 08:59:56 -0800

Luca,

Why is there any difference in treating the AC down and receiving say ATM OAM?

-Shahram

> Sent: Friday, February 18, 2005 10:41 AM
> To: Kulkarni, Hrishikesh (Hrishikesh)
> Cc: PWE3 WG (E-mail)
> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 
> change to PW
> st atus.
> 
> 
> Rishi,
> 
> I just spotted another problem, the text "CE- facing 
> interface down" is incorrect.I had already replaced it with 
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>Luca Martini

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 18 Feb 2005 12:13:06 -0500

> Sent: Friday, February 18, 2005 10:51 AM
> Cc: [email-masked]'; [email-masked]
> 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. 

Peter

> >>>In this section , we were asked to make the implementation 
> >>>      
> >>>
> >>of the PW 
> >>    
> >>
> >>>Also all "CE-facing port" terminology will be changed to 
> >>>      
> >>>
> >>"attachment 
> >>    
> >>
> >>>circuit".
> >>>
> >>>   unless the user administratively configures the 
> >>>      
> >>>
> >>CE-facing interface
> >>    
> >>
> >>>   procedures outlined in this section a simple label 
> >>>      
> >>>
> >>withdraw method
> >>    
> >>

---

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

>2) This will result in the PW label mapping message being advertised only if the attachment circuit becomes active.
Shahram,
If you take the second statement in the context of the text preceding it 
then we have :

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 part that you must consider is that if the negotiations procedures 
result in the fact that this PW has to use the old label withdraw method 
, then the PE  will advertise the label only when the AC becomes active.
Or in other words statement #1 applies if we use the PW status method , 
while #2 applies to the label withdraw method.
If you read the wording carefully, the conclusion is that all 
implementations MUST implement PW status. However non-PWE3 compliant 
implementations will still work. ( I,E. there is an upgrade path ... )

Thanks.
Luca

---

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

>Why is there any difference in treating the AC down and receiving say ATM OAM?
I'm not sure I understand what you mean by "treating" ...
the AC will have a rx fault if it receives an ATM AIS alarm on it. This 
will result in a PW status message sent along the PW.
The AC can be down , and no ATM AIS alarm present.  Maybe there are too 
many errored cell s on it ....
Luca

>>>>means of signaling PW status. In any case if the Label 
>>>>        
>>>>
>>mapping is not
>>    
>>
>>>The label withdrawal should not be dependent on the state of 
>>>      
>>>
>>the CE-facing
>>    
>>
>>>interface.
>>>take for example N:1 ATM pwe3. Ckts from various CE-facing 
>>>      
>>>
>>interface can
>>    
>>
>>>come
>>>>label mapping message being advertised only if the 
>>>>        
>>>>
>>attachment circuit
>>    
>>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Sat, 19 Feb 2005 13:07:11 -0500

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

Well, at once?

It has been clear for the past two years that PW Status is the preferred approach. Furthermore, not every PE will be connected to every other PE. Often, introduction of a new line of products has impact on a small set of existing products.

The control draft will become an RFC that will guide implementations for the next decade. I don't think it should have requirements that only serve to guarantee compatibility with products with pre-standard implementations.

I propose that we change the wording to: a simple label withdraw method MAY also be supported to interwork with legacy products that use this as a primitive means of signaling PW status.

With that definition, vendors can assess the market and decide for themselves whether this interoperability is still required.

---

From: Luca Martini <[email-masked]>
Date: Sat, 19 Feb 2005 21:14:43 -0700

Peter,

I do not believe that we have consensus to drop the interoperability , 
however I will add the "legacy" wording.

Luca

---

From: Shahram Davari <[email-masked]>
Date: Wed, 23 Feb 2005 07:17:44 -0800

Agree.

> From: Mustapha Aissaoui [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2005 10:09 AM
> To: Shahram Davari; 'Luca Martini'
> Cc: [email-masked]; [email-masked]
> This is why I asked that we should only withdraw the label 
> when the AC is
> administrativley DOWN when the label withdraw method is used. 
> Operational
> status should be updated by AIS/RDI which gets passed 
> transparently if the
> label is not whithdrawn.
> 
> Mustapha.
> 
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2005 9:45 AM
> To: 'Luca Martini'; Mustapha Aissaoui
> Cc: [email-masked]; [email-masked]
> change to PW st
> atus.
> > >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.
> >
> 
> How does the other end know whether this is an administrative 
> withdrwal for
> removing the service (in which case it should not generate 
> AIS) or it is a
> withdrawal caused by a fault (in which case it should generate AIS)?
> 
> -Shahram
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 23 Feb 2005 06:45:09 -0800

Luca,

> yes. This is correct, then the remote end would re-generate 
> the AIS alarm.
> 

How does the other end know whether this is an administrative withdrwal for
removing the service (in which case it should not generate AIS) or it is a withdrawal caused by a fault (in which case it should generate AIS)?

-Shahram

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Wed, 23 Feb 2005 10:09:07 -0500

Shahram,
This is why I asked that we should only withdraw the label when the AC is
administrativley DOWN when the label withdraw method is used. Operational
status should be updated by AIS/RDI which gets passed transparently if the
label is not whithdrawn.

Mustapha.

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Wednesday, February 23, 2005 9:45 AM
To: 'Luca Martini'; Mustapha Aissaoui
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PW st
atus.

Luca,

How does the other end know whether this is an administrative withdrwal for
removing the service (in which case it should not generate AIS) or it is a
withdrawal caused by a fault (in which case it should generate AIS)?

-Shahram

---

From: "Kulkarni, Hrishikesh (Hrishikesh)" <[email-masked]>
Date: Thu, 24 Feb 2005 14:34:29 +0530

Mustapha,

The problem of when multiple AC are going through a singe N:1 PWE3 remains
unsolved.
if we withdraw the label when one AC is admin down, what about other AC.

Rishi

> Mustapha Aissaoui
> Sent: Wednesday, February 23, 2005 8:39 PM
> To: 'Shahram Davari'; 'Luca Martini'

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Feb 2005 12:16:50 -0500

> From: Benny Ammitzbøll [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2005 4:29 AM
> To: Luca Martini; [email-masked]
> Cc: [email-masked]; [email-masked]
> Sorry if I jump in in the middle of this, but I believe that 
> Neils point is
> that the PW is the server and what the PW carries inside is 
> the client. This
> also IMO means that the AC is client and the state of the AC 
> should not
> affect the server layer, i.e. the PW.
> 
> I think it would help to stress more clearly in section 5.3.1 that the
> coupling between AC state and PW state is NOT the desired 
> behaviour, but it
> is only there because of backwards compatability with non-standard
> equipment.
> 
> My proposal for a new text:
> 
>    attachment circuit state. The PW label should not be 
> withdrawn unless
>    the user administratively configures the PW down (or the 
> PW configuration
>    is deleted entirely). If the Label mapping is not 
> available the PW MUST
>    For backwards compatability a simple label withdraw method 
> MUST also be

I have made this point in an earlier email, but I think it is worth repeating. I believe that this MUST should be a MAY.

Label mapping, label withdraw and the use of PW Status are all functions that are implemented in software. Therefore, it may be true that there are legacy devices today that only support label withdraw, but there is no reason why vendors would not be able to support PW Status in future software releases. PW Status is mandatory and future software releases must support it to be standards-compliant.

Considering the fact that PWE is a relatively new and rapidly expanding technology, does anybody believe that five years from now there will be products in the field that were installed pre 2003 and that still run their original R1 software load?

>    supported as a legacy means of signaling PW status. When 
> the PW status
>    negotiation procedures are completed and if they result in 
> not using the
>    PW Status TVL, 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.
> 
> /Benny
> 
> 
> Sent: 22. februar 2005 20:35
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> [email-masked] wrote:
> 
> >Mustapha,
> >
> >This is precisely why I raised this point.....but please do 
> not overlook
> >the more fundamantal point that 'defect events' in any client layer
> >should never result in 'events' in any server layer.  One should not
> >violate principles like these just because its expedient.  
> If everyone
> >had taken this attitude we could, in theory, cause 'events' at the
> >optics layer (maybe in someone else's network even) for 
> 'defect events'
> >in some client perhaps several layers removed (upwards).  
> Clearly this
> >is a nonsense.
> >
> >regards, Neil
> >
> >
> >
> Neil, I agree, however the PW is not a client of the PW control
> protocol. I see the PW an adaptation of the 
> atm/frame/ethernet etc. to MPLS.
> So we are not causing an alarm in the RSVP LSP , or in the 
> IGP protocol.....
> 
> Luca
> 
> >>Sent: 22 February 2005 15:05
> >>To: 'Luca Martini'; Harrison,N,Neil,IKM1 R
> >>Cc: [email-masked]
> >>change to 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?
> >>
> >>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?
> >>
> >>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.
> >>
> >>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.
> >>
> >>Mustapha.
> >>
> >>Sent: Friday, February 18, 2005 10:45 AM
> >>To: [email-masked]
> >>Cc: [email-masked]
> >>change to PW status.
> >>[email-masked] wrote:
> >>
> >>
> >>
> >>>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
> >>
> >>
> >>
> >>>in some client layer link connection.  Just think if we 
> did this for
> >>>all nested layer networks right down to optics!
> >>>
> >>>regards, Neil
> >>>
> >>>
> >>>
> >>>
> >>>
> [mailto:[email-masked]] On Behalf
> >>>>Of Luca Martini
> >>>>  The PEs MUST send PW label mapping messages to their
> >>>>
> >>>>
> >>peers as soon
> >>
> >>
> >>>>as
> >>>>  the PW is configured and administratively enabled, regardless of
> >>>>the
> >>>>  MAY also be supported as a primitive means of signaling
> >>>>
> >>>>
> >>PW status.
> >>
> >>
> >>>>It
> >>>>  is strongly RECOMMENDED that the PW status signaling procedures
> >>>>below
> >>>>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.
> >>>>
> >>>>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 24 Feb 2005 10:37:43 -0800

This is a reasonable suggestion.

-Shahram

> > I have made this point in an earlier email, but I think it is worth 
> > repeating. I believe that this MUST should be a MAY.
> 
> 	Peter,
> 
> 	This seems reasonable (and flexible) to me.  In fact,
> I thought we all agreed to a MAY a while back.
> 
> 	--Tom
> 
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Feb 2005 14:08:23 -0500

Sounds good to me.

> From: Luca Martini [mailto:[email-masked]]
> Sent: Thursday, February 24, 2005 2:07 PM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; Busschbach, Peter B (Peter); [email-masked];
> [email-masked]; [email-masked]; 'Benny
> Ammitzboll'
> Excellent , it sound like we are converging.
> However we need to agree on the logic of this PW status procedure.
> If the PW status negotiation results in Label Withdraw method then :
> 
> 1) we use label withdraw method ( MAY option )
> 2) if label withdraw is not implemented , we disable the PW 
> with a label 
> release error message.
> 3) we do nothing. however in this case PW messaging would be broken.
> 
> I think that we need #1 and #2 in the text with the 
> corresponding error 
> for #2
> 
> Do you agree ?
> 
> Luca
> 
> 
> 
> 
> Shahram Davari wrote:
>

---

From: Shahram Davari <[email-masked]>
Date: Thu, 24 Feb 2005 11:56:31 -0800

How  can the negotiation result in Label Withdrawal, if it is not implemented?

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Thursday, February 24, 2005 2:52 PM
> To: Luca Martini
> Cc: 'Benny Ammitzboll'; Shahram Davari; [email-masked];
> [email-masked]; [email-masked]; 
> Busschbach, Peter
> B (Peter)
> 	Cool with me.  So I think it should be worded
> like:
> 
> If the PW status negotiation results in Label Withdraw method then
> you SHOULD use either 1) label withdraw method, or 2) if
> label withdraw is not implemented, we disable the PW with a label
> release error message.
> 
> 	--tom
> 
> 
> > 2) if label withdraw is not implemented , we disable the PW with a 
> > label release error message.
> > I think that we need #1 and #2 in the text with the corresponding 
> > error for #2
> >
> > Do you agree ?
> >
> > Luca
> >
> >
> >
> >
> > Shahram Davari wrote:
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Feb 2005 16:50:32 -0500

Hi Shahram,

See 5.3.3: Pseudowire Status Negotiation Procedures.

Peter

> Sent: Thursday, February 24, 2005 2:57 PM
> To: 'Thomas D. Nadeau'; Luca Martini
> Cc: 'Benny Ammitzboll'; [email-masked]; [email-masked];
> [email-masked]; Busschbach, Peter B (Peter)

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Feb 2005 16:56:03 -0500

I agree with Andy's proposal.

Peter

> From: Andrew G. Malis [mailto:[email-masked]]
> Sent: Thursday, February 24, 2005 3:50 PM
> To: Thomas D. Nadeau
> Cc: Luca Martini; Shahram Davari; [email-masked]; 'Benny Ammitzboll';
> Busschbach, Peter B (Peter); [email-masked];
> [email-masked]
> The SHOULD in Tom's text below needs to be a MUST, since if 
> the negotiation 
> results in using the Withdraw method, then you MUST follow 
> Tom's algorithm.
> 
> I would also prefer that implementations SHOULD implement 
> Withdraw for 
> backwards compatibility, rather than MAY, to encourage backwards 
> compatibility without actually requiring it.  When the 
> Proposed Standard 
> goes for Draft Standard, we can think about lessening the 
> SHOULD to a MAY 
> (or even removing it), since hopefully at that point the 
> installed base 
> would have migrated to the RFC.
> 
> Cheers,
> Andy
> 
> ------------
> 
> At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote:
>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Feb 2005 16:55:22 -0500

Forgot to add something. Please see below.

> From: Busschbach, Peter B (Peter) 
> Sent: Thursday, February 24, 2005 4:51 PM
> To: 'Shahram Davari'; 'Thomas D. Nadeau'; Luca Martini

If one of the two PEs indicates that it cannot support PW Status, Label Withdraw is the assumed mechanism. However, if the other PE does not support Label Withdraw, it must generate an alarm, as Luca proposed in an earlier email. 

> corresponding

---

From: Shahram Davari <[email-masked]>
Date: Thu, 24 Feb 2005 13:57:31 -0800

Thanks Peter,

Isn't Label withdrawal a mandatory implementation in LDP?

-Shahram

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: Thursday, February 24, 2005 4:55 PM
> To: Shahram Davari; 'Thomas D. Nadeau'; 'Luca Martini'
> Cc: 'Benny Ammitzboll'; [email-masked]';
> [email-masked]'; [email-masked]'
> If one of the two PEs indicates that it cannot support PW 
> Status, Label Withdraw is the assumed mechanism. However, if 
> the other PE does not support Label Withdraw, it must 
> generate an alarm, as Luca proposed in an earlier email. 
> 
> 
> > 
> > Peter
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Feb 2005 17:07:07 -0500

Yes, Label Withdraw is a mandatory part of LDP per se. However, the issue here is its usage in relation to OAM.

If we didn't have the situation with legacy equipment, the OAM procedures are as described in the oam-msg-map draft, i.e. in case of failures, generate AIS or send PW Status. To deal with legacy equipment, the algorithm must now include a check on the capabilities of the peer:

IF <Peer supports PW Status> THEN <send PW Status> ELSE <Withdraw Label>

Peter

> Sent: Thursday, February 24, 2005 4:58 PM
> To: 'Busschbach, Peter B (Peter)'; 'Thomas D. Nadeau'; 'Luca Martini'

---

From: Shahram Davari <[email-masked]>
Date: Thu, 24 Feb 2005 14:41:03 -0800

Hi Peter,

I know. But my question is regarding this statement:

"However, if  the other PE does not support Label Withdraw, it must 
generate an alarm, as Luca proposed in an earlier email."

If label withdrawal is a mandatory part of LDP, then how is it possible
that a PE may not support it?

Thanks
Shahram

> Sent: Thursday, February 24, 2005 5:07 PM
> Yes, Label Withdraw is a mandatory part of LDP per se. 
> However, the issue here is its usage in relation to OAM.
> 
> If we didn't have the situation with legacy equipment, the 
> OAM procedures are as described in the oam-msg-map draft, 
> i.e. in case of failures, generate AIS or send PW Status. To 
> deal with legacy equipment, the algorithm must now include a 
> check on the capabilities of the peer:
> 
> > > > > > >>>> I have made this point in an earlier email, 
> but I think 
> > > > > > it is worth

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 24 Feb 2005 17:48:21 -0500

> Sent: Thursday, February 24, 2005 5:41 PM

Perhaps my wording was imprecise. It should have been "if the other PE does not support Label Withdraw as a mechanism to signal AC or PW failures".

Does that help?

> > > > > > How  can the negotiation result in Label 
> Withdrawal, if it is 
> > > > > > not implemented?
> > > > > > 
> > > > > > > > 2) if label withdraw is not implemented , we 
> disable the 
> > > > > > PW with a 
> > > > > > > > 3) we do nothing. however in this case PW 
> messaging would 
> > > > > > be broken.
> > > > > > > >

---

From: [email-masked]
Date: Fri, 25 Feb 2005 10:37:36 -0000

Let me repeat the key messsages:
-	in any client/server relationship one must be able to
functionally decouple the client and server layer networks.  And one
corollary of this is that:
-	 events in the client layer network should not affect the server
layer network....
-	...and further, events in a given server layer trail that
supports a specific client layer link-connection must not result in
events in a *different* server layer trail that supports a *different*
client layer link connection.

Let me make sure the last point is understood (because this is
effectively what is being sanctioned here).

Assume a very simple client layer topology of 3 nodes A, B, and C with
link-connections between them of A-B and B-C.  Assume link-connection
A-B is provided by a server trail in technology X and that
link-connection B-C is provided by a server layer trail in technology Y
(we can substitute SDH, PDH, ATM whatever for X and MPLS or whatever for
Y).  

Now suppose there is a failure of the server layer trail in X.  Assuming
technology X is correctly functionally specified (like SDH is for
example) this will result in an FDI OAM message being mapped to the
client (across the X->client adaptation function).  Now this (FDI)
should get transferred in the client completely transparently across all
other link-connections....and in the very simple topology I gave this
means the link-connection supported by the trail in technology Y.

The arch that seems to be being agreed on here (without much operator
agreement I might add) means that failures in technology X (ie not the
client, that just get affected) get mapped to failure indications in
technology Y....which itself is plain wrong....but worse, if there is
the 'withdraw' notion, then failures in the server layer trail in
technology X will result in the removal of the trail in technology
Y.....now this is obviously very wrong, and speaking as an operator this
would be wholly unacceptable as a general arch principle.

You can now extend this argument to the case of >2 link-connections and
some arbitrary meshed client layer topology.....at what point do you
stop mapping a server layer failure in 1 technology supporting 1 client
layer link-connection to failure indications in other technologies
supporting a different client layer link-connection?

Also, just think what this also means for trying to define a prot-sw
strategy in the client layer network topology when server layer trails
on non-affected client link-connections just 'get taken away'.

The reason we are not seeing this consequence is that there are strict
topological constraining assumptions, ie a pair of 1-hop client
link-connections ('ACs') at each end (with unknown/undefined server
layer support), and a 1-hop PW/MPLS server layer supporting the middle
link connection (with unknown/undefined server layer support below
MPLS).  Any deviation from this to a more general case and the problems
I have highlighted will bite you.

If we had implemented what you guys are proposing as a general principle
in our current networks we would be in complete mess now.

regards, Neil

> Sent: 24 February 2005 22:48
> To: 'Shahram Davari'; 'Thomas D. Nadeau'; 'Luca Martini'
> [email-masked]'; Harrison,N,Neil,IKM1 R
> change to PW st atus.
> Perhaps my wording was imprecise. It should have been "if the 
> other PE does not support Label Withdraw as a mechanism to 
> signal AC or PW failures".
> 
> Does that help?
> 
> 
> > 
> > Thanks
> > Shahram
> > 
> [mailto:[email-masked]]
> > > > > > > > > However we need to agree on the logic of this 
> PW status 
> > > > > > procedure.
> > > > > > > > > If the PW status negotiation results in Label 
> Withdraw 
> > > > > > > method then :
> > > > > > > > >

---

From: "David Allan" <[email-masked]>
Date: Fri, 25 Feb 2005 07:24:17 -0500

> I think we have to spell out very clearly that the label 
> withdraw is not the way to signal AC state to the remote PE. 
> For this reason I also think the SHOULD should just be a MAY.

I agree with this. There are clearly consequences to a label withdraw that
must be supported, but it should not be used to communicate AC state (and
IMO administative state).

Dave

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 25 Feb 2005 08:45:27 -0500

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 25, 2005 5:38 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];

Neil,

I disagree with this statement. I hope you find time to read the latest version of the oam-msg-map draft. You will see that it attempts to prescribe the right behavior.

Unfortunately, not all existing protocols are structured as SDH and ATM. Therefore, the behavior that you would like to see is not always possible. Frame Relay does not support AIS. Therefore the observation that a FR DLC is down needs to be conveyed by other means: PW Status.

Another example is Ethernet. The current oam-msg-map draft is written for Ethernet applications that do not support Ethernet AIS. (Once the work in IEEE on Ethernet OAM progresses, we will probably write an extension to oam-msg-map that includes Ethernet AIS and that describes procedures similar to the ATM procedures described in oam-msg-map). In the absence of Ethernet AIS, one could consider that PWE is a form of service interworking: an Ethernet-over-ATM attachment circuit is connected to an Ethernet-over-PW pseudo wire, which in turn is connected to an Ethernet-over-FR attachment circuit. In that case, a defect in one attachment circuit could be translated to PW Status followed by AIS in the other attachment circuit. This may not be architecturally pure, but without Ethernet AIS it is the best one can do.

Below you also devote a paragraph to label withdraw as a means to signal failures and conclude that it is "wholly unacceptable as a general arch principle". I think we all realize that. That is why all emails in the past days have explicitly stated that interoperability with legacy equipment the ONLY reason that this is still mentioned in the draft. If you and other operators feel that interoperability with legacy equipment is not important, it would be helpful if you would share that with the list.

Peter

> > > > > > method then

---

From: Shahram Davari <[email-masked]>
Date: Fri, 25 Feb 2005 06:33:49 -0800

I will also go with MAY.

-Shahram

> Sent: Friday, February 25, 2005 7:58 AM
> To: David Allan
> Cc: "'Benny Ammitzboll'"; [email-masked]; Thomas D. Nadeau; Shahram
> Davari; [email-masked]; [email-masked];
> Busschbach, Peter B (Peter); Luca Martini
> OK, I give in to Benny and Dave.  Let's incorporate Benny's 
> clarification 
> and make the "SHOULD" a "MAY".
> 
> Thanks,
> Andy
> 
> -----------
> 
> At 2/25/2005 07:24 AM -0500, David Allan wrote:
>

---

From: [email-masked]
Date: Fri, 25 Feb 2005 16:44:23 -0000

Thanks Peter for a good/reasoned repsonse....some remarks below.
> I disagree with this statement.
NH=> I can understand why you might say this looking at the relationship
between a given a given client/server pair case and as per how PWs have
grown up.  But the above observations are general...and they are quite
accurate as to what is happening here (if you work through it...as per
the example I gave below in the preceding mail).

> I hope you find time to read 
> the latest version of the oam-msg-map draft. You will see 
> that it attempts to prescribe the right behavior.
NH=> I'll have a review of this at some point.  Still like to see MPLS
OAM done right irrespective of any mapping expediencies.
> 
> Unfortunately, not all existing protocols are structured as 
> SDH and ATM.
NH=> There are generic solutions in each mode.  None have been done
perfect to date.  But there is little excuse NOT to get this largely
right from now on is there? 

> Therefore, the behavior that you would like to 
> see is not always possible. Frame Relay does not support AIS. 
> Therefore the observation that a FR DLC is down needs to be 
> conveyed by other means: PW Status.
NH=> OK, but this should not stop us getting OAM right in new layer
network technologies.
> 
> Another example is Ethernet. The current oam-msg-map draft is 
> written for Ethernet applications that do not support 
> Ethernet AIS. (Once the work in IEEE on Ethernet OAM 
> progresses, we will probably write an extension to 
> oam-msg-map that includes Ethernet AIS and that describes 
> procedures similar to the ATM procedures described in 
> oam-msg-map). In the absence of Ethernet AIS, one could 
> consider that PWE is a form of service interworking: an 
> Ethernet-over-ATM attachment circuit is connected to an 
> Ethernet-over-PW pseudo wire, which in turn is connected to 
> an Ethernet-over-FR attachment circuit. In that case, a 
> defect in one attachment circuit could be translated to PW 
> Status followed by AIS in the other attachment circuit. This 
> may not be architecturally pure, but without Ethernet AIS it 
> is the best one can do.
NH=> I am aware of the work on eth OAM that is attempting to overlay a
co-ps behaviour on the native cl-ps behaviour.  However, FDI is not
really a valid OAM function in a true cl-ps mode network.
> 
> Below you also devote a paragraph to label withdraw as a 
> means to signal failures and conclude that it is "wholly 
> unacceptable as a general arch principle". I think we all 
> realize that. That is why all emails in the past days have 
> explicitly stated that interoperability with legacy equipment 
> the ONLY reason that this is still mentioned in the draft. If 
> you and other operators feel that interoperability with 
> legacy equipment is not important, it would be helpful if you 
> would share that with the list.
NH=>  IMO stds should reflect best-knowledge.....so if folks build
early, and to a draft, then there is a risk they will not be in
accordance with the finally ratified standard.  I think its an abuse of
standards to make them reflect what folks have built *if* there are
known problems.  

regards, Neil
> > link-connection B-C is provided by a server layer trail in 
> technology 
> > Y (we can substitute SDH, PDH, ATM whatever for X and MPLS or
> > whatever for
> > Y).  
> > 
> > Y.....now this is obviously very wrong, and speaking as an operator 
> > this would be wholly unacceptable as a general arch principle.
> > 
> > MPLS).  Any deviation from this to a more general case and the 
> > problems I have highlighted will bite you.
> > 
> > > > If label withdrawal is a mandatory part of LDP, then how is it 
> > > > possible that a PE may not support it?
> > > 
> > > 
> > > > > > > > > > label withdraw is not implemented, we 
> disable the PW 
> > > > > > > with a label
> > > > > > > > > > release error message.
> > > > > > > > > > 
> > > > > > > > > > 	--tom
> > > > > > > > > > 
> > > > > > > > > >

---

From: Shahram Davari <[email-masked]>
Date: Fri, 25 Feb 2005 11:38:31 -0800

Luca,

One more thing. When a PE withdraws a label, what should the other PE do?
Should it generate AIS? and if so how does it know that this is an
administrative label withdrawal or it is caused by AC being down?

-Shahram

> Sent: Friday, February 25, 2005 2:11 PM
> To: Shahram Davari
> Cc: 'Andrew G. Malis'; David Allan; 'Benny Ammitzboll'; [email-masked];
> Thomas D. Nadeau; [email-masked]; 
> [email-masked];
> Yes, as I said before the MAY will have more chances of passing the 
> AD/IESG review.
> here is the text :
> 
> ----------------------------------------------------------
> .Pc "Use of Label Mappings."
> administratively configures the pseudo wire down (or the PW
> section a simple label withdraw method MAY also be supported 
> as a legacy
> communication, and
> this method is not supported by the PE, then the PW MUST be 
> disabled and a
> label release message MUST be sent to the remote PE with the 
> following 
> error:
> 
> "Label Withdraw PW Status Method Not Supported"
> 
> If the label withdraw method for PW status communication is 
> selected for the
> PW, it  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.
> ----------------------------------------------------
> 
> I also corrected the spelling error that Tom pointed out.
> 
> Luca
> 
> 
> 
> Shahram Davari wrote:
> 
> >I will also go with MAY.
> >
> >-Shahram
> >
> >  
> >
> >>>I agree with this. There are clearly consequences to a label 
> >>>      
> >>>
> >>withdraw that
> >>    
> >>
> >>>must be supported, but it should not be used to communicate 
> >>>      
> >>>
> >>AC state (and
> >>    
> >>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 25 Feb 2005 14:44:20 -0500

Hi Luca,

Suggestions for a few minor modifications ...

> Yes, as I said before the MAY will have more chances of passing the 

I would use "operator" instead of "user".

> means of signaling PW status.

Strictly speaking, it should be "PW and AC status"

> In any case if the Label mapping is not
> disabled and a label release message MUST be sent to the
> remote PE with the following error:

I would prefer: "... this method is not supported by one of the PEs, than that PE must send a label release message to its peer with the following error ..."

I consider this an improvement because: (a) it removes the ambiguity of which PE is supposed to release the PW, and (b) the term "disable" is not defined in the document .

> the attachment circuit becomes active.

Perhaps it is more accurate to say "is active" instead of "becomes active".

---

From: Luca Martini <[email-masked]>
Date: Fri, 25 Feb 2005 14:23:48 -0700

Very good , I added all suggestions below.

Luca

---

From: Luca Martini <[email-masked]>
Date: Fri, 25 Feb 2005 14:26:57 -0700

>Should it generate AIS? and if so how does it know that this is an
yes, that should be specified in the technology specific draft.

>administrative label withdrawal or it is caused by AC being down?
It does not , that is why we have the new "better" method of PW status 
signaling using a PW status TLV , that indicates precisely what is 
happening.

Luca