Subject: Re: PW Status negotiation procedure

From: Luca Martini <[email-masked]>
Date: Tue, 23 Dec 2003 12:27:33 -0700

Rex Emmanuel Fernando wrote:

>Hi, Guys,
>
> It seems
>to me that the text which describes PW Status negotiation is flawed.
>
>This is what it says:
>
>---
>
>   "A PE that supports the PW Status TLV MUST include it in the initial
>   label mapping signaling as part of the PW FEC and following the
>   interface parameters field. The PW Status TLV will be used for the
>   lifetime of the Pseudowire for PEs that support this TLV.
>
>   If the PW Status TLV is not present in the initial PW FEC Message
>   received by a PE, then the PW Status TLV will not be used and both
>   PEs of the pseudowire will revert to the label withdraw procedure for
>   signaling status changes.
>
>   If PW status TLV is sent as part of the initial PW FEC Message, but
>   the remote PE corresponding FEC advertisement does not include a PW
>   status TLV, or the remote PE does not support the PW Status TLV then
>   the PW will revert to the label withdraw method to signal PW status.
>   Note that if the PW Status TLV is not supported it will automatically
>   be ignored since the LDP ignore bit is set."
>
>----
>
>The text says that the "PW Status TLV" should be part of the FEC TLV
>and following the interface parameters. Note that according to LDP spec
>a FEC TLV does not have sub-tlvs and I don't see a provision for
>having sub-tlvs within it. All it has is a contiguous array of different
>FEC types. So I am assuming that the PW Status TLV is *NOT* part of
>the FEC TLV but an additional TLV following the FEC TLV. Also note that
>the text says that old implementations which do not suppor this would
>ignore it - this is possible only if its a separate TLV and is not
>piggybacked on the FEC TLV. The text has to be corrected to relfect this. 
>
>  
>
Yes , I can see there is a problem in the description. And yes the 
status TLV is a separate TLV and MUST immediately follow the FEC TLV.

>The next question I have is, if the PW Status TLV follows the FEC TLV, to
>which FEC does it apply (note that a FEC TLV could have 'n' number of
>FECs). Does the PW status apply to all FECs ?
>  
>
not for the PW case. In IP you can have multiple FEC elements in the FEC 
( sharing of LSP for multiple IP addresses ), but for the PW it's only 
one FEC element per FEC so the status TLV will be only for the FEC 
element present.

>Correct me if I am wrong in any of these points.
>  
>
you are right on most of them :-)

>Also is there an IANA assigned number for the PW Status TLV type ?
>  
>
No. Not yet.

I'll send out a correction for the text above . it really meant to say 
"the PW Status TLV should immediately follow the FEC TLV" as in the 
picture...

Luca

>Thanks for your clarification.
>
>- Rex
>
>
>
>  
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 23 Dec 2003 14:54:29 -0500

In draft-shah-pwe3-control-protocol-extension-01.txt, 
we have recommended that this status TLV (or for that
matter any additional TLV) should be part of the
"optional parameter" field of the Label Mapping message.

/himanshu

http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-protocol-extension-01.txt

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Tuesday, December 23, 2003 2:28 PM
> To: Rex Emmanuel Fernando
> Cc: [email-masked]; Srihari Ramachandra Sangli; Renwei Li;
> Avneesh Sachdev; Rajesh Parikh; [email-masked]
> Subject: [PWE3] Re: PW Status negotiation procedure
> 
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Luca Martini <[email-masked]>
Date: Tue, 23 Dec 2003 14:34:17 -0700

Himanshu,

When we dicussed this months ago , I had pointed out that putting this 
in the optional parameter field , means that the FEC changes every time 
there is a status change. This would mean a withdraw a, and 
re-advertisement of the PW FEC.
It is too late to change anything now, But I was under the impression 
that the draft below would be amended to include only the IP TLV , and 
other VPLS related informantion.

Luca

Shah, Himanshu wrote:

