Subject: PWE3 state information in context to ATM

From: "Roy, Anindya (Anindya)" <[email-masked]>
Date: Mon, 22 Mar 2004 10:12:23 -0500

Hi All,
	 
Would like to get the groups view on the following issue.

PWs can fail in a single direction or in both directions.However this may not be acceptable when the PWE3 are used to emulate ATM Layer2 connections, to maintain the integrity of the  bidirectional property of ATM connections.

My understanding is in order to preserve the integrity of the BI-DIRECTIONAL property of ATM VC/VP, any or both of the  following MUSTBE supported.

(1) If a PWE3 is emulating a ATM Layer 2 service, the PW must be bound to a *bi-directional* PSN tunnel because of the ATM's  bidirectional connection properties ?

(2) Incase the PW is allowed to setup over two disjoint unidirectional tunnels in each direction, then the implementation must maintain state information of both the tunnels in order to synchronize the operational state of the ATM VC's in both the  direction to handle situations of PSN failures in single direction.

If there is already a proposed solution can someone please provide a pointer.

Thanks.
Anindya

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 22 Mar 2004 10:32:24 -0500

Anindya,

See draft-nadeau-pwe3-oam-msg-map-04.txt

Section 6 covers the mapping of PW failures and alarms to ATM alarms and vice versa. Section 4.7 discusses some issues regarding the bi-directional nature of Pseudo Wires.

One point that is not clearly covered in the current draft and that was pointed out by Neil Harrison is that even if only one direction of a PW is down, from a perspective of SLAs and Performance Monitoring the entire emulated ATM VC must be considered failed.

Peter

> -----Original Message-----
> From: Roy, Anindya (Anindya) [mailto:[email-masked]]
> Sent: Monday, March 22, 2004 10:12 AM
> To: Roy, Anindya (Anindya); [email-masked]'
> Subject: [PWE3] PWE3 state information in context to ATM
> 
> 
> 
> Hi All,
> 	 
> PWs can fail in a single direction or in both 
> directions.However this may not be acceptable when the PWE3 
> are used to emulate ATM Layer2 connections, to maintain the 
> integrity of the  bidirectional property of ATM connections.
> 
> My understanding is in order to preserve the integrity of the 
> BI-DIRECTIONAL property of ATM VC/VP, any or both of the  
> following MUSTBE supported.
> 
> (1) If a PWE3 is emulating a ATM Layer 2 service, the PW must 
> be bound to a *bi-directional* PSN tunnel because of the 
> ATM's  bidirectional connection properties ?
> 
> (2) Incase the PW is allowed to setup over two disjoint 
> unidirectional tunnels in each direction, then the 
> implementation must maintain state information of both the 
> tunnels in order to synchronize the operational state of the 
> ATM VC's in both the  direction to handle situations of PSN 
> failures in single direction.
> 
>  
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Mon, 22 Mar 2004 17:56:34 -0000

Thanks Peter....small additional remark in-line....regards, Neil

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Busschbach, Peter B (Peter)
> Sent: 22 March 2004 15:32
> Subject: RE: [PWE3] PWE3 state information in context to ATM
> 
> 
> Anindya,
> 
> Section 6 covers the mapping of PW failures and alarms to ATM 
> alarms and vice versa. Section 4.7 discusses some issues 
> regarding the bi-directional nature of Pseudo Wires.
> 
> One point that is not clearly covered in the current draft 
> and that was pointed out by Neil Harrison is that even if 
> only one direction of a PW is down, from a perspective of 
> SLAs and Performance Monitoring the entire emulated ATM VC 
> must be considered failed.

NH=> Peter is right to mention this.  But it is also dependent on having consistent interpretations wrt processing events.  That is, there is a clear 'ordering' behaviour here which goes along these lines:

1	Get the arch of the mode in question right first.....

2	If you don't do this then you will not be able to correctly identify the relevant defects....the defects of a cl-ps mode (eg IP) are not the same as those that can occur in a co-ps mode (eg MPLS), and these are also not the same as the defects that can occur in a co-cs mode (eg SDH).  Now if you violate the arch of the mode (eg mp2p or PHP in MPLS) then you are asking for trouble, as the defects now get rather complex to detect/diagnose/handle (understatement).......hopefully many of you should know the story from here on in by now ;-)

3	You then need to define suitable OAM that can consistently and automatically detect/handle the identified defects, ie we need known entry/exit criteria and consequent actions specifying.

4	Now you can specify the unavailable entry/exit state of the trails based on defect persistency.....and this is where the 'ORing' of unidirectional failures that Peter mentioned is important because.......

5	Net Performance metrics (ie loss, errors, delay) are only meaningful whilst the trail is in the available state.  These are unidirectional in context whilst both directions are in the available state, but on failure of any direction then Net Perf measurements of both directions are no longer meaningful (at least wrt to any Net Perf SLA context).

6	Finally (though this should also be thought about up-front....well I did this anyway when drafting Y.1710/11), one needs to take a holistic view across all the possible client/server relationships to ensure there is some harmonised sense of consistency wrt what is being specified in each layer network in terms of defects, unavailability and Net Perf metrics.  This can't be totally aligned because each of the 3 modes are different.  However, some consideration of the harmonisation of these aspects is important because it has commercial implications for operator interworking and the services being offered.  Further, if MPLS is ever to achieve its potential to become a key convergence technology (and a few things need to happen for this to be true in our view), we operators will also need to think about global reference connections and the fair allocations of objectives in a horizontally partitioned sense, ie same layer network, between operators.  And how well one can address this is predicated on getting the ordering and consistency (of specification) as described above right.

Unfortunately PWs don't really help in any of this if you think about it....we need to do this wrt to the entity that is being *networked*....so that is a cl-ps pkt in IP and a co-ps trail in MPLS.  I wish folks would wise up on this sooner rather than later.

Now I don't think you can do this lot much simpler than what has been specified in Y.1711.

regards, Neil