Subject: RE: draft-nadeau-pwe3-oam-msg-map-04.txt

From: [email-masked]
Date: Thu, 25 Mar 2004 07:59:51 -0000

Hi Peter...a few observations below....
> Busschbach, Peter B (Peter) wrote 24 March 2004 15:01

> Ben,
> 
> If you read the draft, you will see that at no point it is 
> suggested that ATM or SONET alarms should be mapped to PW 
> alarms.
NH=> I am being pedantic here, but one does not map 'alarms' between layer networks under any situations....even those where the func arch requirements of layer networks involved are not violated.  The only OAM semantic that should be passed between layer networks is the FDI (the purpose being to *suppress alarms*)....and then only in an arch valid client/server case, this should not passed *between* layer networks when operating in a peer-partition sense.  And to be clear why, I have attempted an expanation below:

Peer-partition interworking has very different architectural requirements to client/server interworking.

The only pair of technologies that have tried peer-partition interworking to date are FR and ATM (see FRF.8 for example). Several points are of immediate note:

- The basic premise here (for both FR and ATM) is that we are selling the technology as the service.....which is not really where we operators want to be in the future (as this leads to the 'technology=service' stovepipe problem and proliferates the interworking problem).

- It largely ignores the 'common thing' that goes end-end between end-systems, ie what is the common interworking entity that is transparently handed from one network partition to the next?  This is the really critical thing to get right up-front if possible.

- It assumes there is a correlation of the behaviour, functions and features in each of the peer network partitions.

Let us deal with the last point above first, as this most easily shows why a FRF.8-like mind-set for peer-partition interworking is wrong in general.

Firstly, there may be a subconscious acceptance that each partition belongs to the same mode.....and in the case of FR and ATM then both belong to the co-ps mode.  But what happens when we want to interwork MPLS(co-ps)/ethernet(cl-ps)/SDH(co-cs) as peer-partitions?

This makes no sense in a FRF.8-type of context.  Perhaps the most obvious reason it makes no sense is that the functions and features of the each of the different mode/technologies don't have any common meaning.  For example ethernet as-is has no signalling, but MPLS and SDH might have.  Further, the defects that affect different modes/technologies are usually different, and thus have different OAM functions.  Further still, there is a 'priority' feature in ATM and FR (ie CLP and DE flags) but this does not exist in SDH say.  Similarly we find congestion indicators in ATM (EFCI) that are different in FR (FECN and BECN) and these don't even exist in MPLS or ethernet......and clearly this would have no valid interpretation in SDH anyway.  Finally, note that all technologies that belong to the co-cs mode do not have any traffic/QoS classes but these can exist in the other modes/technologies.

So, as a general architectural goal, it is clear that the peer-partition interworking model of FRF.8 is wrong for many reasons.  This has led us to formulate the following architectural rules for peer-partition interworking of different modes/technologies:

- We should aim to be clear about the 'thing' that is the common client to all the (server) layer peer partitions.  

- We must terminate all the CI (characteristic information, as defined in G.805/809) of the data-plane (at least) at the interworking point.

- Defects detected in a given peer-partition should be mapped to the appropriate FDI syntax of the 'thing' that is the common client.

There are many reasons why there is no point in trying to map some form of defect indication between the server peer partitions.  For example:
(i) the defects in each mode/technolgy can be quite different....so there may be no common semantic/syntax for the handling of defect indications in each technology partition;
(ii) it creates a 'defect relay-delay' and more chance to get this wrong;
(iii) it may create uncertainty of where the defect truly is and this may also cause defect handling problems (eg can't have CV and FDI say co-existing in a downstream partition that is not where the failure is);
(iv) it creates an N^2/2 mapping problem for all technologies that can form peer partition relationships;
(v) when one gets to the last peer partition technology in the sequence there is still a need to do something with the FDI indications at that point, ie tell the common client, so one might as well have done this at the peer partion where the defect originally occurred.

- There might be an opportunity to converge on some control-plane functions, eg same signalling......but this will depend of things like peer partition domain ownership (ie I-NNI vs E-NNI like issues), the commonality of the modes, etc.

> However, there are protocols that don't have the same 
> in-band OAM mechanisms as ATM and SONET, viz Frame Relay and 
> Ethernet. In Frame Relay, the way an alarm at one NNI is 
> conveyed to another NNI is not specified in the standards.
NH=> Excellent point.  But that is a failing of the FR layer network specifications.  And do not forget FR today can/is carried *transparently* on other server layer networks like ATM, PDH and SDH today.....the point being that it is the responsibility of the FR layer network here to 'look after itself'......so there should be no backwards implications on all other possible technologies that *could* be used to carry FR.  This is why layer network independence is so important in a client/server relationship.  So we should not compromise the specification of future generations of layer network technologies due to poor specifications of existing layer network technologies.  Sure, we can 'bend' the rules a bit, and when we do we should be clear of the consequences.....but the above mindset ought to be the goal.

> When a PW is used to connect the two NNIs, it was decided to 
> use PW Status messages to convey alarms. This is what the 
> draft describes and this is why the introduction mentions 
> "vice versa".
NH=> This may be a reasonable 'bending of the rules' here.  However, as noted, we should be clear that this is an exception to cater for migration and network evolution....it is not a correct arch solution.  Note - In a client/server case if we can ensure that the stds we produce *always* allow for transparent client layer conveyance over some server layer then that will be the correct arch default case.  Folks who then want to try and compress a client layer can do so providing they understand the consequences of doing so......but this behaviour should not be forced on others.

regards, Neil
> 
> Peter
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Wednesday, March 24, 2004 9:23 AM
> > To: [email-masked]
> > Subject: RE: [PWE3] draft-nadeau-pwe3-oam-msg-map-04.txt
> > 
> > 
> > Folks,
> > 
> > draft-nadeau-pwe3-oam-msg-map-04 states in the introduction 
> > "This document describes ... how faults detected in 
> > pseudo-wires are mapped to OAM messages native to the 
> > emulated services and vice versa".
> > 
> > I can see the need to map OAM up the network stack from the 
> > server layer OAM (e.g. a MPLS server layer) to the client AC 
> > OAM (e.g. an ATM client layer) but why is there a need to map 
> > OAM down the network stack from AC OAM to server layer OAM?
> > 
> > For example, today there are client/server relationships 
> > where ATM VPs (the client) are transported over SDH VC_4s 
> > (the server), defects in the SDH server layer are mapped 
> > upwards to the ATM client layer.  However defects in the ATM 
> > client layer are not mapped down to the SDH server layer.  
> > This is because defects in the client layer do not affect the 
> > server layer whereas defects in the server layer do affect 
> > the client layer.
> > 
> > Thanks
> > Ben
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>