>>>  "A PE that supports the PW Status TLV MUST include it in 
>>>      
>>>
>>the initial
>>    
>>
>>>  PEs of the pseudowire will revert to the label withdraw 
>>>      
>>>
>>procedure for
>>    
>>
>>>  If PW status TLV is sent as part of the initial PW FEC 
>>>      
>>>
>>Message, but
>>    
>>
>>>  the remote PE corresponding FEC advertisement does not 
>>>      
>>>
>>include a PW
>>    
>>
>>>  status TLV, or the remote PE does not support the PW 
>>>      
>>>
>>Status TLV then
>>    
>>
>>>  the PW will revert to the label withdraw method to signal 
>>>      
>>>
>>PW status.
>>    
>>
>>>  Note that if the PW Status TLV is not supported it will 
>>>      
>>>
>>automatically
>>    
>>
>>>and following the interface parameters. Note that according 
>>>      
>>>
>>to LDP spec
>>    
>>
>>>having sub-tlvs within it. All it has is a contiguous array 
>>>      
>>>
>>of different
>>    
>>
>>>the FEC TLV but an additional TLV following the FEC TLV. 
>>>      
>>>
>>Also note that
>>    
>>
>>>piggybacked on the FEC TLV. The text has to be corrected to 
>>>      
>>>
>>relfect this. 
>>    
>>
>>> 
>>>
>>>      
>>>
>>>The next question I have is, if the PW Status TLV follows 
>>>      
>>>
>>the FEC TLV, to
>>    
>>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 23 Dec 2003 17:01:08 -0500

The Status TLV is sent in label mapping message 
in "optional parameter" field as a  "capability learning" mechanism.

The changes in PW status (or others) is subsequently sent as 
LDP notification messages as per rev1 draft (we did listen to you :-).

I still believe that dispatching initial status tlv in optional
parameter field is a better choice than appending to the PW FEC.
Its a suggestion that you may want to consider....

Yes, we are going to update the draft to remove status related
stuff (as you have covered it in your draft) and keep IP TLV
and other stuff. So your impression is correct.

/himanshu

> Sent: Tuesday, December 23, 2003 4:34 PM
> To: Shah, Himanshu
> Cc: Rex Emmanuel Fernando; [email-masked]; Srihari Ramachandra
> Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh; [email-masked]
> Subject: Re: [PWE3] Re: PW Status negotiation procedure
> 
> 
> Himanshu,
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 24 Dec 2003 07:49:17 -0500

The changes to PWE3-control draft has to be determined
by Luca and his co-authors. We can only make recommendations.....

/himanshu

> From: Rex Emmanuel Fernando [mailto:[email-masked]]
> Sent: Wednesday, December 24, 2003 12:25 AM
> To: Shah, Himanshu
> Cc: 'Luca Martini'; [email-masked]; Srihari 
> Ramachandra Sangli;
> Renwei Li; Avneesh Sachdev; Rajesh Parikh; [email-masked]
> Subject: RE: [PWE3] Re: PW Status negotiation procedure
> 
> 
> 
> Himanshu,
> 
> As Luca seems to concur below the PW Status TLV has to be a 
> separate TLV 
> following the FEC TLV in the label mapping message. Having 
> said that I 
> agree with you that the correct way to carry this information 
> would be in 
> the optional parameters field in the label mapping message. 
> Any subsequent 
> change to the status is conveyed using LDP notification so there is
> no FEC churn. 
> 
> If we all agree on this could the authors make necessary changes to
> the draft so that we (implementors) could make forward progress ?
> 
> Thanks,
> 
> - Rex
> 
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Wed, 24 Dec 2003 17:59:19 -0500

draft-ietf-pwe3-iana-allocation-02 defines the following PW status codes.

0x00000000 - Pseudo Wire forwarding ( clear all failures)
0x00000001 - Pseudo Wire Not Forwarding
0x00000002 - Local Customer-facing PW ( ingress ) Receive Fault
0x00000004 - Local Customer-facing PW ( egress ) Transmit Fault
0x00000008 - Local PSN-facing PW ( ingress ) Receive Fault
0x00000010 - Local PSN-facing PW ( egress ) Transmit Fault

Could anyone explain what exactly is meant by each of these codes?

Here are the reasons I am uncertain about the semantics:

