RE: [PWE3] Pseudo Wire (PW) OAM Message Mapping

[neil.2.harrison at bt.com]

Hi Yaakov.....I am also generally OK with these restrictions now.  But let me just remind folks of the correct arch interpretation of 'network i/w' (which is an awful term IMO.....I think we should try and encourage folks to use the term 'client/server i/w'):

1.	the client and server layers must be independent in all aspects.....this applies to the data-plane, control-plane and management-plane;
2.	the client (all aspects, not just the traffic's data-plane) should be carried transparently over the server layer;
3.	defects detected at the server layer's trail termination point should be mapped (at the server->client adaptation function) to the client layer's semantic/syntax for FDI (Forward Defect Indication) in each/every client layer signal that is affected.

Note - I have used word 'should' above in rules 2 and 3 because not all cases will be satisfied for several reasons.  For example:
-	some clients don't (for historical reasons) have the required data-plane FDI function (or more general OAM functions), eg FR;
-	I know some folks will break (and indeed already have broken) these rules.....now this might be OK providing all parties affected understand and accept the consequences of doing this, but for some organisations these consequences might not be acceptable.

Why do we need these rules?

In case of 1, the most obvious reason is when the client and server layers are owned by different operating parties....so this is not just a technical requirement, it is an essential commercial requirement.  A further (more technical) reason is to allow independent protocol (in any plane) addition/change/removal.

In the case of 2, we don't want the server layer (at some client<->server adaptation point) to be terminating/processing specific client layer characteristic information (CI).  Moreover, client BW squeezing is not a key requirement, reducing complexity and opex costs are however.

In the case of 3, the primary intention is to prevent operational folks chasing inappropriate alarm indications, ie the key purpose of FDI is to tell higher layer clients that the failure lies in a lower layer network.  Note that this is a recursive behaviour upwards into any further higher layer layer networks that are supported.  Unless this is addressesd the inappropriate reporting of alarms can be geographically and organisationally widespread.  Finally, note that FDI should ideally be an OAM function of the data-plane because (i) trails may be set-up by NMS and not a signalling protocol and (ii) the indications should work even if the signalling function is not working.

Note the above is effectively embodied within G.805/809 (though these cover more than this, eg same-layer partitioning).  G.805/809 are generic for the 3 networking modes. Specific technologies are covered in their own Recs, eg ethernet is described in G.8010, and one of my colleagues is currently modelling the various flavours of MPLS.

One of the key issues to address when considering these client/server relationships are the 2 end-stops of the recursion.  One occurs at the bottom of the stack in terms of the 'physicals' (this is easy to deal with) and one occurs at the top of the stack where we have to interface to applications (this is harder to deal with).  We do not, as yet, have a common adaptation function agreed that has all the right properties for all cases.....and it is something we, as an industry, need to better understand and address.  To date each technology has done its own thing here.  This is also the key problem for properly coming to terms with (the so-called, again badly IMO) 'service i/w' case.  I will say no more on this here, though its something that needs considering by both IETF and ITU folks.....and I agree with Yaakov below when he urges that we should try and work together as an industry on this (though I also urge that we all should try and use G.805/809, as this is the starting point of achieving such a better understanding of what is really going on).

regards, Neil

> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of
> Yaakov Stein
> Sent: 03 March 2004 06:53
> To: Monique Morrow (mmorrow); Stewart; pwe3@ietf.org
> Subject: RE: [PWE3] Pseudo Wire (PW) OAM Message Mapping
> 
> 
> Monique, 
> 
> Now that the treatment has been limited to network interworking
> I support using this draft as a starting point for PWE's OAM work.
> 
> I agree with Shahram that the title should be PW OAM interworking.
> 
> I strongly suggest trying to harmonize this work with that being
> performed in ITU-T Q3/13.
> 
> I would be happy to help fill in the TBD in the section on TDM
> Encapsulation.
> 
> Y(J)S
> 
> > -----Original Message-----
> > From: Stewart Bryant [mailto:stbryant@cisco.com]
> > Sent: Sunday, February 29, 2004 11:15 PM
> > To: pwe3@ietf.org
> > Subject: [PWE3] Pseudo Wire (PW) OAM Message Mapping
> > 
> > 
> > Is there WG consensus for
> > 
> > Pseudo Wire (PW) OAM Message Mapping
> >
> http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-
map-04.txt

to be accepted as a WG draft?

- Stewart


_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3