- Should "customer-facing PW" be read as "attachment circuit"? If not, I don't know what it is meant. From the perspective of a PE, I would think that the PW is always PSN-facing.

- I assume that "PSN-facing transmit fault" is an indication from one PE (PE1) to its peer (PE2) that there is a failure on the PW in the direction from PE1 to PE2. However, if that failure does indeed exist, how is the status indication  supposed to reach PE2?

- What is meant by "Pseudo Wire Not Forwarding"? When is this error code used instead of "PSN-facing PW receive fault" and/or "PSN-facing PW transmit fault"?

Peter

> From: Shah, Himanshu [mailto:[email-masked]]
> Sent: Wednesday, December 24, 2003 7:49 AM
> To: 'Rex Emmanuel Fernando'

---

From: Luca Martini <[email-masked]>
Date: Wed, 24 Dec 2003 16:28:57 -0700

>- Should "customer-facing PW" be read as "attachment circuit"? If not, I don't know what it is meant. From the perspective of a PE, I would think that the PW is always PSN-facing.
Yes,  It would probably make it easier to read if we corected the 
definition.  I take that attachment circuit does not mean attachment 
interface right ?

>- I assume that "PSN-facing transmit fault" is an indication from one PE (PE1) to its peer (PE2) that there is a failure on the PW in the direction from PE1 to PE2. However, if that failure does ind…
through the control channel. After all, the MPLS LSP can be broken , but 
IP connectivity can still exist.
I cant remember now, but there was some reason why we did not simply 
call this "Local PSN tunnel" .
we can change this if nobody else objects...

>- What is meant by "Pseudo Wire Not Forwarding"? When is this error code used instead of "PSN-facing PW receive fault" and/or "PSN-facing PW transmit fault"?
Somebody purposefully configures it to be administratively down.

Please keep in mind that these are general status singals, and not meant 
to carry the operational status information that a NOC would need.
Luca

>>>>in "optional parameter" field as a  "capability learning" 
>>>>        
>>>>
>>mechanism.
>>    
>>
>>>>LDP notification messages as per rev1 draft (we did listen 
>>>>        
>>>>
>>>to you :-).
>>>      
>>>
>>>>>Cc: Rex Emmanuel Fernando; [email-masked]; 
>>>>>          
>>>>>
>>>Srihari Ramachandra
>>>      
>>>
>>>>>It is too late to change anything now, But I was under 
>>>>>          
>>>>>
>>>the impression 
>>>      
>>>
>>>>>>http://www.ietf.org/internet-drafts/draft-shah-pwe3-control-p
>>>>>>            
>>>>>>
>>>>rotocol-extension-01.txt
>>>>        
>>>>
>>>>>> 
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Cc: [email-masked]; Srihari Ramachandra Sangli; 
>>>>>>>              
>>>>>>>
>>>Renwei Li;
>>>      
>>>
>>>>>>>>to me that the text which describes PW Status negotiation 
>>>>>>>>                
>>>>>>>>
>>>>>is flawed.
>>>>>          
>>>>>
>>>>>>>>This is what it says:
>>>>>>>>
>>>>>>>>---
>>>>>>>>
>>>>>>>> label mapping signaling as part of the PW FEC and 
>>>>>>>>                
>>>>>>>>
>>>following the
>>>      
>>>
>>>>>>>> interface parameters field. The PW Status TLV will be 
>>>>>>>>                
>>>>>>>>
>>>>>used for the
>>>>>          
>>>>>
>>>>>>>> If the PW Status TLV is not present in the initial 
>>>>>>>>                
>>>>>>>>
>>>PW FEC Message
>>>      
>>>
>>>>>>>> received by a PE, then the PW Status TLV will not be 
>>>>>>>>                
>>>>>>>>
>>>>>used and both
>>>>>          
>>>>>
>>>>>>>>The text says that the "PW Status TLV" should be part of 
>>>>>>>>                
>>>>>>>>
>>>>>the FEC TLV
>>>>>          
>>>>>
>>>>>>>>a FEC TLV does not have sub-tlvs and I don't see a 
>>>>>>>>                
>>>>>>>>
>>>provision for
>>>      
>>>
>>>>>>>>FEC types. So I am assuming that the PW Status TLV is 
>>>>>>>>                
>>>>>>>>
>>>*NOT* part of
>>>      
>>>
>>>>>>>>the text says that old implementations which do not suppor 
>>>>>>>>                
>>>>>>>>
>>>>>this would
>>>>>          
>>>>>
>>>>>>>>ignore it - this is possible only if its a separate 
>>>>>>>>                
>>>>>>>>
>>>TLV and is not
>>>      
>>>
>>>>>>>Yes , I can see there is a problem in the description. 
>>>>>>>              
>>>>>>>
>>>And yes the 
>>>      
>>>
>>>>>>>status TLV is a separate TLV and MUST immediately follow 
>>>>>>>              
>>>>>>>
>>>>>the FEC TLV.
>>>>>          
>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>which FEC does it apply (note that a FEC TLV could have 
>>>>>>>>                
>>>>>>>>
>>>>>'n' number of
>>>>>          
>>>>>
>>>>>>>one FEC element per FEC so the status TLV will be only 
>>>>>>>              
>>>>>>>
>>>for the FEC 
>>>      
>>>
>>>>>>>element present.
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>>>Also is there an IANA assigned number for the PW 
>>>>>>>>                
>>>>>>>>
>>>Status TLV type ?
>>>      
>>>
>>>>>>>>     
>>>>>>>>
>>>>>>>>                
>>>>>>>>
>>>>>>>No. Not yet.
>>>>>>>
>>>>>>>"the PW Status TLV should immediately follow the FEC 
>>>>>>>              
>>>>>>>
>>>TLV" as in the 
>>>      
>>>
>>>>>>>picture...
>>>>>>>
>>>>>>>Luca
>>>>>>>
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>              
>>>>>>>

---

From: Rex Emmanuel Fernando <[email-masked]>
Date: Tue, 23 Dec 2003 21:24:52 -0800 (PST)

Himanshu,

> Its a suggestion that you may want to consider....

As Luca seems to concur below the PW Status TLV has to be a separate TLV 
following the FEC TLV in the label mapping message. Having said that I 
agree with you that the correct way to carry this information would be in 
the optional parameters field in the label mapping message. Any subsequent 
change to the status is conveyed using LDP notification so there is
no FEC churn. 

Thanks,

- Rex

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 29 Dec 2003 10:23:21 -0500

> Sent: Wednesday, December 24, 2003 6:29 PM

> >- Should "customer-facing PW" be read as "attachment 
> circuit"? If not, I don't know what it is meant. From the 
> perspective of a PE, I would think that the PW is always PSN-facing.
> >  
> >

Luca,

That is a good point. I don't know what was originally intended, but it would make sense to clearly define what fault conditions are covered by these error codes.

Take, for example, a receive failure on an Attachment Circuit. In most cases such a failure indication should be propagated via failure notifications in the emulated protocol and not via the PW control plane. E.g. if the emulated service is ATM, the PE should translate a receive failure on the Attachment Ciruit to an AIS signal that is forwarded over the Pseudo Wire. There would be no need for a failure indication over the PW control plane.

I can see two exceptions:

1) When port-mode encapsulation is used. I.e. if there is no Native ATM Processing in the PE, the PE is not able to generate AIS signals (after all, it doesn't know which VCs are active). In that case, it would make sense to use the PW control plane to indicate a failure on the Attachment Circuit. 

2) When the failure occurs on the interface within the PE between the NSP module and the PW module. In that case, the NSP module is cut off from the PW module and can not be relied on for AIS generation. Hence, the need for a failure indication in the PW control plane so that the egress PE can generate AIS.

I think the OAM Message Mapping draft is the right place to identify under which conditions a PE should generate each of the PW status codes and how its peer should react. However, until a new version of that draft comes out, I would appreciate it if people could give more examples to illustrate when the PW status codes should be used.

Peter

> 
> >- I assume that "PSN-facing transmit fault" is an indication 
> from one PE (PE1) to its peer (PE2) that there is a failure 
> on the PW in the direction from PE1 to PE2. However, if that 
> failure does indeed exist, how is the status indication  
> supposed to reach PE2?
> >  
> >
> >- What is meant by "Pseudo Wire Not Forwarding"? When is 
> this error code used instead of "PSN-facing PW receive fault" 
> and/or "PSN-facing PW transmit fault"?
> >  
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 29 Dec 2003 10:28:16 -0500

> Sent: Wednesday, December 24, 2003 6:29 PM

[snipped]
> Somebody purposefully configures it to be administratively down.

I thought that  "PW administratively down" is normally reflected by releasing PW labels. Is there really a need to keep the PW up in an administrative down state?

[snppied to the end]

---

From: Luca Martini <[email-masked]>
Date: Mon, 29 Dec 2003 09:11:52 -0700

>I thought that  "PW administratively down" is normally reflected by releasing PW labels. Is there really a need to keep the PW up in an administrative down state?

yes. It is usually much more "work" to actually withdraw the label , and 
we thought it necessary to allow an easier mechanism to shut down the 
PW. By sending the status message we avoid having to release labels, 
unprogram hardware , etc.

Luca

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 29 Dec 2003 11:22:05 -0500

Original intent was to relay only "ability/inability to forward 
traffic between AC and PW" as the PW status indication. 
It seems that people wanted additional breakdown (when possible) for
diagnostic purposes.  As we dig deeper, if there is a need to 
further qualify an action per status per PW type, it will complicate
whole PW status handling.

I also think we need clearer rules on PW status handling to
avoid PW status deadlock.

/himanshu

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]]
> Sent: Monday, December 29, 2003 10:23 AM
> To: 'Luca Martini'
> Cc: Shah, Himanshu; 'Rex Emmanuel Fernando'; [email-masked];
> Srihari Ramachandra Sangli; Renwei Li; Avneesh Sachdev; Rajesh Parikh;
> [email-masked]
> That is a good point. I don't know what was originally 
> intended, but it would make sense to clearly define what 
> fault conditions are covered by these error codes.
> 
> Take, for example, a receive failure on an Attachment 
> Circuit. In most cases such a failure indication should be 
> propagated via failure notifications in the emulated protocol 
> and not via the PW control plane. E.g. if the emulated 
> service is ATM, the PE should translate a receive failure on 
> the Attachment Ciruit to an AIS signal that is forwarded over 
> the Pseudo Wire. There would be no need for a failure 
> indication over the PW control plane.
> 
> 1) When port-mode encapsulation is used. I.e. if there is no 
> Native ATM Processing in the PE, the PE is not able to 
> generate AIS signals (after all, it doesn't know which VCs 
> are active). In that case, it would make sense to use the PW 
> control plane to indicate a failure on the Attachment Circuit. 
> 
> 2) When the failure occurs on the interface within the PE 
> between the NSP module and the PW module. In that case, the 
> NSP module is cut off from the PW module and can not be 
> relied on for AIS generation. Hence, the need for a failure 
> indication in the PW control plane so that the egress PE can 
> generate AIS.
> 
> 
> I think the OAM Message Mapping draft is the right place to 
> identify under which conditions a PE should generate each of 
> the PW status codes and how its peer should react. However, 
> until a new version of that draft comes out, I would 
> appreciate it if people could give more examples to 
> illustrate when the PW status codes should be used.
> 
> Peter
> 
> 
> 
> > 
> > >>>>>>>not for the PW case. In IP you can have multiple FEC 
> elements 
> > >>>>>>>in the FEC

---

From: Luca Martini <[email-masked]>
Date: Mon, 29 Dec 2003 09:44:40 -0700

Peter,

You are correct , however, unlike ATM,  other protocols like ethernet 
etc. lack the ability to propagate the status information.
Also SP like built in SLA down time measurements, which require a status 
code from the remote PE to signal that something went wrong. In this 
case it can be difficult to snoop the data in the PW to glean the status 
of the PW itself.

Luca

Busschbach, Peter B (Peter) wrote:

>>>draft-ietf-pwe3-iana-allocation-02 defines the following PW 
>>>      
>>>
>>status codes.
>>    
>>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 29 Dec 2003 11:50:23 -0500

> Sent: Monday, December 29, 2003 11:22 AM
> To: 'Busschbach, Peter B (Peter)'; 'Luca Martini'
> Cc: 'Rex Emmanuel Fernando'; [email-masked]; Srihari 
> Ramachandra

Himanshu,

I am not entirely sure what you are arguing for. Are you saying that we should keep the PW status indication as simple as possible and not use the additional breakdown or are you saying that we shouldn't define consequent actions?

My personal view is:

- We should limit the use of PW status indication to very specific cases. There are other tools to provide additional diagnostics when necessary and it doesn't make sense to duplicate that functionality in PW status indications.

- We need to define consequent actions. When one PE sends a PW status indication to another PE, the receiving PE should perform some action, otherwise you might as well not send the message. It has to be clear what that action is. In many cases, that action will be the generation of a forward and/or backward Failure Indication in the emulated protocol. 

Peter

> > > >>>>>>>( sharing of LSP for multiple IP addresses ), but 
> for the PW 
> > > >>>>>>>it's only

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 29 Dec 2003 12:03:08 -0500

Luca> You are correct , however, unlike ATM,  other protocols like ethernet 
Luca> etc. lack the ability to propagate the status information.

But if the emulated protocol lacks the ability to propagate status information, what is the egress PE supposed to do?

To make sure that we are talking about the same thing:
Let's assume we have Attachment Circuit 1 connected to PE1, which is connected via a PW to PE2, which supports AC2.

My point was: if AC1 goes down, the NSP functionality in PE1 should generate Forward and Backward Defect indications. There is no need for a PW status indication. Your point is, if I am not mistaken, that there is a need for a status indication since the emulated prorocol may not have FDI and BDI defined.

So the question is: what good does it do to inform PE2 that AC1 is down, if PE2 is not able to propagate the failure indication over AC2 for lack of FDI?

Luca> Also SP like built in SLA down time measurements, which 
Luca> require a status 
Luca> code from the remote PE to signal that something went wrong. In this 
Luca> case it can be difficult to snoop the data in the PW to glean 
Luca> the status 
Luca> of the PW itself.

I don't understand this. If PE1 detects that there is a failure, why can't it send an alarm to the SP's fault management system? Are you assuming that the SP monitors PE2, but not PE1?

---

From: "Shah, Himanshu" <[email-masked]>
Date: Mon, 29 Dec 2003 12:20:36 -0500

comments below.

> Sent: Monday, December 29, 2003 11:50 AM
> To: Shah, Himanshu; Busschbach, Peter B (Peter); 'Luca Martini'
> I am not entirely sure what you are arguing for. Are you 
> saying that we should keep the PW status indication as simple 
> as possible and not use the additional breakdown or are you 
> saying that we shouldn't define consequent actions?

Keep status indications simple.  So if the rule is that when forwding
capability is compromised, PW status is generated irrespective
of whether it is ATM, FRL, ETH, RX down/TX down, RX up but TX is down,
or whatever. Similarly when PW status is received, PE performs
appropriate actions to AC based on AC type. 

Whatever is done for OAM interworking (between AC&PW at 
data plane level) is independent of PW status. But there needs
clearer action plans so that PW status ping pong does not
happen leading to PW status deadlock when each PE thinks
other is responsible for clearing the PW status.

/himanshu

> 
> My personal view is:
> 
> - We should limit the use of PW status indication to very 
> specific cases. There are other tools to provide additional 
> diagnostics when necessary and it doesn't make sense to 
> duplicate that functionality in PW status indications.
> 
> - We need to define consequent actions. When one PE sends a 
> PW status indication to another PE, the receiving PE should 
> perform some action, otherwise you might as well not send the 
> message. It has to be clear what that action is. In many 
> cases, that action will be the generation of a forward and/or 
> backward Failure Indication in the emulated protocol. 
> 
> Peter
> 
> > 
> > > > >>>>>in the optional parameter field , means that the 
> FEC changes 
> > > > >>>>>every time 
> > > > >>>>>that the draft below would be amended to include 
> only the IP 
> > > > >>>>>TLV , and 
> > > > >>>>>>>I'll send out a correction for the text above . 
> it really 
> > > > >>>>>>>meant to say

---

From: Luca Martini <[email-masked]>
Date: Mon, 29 Dec 2003 15:02:37 -0700

in section 4.1 of the control document:
4.1. Frame Relay

   When emulating a frame relay service, the Frame Relay PDUs are
   encapsulated according to the procedures defined in [7]. The PE MUST
   provide Frame Relay PVC status signaling to the Frame Relay network.
   If the PE detects a service-affecting condition for a particular
   DLCI, as defined in [2] Q.933 Annex A.5 sited in IA FRF1.1, PE MUST
   communicate to the remote PE the status of the PW corresponds to the
   frame relay DLCI. The Egress PE SHOULD generate the corresponding
   errors and alarms as defined in [2] on the egress Frame relay PVC.

In this case frame-relay does have an LMI protocol, and we indicate the 
failure to the CE using the LMI protocol.
I also think that when ethernet LMI is finalized , and actually widely 
implemented it can also be used in this instance.

Some SPs will also probably run VCCV , and would then want to notify the 
CE based on a detected failure. The customer might or might not be 
running ATM OAM F4/F5 loopback cell to monitor the circuit.

>I don't understand this. If PE1 detects that there is a failure, why can't it send an alarm to the SP's fault management system? Are you assuming that the SP monitors PE2, but not PE1?
this is for debugging , at the command line. From the router world point 
of view, there is no centralized management, just an alarm monitoring 
system. Then  the debugging work is done by logging into the device 
itself , and looking at output of a "show" command. In this case it is 
very useful to have an SLA down timer to measure when this happened. All 
of this can, of course, be implemented in the centralized management 
system, but realistically , information there might not be easy to gather.
This is just a nice thing to have , the main purpose remains as stated 
above.

Luca

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 29 Dec 2003 17:34:47 -0500

[snipped]
> >I don't understand this. If PE1 detects that there is a 
> failure, why can't it send an alarm to the SP's fault 
> management system? Are you assuming that the SP monitors PE2, 
> but not PE1?
> >
> >  
> >

I still don't understand it.

I thought we were discussing under which conditions PE1 needs to inform PE2 of the fact that AC1 (an Attachment Circuit on PE1) is down.

You seem to say that such an indication is necessary because it allows the operator to access an SLA down timer on PE2. My question is: why not just keep this information on PE1? After all, the interface that is down is attached to PE1.

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 29 Dec 2003 21:49:27 -0500

Thanks, Luca.

It was good that you included a quote from the control draft.  It is interesting that there is a fundamental difference between the way FR PVC status is propagated over a PW (i.e. using PW Status) and the way ATM PVC status is propagated. The Control Draft is not very clear about the ATM case, but the ATM Encapsulation draft specifies clearly that OAM cells should be used across the PW.

A few additional comments in line.

Peter

> Sent: Monday, December 29, 2003 5:03 PM
> To: Busschbach, Peter B (Peter)
> Cc: 'Shah, Himanshu'; 'Rex Emmanuel Fernando'; [email-masked];

It doesn't have to be the CE. It could be an adjacent Frame Relay switch.

> implemented it can also be used in this instance.

The question is whether Ethernet OAM will look more like Frame Relay or ATM. In the former case, PW Status should be used. In the latter case, Ethernet OAM messages should be propagated over the PW.

> running ATM OAM F4/F5 loopback cell to monitor the circuit.

Actually, connectivity would be checked with CC cells. Otherwise you are right: If the customer doesn't use CC cells to check ATM PVC status, he might use VCCV over the PW, or even some kind of connectivity verification over the underlying Transport LSP. However, that is tangential to my original comment. My point was that in case of a failure on the Attachment Circuit, the related PE should generate AIS or RDI signals over the encapsulated PVC instead of using PW Status messages to indicate PVC status to the remote PE. Since that is in line with the ATM Encpasulation draft, I assume you agree.

[snipped to the end]