Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

From: Ray Qiu <[email-masked]>
Date: Tue, 08 Jul 2008 11:43:42 -0400

This draft defines some useful mechanisms for end-to-end Ethernet OAM that
works with PWE3 technology.  I support it to be accepted as a WG document.

Cheers,
Ray

>We have a request to accept MPLS and Ethernet OAM Interworking
>
>http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
>
>as a working group draft.
>
>The authors thought that PWE3 had already agreed to this, but the
>minutes of the last meeting do not say that, and in any case
>we did not do a list poll.
>
>Please can we have views on whether to accept as WG draft
>by COB 15th July.
>
>Thanks
>
>Stewart/Danny
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: <[email-masked]>
Date: Tue, 15 Jul 2008 08:22:10 +0100

Thanks Maarten,

I don't have time right now to engage you in a detailed discussion of
all these points...many of which relate to the same issues you have with
my colleague Andy Reid etc in the SG15 unified modelling work, ie what
is a connection, etc.  However, I fully stand by what I said earlier wrt
key principles here....and to quickly summarise:
-	if a technology is so bad it must have complex OAM and be
monitored to death the problem lies with the technology/network design,
eg the FUD over the alarm storm issue to justify AIS where it is simply
not required nor used today, eg IP networks;
-	OAM must be as a simple and sparse of function as
possible...largely because it must be super reliable but also because it
has an opex cost to configure/run/process;
-	in all nested TCM proposals over the last 10+ years I have seen
no solution for their automatic configuration and accurate processing
handling across failures/restorations....if this stuff was so vital
we've have done loads of it by now...but for some reason we haven't.

Regards, Neil

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 14 July 2008 09:14
> To: Harrison,N,Neil,CXM R
> Cc: [email-masked]
> Subject: RE: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt 
> as WG draft
> 
> Neil,
> 
> AIS/FDI OAM for all technologies is associated with 
> configured point-to-point, point-to-multipoint, 
> rooted-multipoint and multipoint-to-multipoint 'transport 
> entities' (i.e.
> PDH/SDH/OTN/ATM/MPLS(-TP)connections, Ethernet VLANs 
> (inlcuding a standalone 802.1D network)). AIS will also be 
> associated with the point-to-point and point-to-multipoint 
> PBB-TE connections.
> 
> COCS, COPS and CLPS are three types of forwarding mode within 
> 'transport entities'. 'Transport entities' itself 
> **connection-oriented**, connection admission controlled and 
> traffic engineered; they are set up under management plane 
> control, with or without the help of a control plane.
> 
> - COCS is a forwarding mode in a 'transport entity' in which 
> every traffic unit is treated identically from a forwarding 
> perspective in the switch functions and link ingress points.
> - COPS is a forwarding mode in a 'transport entity'in which 
> every traffic unit is treated identically from a forwarding 
> perspective in the switch functions (same as COCS case), but 
> may be treated differently in link ingress points. In link 
> ingress points the CoS and Discard Eligibility of the traffic 
> unit determine the forwarding.
> - CLPS is a forwarding mode in a 'transport entity' in which 
> traffic units may be treated differently from a forwarding 
> perspective in switch functions and link ingress points. In 
> the link ingress points the CoS and Discard Eligibility of 
> the traffic unit determine its forwarding (same as in COPS 
> case). In the switch fucntions the value of a label within 
> the traffic unit (e.g. address label or demultiplexer label) 
> determines the forwarding of a traffic unit within the 
> 'transport entity'.
> 
> CLPS forwarding behaviour within 'transport entities' is 
> specified today for Ethernet VLANs and IP VPNs. 
> The label in the traffic unit that is used to determine which 
> output port or output ports of the VLAN/VPN 'transport 
> entity' should receive this traffic unit is the destination 
> address label.
> 
> 	Note that an 802.1D network is an Ethernet network with 
> a single VLAN (single 'transport entity'). 
> 	The 'internet' is an IP network with a single (public) 'IP VPN'
> (signle 'transport entity').
> 
> In **theory** it is possible to specify CLPS forwarding also in e.g.
> point-to-multipoint MPLS tunnels when those tunnels carry 
> point-to-multipoint MPLS PWs (with each PW carrying e.g. a TV 
> channel).
> Forwarding of a traffic unit within a MPLS tunnel connection 
> in a MPLS tunnel switch will - in a CLPS mode - depend on the 
> value of the PW label inside the traffic unit. For this 
> purpose PW labels will be registered per MPLS tunnel output 
> port, and if a PW label value X is not assocaited with a 
> tunnel output port Y, then the MPLS tunnel traffic unit will 
> not be forwarded via this output port Y.
> 
> OAM mechanisms are specified to monitor these 
> **connection-oriented** 'transport entities'. 
> OAM mechanisms are not specified to monitor the individual 
> traffic units or streams of traffic units that are 
> transported between ports of 'transport entities'.
> 
> AIS/FDI, LCK, OCI/UNEQ are OAM maintenance signals that are 
> generated within the scope of the **connection-oriented** 
> 'transport entity', including the Ethernet VLAN 'transport 
> entity'. That is why Ethernet AIS is specified in Y.1731, 
> G.8021 and G.8051. Without this Ethernet AIS OAM you will get 
> alarm storms in Ethernet VLAN and VPLS transport networks.
> 
> You need the AIS/FDI based alarm suppression mechanism as 
> soon as you deploy a 'transport entity' continuity check 
> mechanism and you can not guarantee that a broken 'transport 
> entity' has its connectivity restored within 2 seconds. As 
> PBB-TE tunnel connections are set up under management 
> control, PBB-TE AIS will be necessary to prevent PBB-TE 
> tunnel Loss of Continuity alarm storms after a cable with 96 
> fibers, each carrying e.g. 80 40G wavelengths is broken.
> 
> Note that a Server MEP has nothing to do with TCM. A Server 
> MEP is a MEP in the server layer. Example of ETH Server MEP 
> function: SDH VC-n termination plus Sn/ETH adaptation function.
> 
> ---
> 
> Every layer has three types of Maintenance Entity Groups 
> (MEG) within a 'transport entity':
> 1) Network Connection (NC) MEG level
> 2) Tandem Connection (TC) MEG level
> 3) Link Connection (LC) MEG level.
> 
> The NC-MEG level is always present in a layer network 
> supporting OAM. It is however an operator's choice to deploy 
> the available OAM at this NC-MEG level.
> 
> TC-MEG and LC-MEG level presence depend of the layer 
> network's role (transport service layer, transport tunnel 
> layer, transport link layer), single/multi-owner status of 
> the 'transport entity' and survivability
> (protection) requirements.
> 
> 
> A) Transport Link (or Section) layer requires typically 
> support of the NC-MEG level only; i.e. case of I-NNI and E-NNI. 
> Only when this link/section layer signal is treated as a 
> port-based service TC-/LC-MEG levels will become important; 
> i.e. case of UNI.
> 
> B) Transport Tunnel (or Path) layer requires typically 
> support of the NC-MEG level only; i.e. case of I-NNI and E-NNI.
> When this tunnel/path layer signal is treated as an 
> individual or bundled service entity, then TC-/LC-MEG levels 
> will become important; i.e. case of UNI and carrier-carrier.
> Tunnel protection switching is assumed to be performed 
> between PE nodes using the NC-MEG level MEP functions to 
> monitor for SF/SD status.
> 
> C) Transport service (or Channel) layer requires support for 
> the NC-MEG level and possibly for TC-MEG and LC-MEG levels as well.
> When the service/channel layer 'transport entity' starts/ends 
> inside the transport network (at UNI-N ports) of a single 
> network operator and if such 'transport entity' is not 
> protected, then the NC-MEG will be the only active MEG level. 
> When protection of a 'transport entity' segment is required, 
> a TC-MEG level is necessary to monitor the segment.
> When two or more network operators provide the 'transport 
> entity', each operator want to be able to monitor the 
> status/performance of the 'transport entity' segment in its 
> network; this requires the presence of a TC-MEG level.
> When the 'transport entity' starts/ends in the customer 
> domain, the NC-MEG level is owned by the customer and the 
> transport network must deploy a TC-MEG level to monitor the 
> status/performance provided by the transport network between 
> the UNI-N ports. For this case, the LC-MEG level may be used 
> to monitor the status/performance of the 'transport entity' 
> segment on each UNI (CE to T-PE) and E-NNI.
> 
> When the PBB-TE tunnel layer is a tunnel/path layer operated 
> within the administrative domain of a single network operator 
> you will need only the NC-MEG level. 
> As soon as PBB-TE tunnel connections may start/end in the 
> customer domains or in two network operator domains, PBB-TE 
> tunnel layer will need TC-MEG and LC-MEG levels.
> 
> Regards,
> Maarten
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 12 July 2008 10:16
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt 
> as WG draft
> 
> Thank you Jon....some attempted answers in-line: 
> [email-masked] wrote 11 July 2008 18:22
> 
> > Hi Neil,
> > 
> > A quick query on the subject of AIS:
> > 
> > I understand your summary of the background of AIS, but there is 
> > surely still a requirement for a triggered forward error 
> indication of 
> > some form?  ATM defined AIS cells for this function, so there is 
> > already a precedent for this function in a co-ps network.
> NH=> Yes, that is true.  However, it's not as obvious a 
> requirement as you might think.  FDI requires a persistent 
> binding of a client and server layer network, ie the sever, 
> on failure, needs to be sure who its clients are in order to 
> inject FDI into them....it's not much good if those clients change.
> This long-lasting client/server permanence has been a 
> traditional truth in nested PDH/SDH co-cs mode transport 
> layer networks...which is of course where the notion of AIS 
> comes from as I explained.  But what if the clients can 
> change more dynamically?  Start by envisioning co-cs or co-ps 
> mode SVC clients (eg co-cs PSTN) which have shrinking holding 
> times......in the limit this become a single message of a 
> cl-ps mode client layer network.  So if we imagine a link 
> connection in such a client layer network (ie a single hop 
> between 2 adjacent client layer nodes which is provided by a 
> network connection in some lower layer server network) it 
> becomes quite clear that we cannot assign any permanence 
> between a specific client communications instance and their 
> use (or not) of that link (=server network connection).
> Hopefully you can see that.  And this is why it makes no 
> sense whatsoever to carry over the idea of AIS/FDI into cl-ps 
> mode layer networks and explains why IEEE had the good sense 
> to take AIS out of 802.1ag.
> 
> We discussed the issue of FDI within BT when considering the 
> OAM we would want for PBB-TE (co-ps mode based on using the 
> original cl-ps Ethernet traffic unit), and on balance we 
> considered it was not a good idea.
> However, the CV and BDI OAM functions are essential....but 
> they should NOT be piggybacked in order that we can properly 
> address the p2mp connection case.
> 
> But as I also noted in my mail, a key requirement on OAM (at 
> least that used for defect detection) is that it is super 
> reliable, and that tends to mean as sparse as possible of 
> function with minimal configuration.
> Anything that requires lots of config (and the TCM stuff 
> factors heavily here - see later comment) is really not a requirement.
> > 
> > The problem that I foresee is that, although ethernet is inherently 
> > cl-ps, Ethernet will be extensively used in a p2p manner, 
> especially 
> > when ethernet is used as a tail circuit to an IP service.  In this 
> > case, I think that an AIS function is valid.  If this is not 
> > available, would we not need to have CCM enabled in all cases?
> NH=> Please remember that CV and FDI are very different.  CV 
> checks THIS layer network, FDI is an indication of failure 
> (possibly from a CV flow detected defect) in a LOWER layer 
> network.  I've seen folks try and 'do away' with CV and just 
> use FDI...it's a mistake.....as to get FDI SOME layer network 
> has to be able to detect it's failures, and it won't always 
> be the section layer, ie very bottom of stack, that can do this.
> No CV means you are blind to defects in your layer network, 
> you only see server layer defects IFF they generate a FDI 
> into your layer network across the adaptation function...and 
> as explained above, FDI/AIS is not such a great idea as folks 
> might think.
> > 
> > Maybe the problem stems from the fact that SPs are often 
> trying to use 
> > Ethernet, that is inherently connectionless, in a 
> connection oriented 
> > manner!
> NH=> Well yes....but the mere fact that special topology 
> consideration exists (ie the p2p degenerate network case you 
> mentioned above) is not the general network case.  
> > 
> > > Quite.....need to start getting these things right (here a
> > transparent
> > > client/server layer network relationship).
> > Yes, seems to be the root of a lot of issues we are running into!
> NH=> It is rather important/fundamental....but it is violated 
> all over the place.  I'll say no more on the matter here.
> 
> > Is it worth noting that Y.1731 seems to have defined a server layer:
> > "NOTE - A Server MEP needs to support ETH-AIS function, as 
> described 
> > in sub-clause 7.4, where the Server/ETH adaptation function is 
> > required to issue frames with ETH-AIS information upon detection of 
> > defect at the Server layer by the Server layer termination and/or 
> > adaptation function."
> NH=> This is all about TCM.  One might like to observe that 
> in any general layer network only the access points are 
> fixed....intermediate points can change, and indeed MUST 
> change if we want to have resiliency.
> (You may be struck here by the similarities to the point I 
> made earlier regarding FDI and how one can't assume a 
> permanence between a client communications instance and the 
> links (=server layer connections) it is using at any epoch).  
> Now try and get your head around how you would manage the 
> config of such (moveable) intermediate points, especially if 
> you were trying to get accurate perf mon (PM) data across 
> failures and restorations.
> TCM sounds good on paper, but show me the management 
> solutions for PM across dynamic changes of routing.  Hint=> 
> I've looked quite closely at doing this at end points that 
> are time invariant/fixed in the past and this is not a simple 
> problem even here (eg pkts in-flight, clock differences) now 
> extrapolate that problem to a raft of nested TCM levels that 
> are not invariant/fixed....let me know when you have an 
> answer for PM in TCM across failures/restorations ;-)
> 
> Regards, Neil
> 
> 
> > 
> > Cheers,
> > ~Jon.
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > On Behalf
> > > Of [email-masked]
> > > Sent: 09 July 2008 20:18
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> > > as WG draft
> > > 
> > > Hi Dinesh and Ali,
> > > 
> > > A few observations on the draft and the subject of OAM in
> > general that
> > > you might like to take into account:
> > > 
> > > 1	Despite what some folks having been trying to do in ITU the OAM
> > > required for each of the 3 network modes (cl-ps, co-ps and
> > > co-cs) is not the same.  For example, AIS is mentioned in
> > the draft.  
> > > AIS has its roots in co-cs mode PDH/TDM networks.
> > > AIS is about alarm suppression (in co mode clients 
> *above* a server
> > > failure) not generating alarms.  It was a direct 
> consequence of old 
> > > TTL logic when, on failure, the logic 'floated' to +5V (ie binary 
> > > 1).....so a binary all 1s signal was the natural indication
> > of failure
> > > here.  Note in particular it is a passive signal....in the
> > sense that
> > > we don't have to actively create special traffic units to
> > mimic it as
> > > we would in any packet network.  Further, since the co-cs mode is 
> > > characterised by a constant bit rate signal AIS is naturally a 
> > > constant stream of binary all 1s (when replacing the
> > traffic signal).
> > > 
> > > AIS is however not a natural signal in packet networks.  
> > And whilst it
> > > is understandable to want to have an AIS/FDI OAM function 
> in co-ps 
> > > mode layer networks (on the assumption they have proper
> > single source
> > > connections, ie p2p or p2mp constructs only) it has no meaning in 
> > > cl-ps mode networks, eg IP, Ethernet.  And this, of 
> course, is why 
> > > IEEE saw fit to deprecate AIS in 802.1ag for Ethernet OAM.
> > > 
> > > My view is that IETF should align its position with that of
> > the IEEE
> > > standards when dealing with Ethernet OAM.
> > > 
> > > 
> > > 
> > > 2	I note that the BDI (or RDI) function has been piggy-backed in
> > > CC messages in both Y.1731 and 802.1ag.  In the case of
> > co-cs or co-ps
> > > mode layer networks this only works for symmetrical bidirectional 
> > > connections, ie p2p constructs only.  It does not work for p2mp 
> > > connection constructs (as these cannot be bidirectionally
> > symmetric)
> > > and so a CC message and a BDI message need to be
> > distinct/independent
> > > OAM messages here.
> > > This is something to bear in mind for GMPLS (controlled 
> co-cs mode 
> > > layer network connections), MPLS and PWs (assuming the 
> case of both 
> > > these supporting proper single source co-ps connections).
> > > 
> > > Now of course Ethernet is a cl-ps mode technology so we 
> don't have 
> > > connections. However, if we make the OAM CC message a broadcast 
> > > function between MEPs then we force a condition of symmetry
> > here and
> > > so one can, in principle, piggyback BDI in CC
> > messages.....the traffic
> > > of course can be, and usually is, unicast (once SA MAC 
> learning has 
> > > taken place).  So the first observation here is that the 
> OAM is not 
> > > exercising exactly the same processing path as the traffic.
> >  Further,
> > > the indiscriminate broadcasting of BDI to N far-ends wrt to
> > an unknown
> > > number of incoming failures is hardly good practice (see
> > section 7.5
> > > in Y.1731).
> > > 
> > > However, the key point I am making here is the former one,
> > ie when we
> > > are dealing with proper co-cs or co-ps mode p2mp
> > connections we cannot
> > > piggyback BDI in CC messages.
> > > 
> > > 
> > > 3	It is a very, very bad idea to have client layer defects
> > > reflected in a server layer network (be this DP/CP/MP).  I
> > just noted
> > > Yaakov also allude to this point in his mail 09 July 2008
> > 17:31, viz:
> > > 
> > > "However, I would like to reiterate what I said in Philadelphia.
> > > I am not a great fan of OAM mapping at all, and wouldn't
> > care if the
> > > present oam-msg-map draft died a natural death.
> > > Ethernet to Ethernet PW OAM interworking is an evil, but
> > frequently a
> > > necessary one.
> > > Work on it needs to be expedited."
> > > 
> > > Quite.....need to start getting these things right (here a
> > transparent
> > > client/server layer network relationship).
> > > 
> > > 
> > > 4	Final, and far more general, point....OAM needs to be uber
> > > reliable...far more so than the intrinsic failure rate of
> > the network
> > > it resides in.  So defect detection/handling OAM needs to be as 
> > > simple/sparse as possible.  Collecting OAM (esp Perf Mon OAM) 
> > > information also has a real opex cost.
> > > Ops folks will turn-off as much OAM as they can...esp
> > bloated/bad OAM
> > > (Y.1731 is bloated IMO).  I've just noticed TCM (Tandem Connection
> > > Monitoring) has been added to the
> > > PWE3 charter.  I would strongly advise IETF *not* to go here just 
> > > because others have included this in their standards.
> > > This idea has been around for many years in ITU and there 
> are very 
> > > good reasons why very little of it is used in practice (I 
> can spell 
> > > this out if not obvious).
> > > 
> > > Regards, Neil
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf
> > > > Of Dinesh Mohan
> > > > Sent: 08 July 2008 16:08
> > > > To: [email-masked]; pwe3
> > > > Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> > > > as WG draft
> > > > 
> > > > Stewart, of course as an author I support this as a WG draft :-)
> > > > 
> > > > FYI...an updated version of the document is also
> > available based on
> > > > feedback during the meeting and some further offline
> > > > discussions:
> > > > http://www.ietf.org/internet-drafts/draft-mohan-pwe3-mpls-eth-
> > > > oam-iwk-01
> > > > .txt
> > > > 
> > > > If we agree, this could be the version that can be accepted for 
> > > > working group draft.
> > > > 
> > > > ---
> > > > Dinesh
> > > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf
> > > > Of Stewart Bryant
> > > > Sent: Tuesday, July 08, 2008 7:35 AM
> > > > To: pwe3
> > > > Subject: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> > as WG draft
> > > > 
> > > > minutes of the last meeting do not say that, and in any
> > case we did
> > > > not do a list poll.
> > > > 
> > > by COB 15th
> > > > July.
> > This e-mail has been scanned for viruses by the Cable & Wireless 
> > e-mail security system - powered by MessageLabs. For more 
> information 
> > on a proactive managed e-mail security service, visit 
> > http://www.cw.com/uk/emailprotection/
> > 
> > The information contained in this e-mail is confidential 
> and may also 
> > be subject to legal privilege. It is intended only for the
> > recipient(s) named above. If you are not named above as a 
> recipient, 
> > you must not read, copy, disclose, forward or otherwise use the 
> > information contained in this email. If you have received 
> this e-mail 
> > in error, please notify the sender (whose contact details 
> are above) 
> > immediately by reply e-mail and delete the message and any 
> attachments 
> > without retaining any copies.
> >  
> > Cable and Wireless plc
> > Registered in England and Wales.Company Number 238525 Registered
> > office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
> >

---

From: <[email-masked]>
Date: Tue, 15 Jul 2008 09:09:38 +0100

Maarten,

I see the same issues here as in SG15 unified modelling wrt what
is/is-not a connection.  Irrespective of how one dresses it up this is
the key observation:
-	we can deterministically control resource assignment in p2p and
p2mp constructs (==connections)
-	we cannot deterministically control resource assignment in mp2p
or mp2mp constructs.
....and a whole raft of issues relating to SLAs, performance
inheritance, OAM, etc flow from this.

Trying to force traditional co OAM behaviour in cl mode technologies is
not a good idea IMO, eg AIS....but I do understand the motivation and
good intentions.  Sure we can overlay a set of N fixed points in a cl
mode network and broadcast a periodic CC+BDI function to them
all.....but you honestly expect me to buy-into a set of up to 8 nested
TCM levels all doing this, of which only the outer (ie access points)
remain invariant across failures/restorations?   And as N->large do
really think this is good idea?

Even Y.1731 recognises there is an issue with piggybacking BDI in
CC....section 7.5 says (in particular see text delimited by **):

7.5	Ethernet Remote Defect Indication (ETH-RDI)
Ethernet Remote Defect Indication function (ETH-RDI) can be used by a
MEP to communicate to its peer MEPs that a defect condition has been
encountered. ETH-RDI is used only when ETH-CC transmission is enabled. 
ETH-RDI has the following two applications:
*	Single-ended fault management: The receiving MEP detects an RDI
defect condition, which gets correlated with other defect conditions in
this MEP and may become a fault cause. The absence of received ETH-RDI
information in a single MEP indicates the absence of defects in the
entire MEG
*	Contribution to far-end performance monitoring: It reflects that
there was a defect condition in the far-end which is used as an input to
the performance monitoring process.

A MEP that is in a defect condition transmits frames with ETH-RDI
information. A MEP, upon receiving frames with ETH-RDI information,
determines that its peer MEP has encountered a defect condition.
**However, for multipoint ETH connectivity, a MEP, upon receiving frames
with ETH-RDI information, cannot determine the associated subset of its
peer MEPs with which the MEP transmitting RDI information encounters
defect conditions, as the transmitting MEP itself does not always have
that information.**
Specific configuration information required by a MEP to support ETH-RDI
function is the following:
*	MEG Level - MEG Level at which the MEP exists
*	ETH-RDI transmission period - application dependent and is
configured to be the same as ETH-CC transmission period.
*	Priority -identifies the priority of frames with ETH-RDI
information. The priority is the same as ETH-CC Priority.
*	Drop Eligibility - Frames with ETH-RDI information are always
marked as drop ineligible. This information is not necessarily
configured.
A MIP is transparent to frames with ETH-RDI information and therefore
does not require any configuration information to support ETH-RDI
functionality.
The PDU used to carry ETH-RDI information is CCM, as described in
sub-clause 9.2. 

7.5.1	CCM with ETH-RDI Transmission
A MEP, upon detecting a defect condition with its peer MEP, sets the RDI
field in the CCM frames for the duration of the defect condition. CCM
frames, as described in sub-clause 7.1.1, are transmitted periodically
based on the CCM transmission period, when the MEP is enabled for CCM
frames transmission. When the defect condition clears, the MEP clears
the RDI field in the CCM frames in subsequent transmissions.

7.5.2	CCM with ETH-RDI Reception
Upon receiving a CCM frame, a MEP examines it to ensure that its MEG
Level corresponds to its configured MEG Level and detects RDI condition
if the RDI field is set. For a point-to-point ETH connection, a MEP can
clear the RDI condition when it receives the first CCM frame from its
peer MEP with the RDI field cleared. **For multipoint ETH connectivity,
a MEP can clear the RDI condition when it receives the CCM frames from
its entire list of peer MEP with the RDI field cleared.**

Regards, neil

> Sent: 14 July 2008 10:02
> To: Harrison,N,Neil,CXM R; [email-masked]; [email-masked]
> > 2	I note that the BDI (or RDI) function has been 
> piggy-backed in CC
> messages in both Y.1731 and 802.1ag.
> > In the case of co-cs or co-ps mode layer networks this only 
> works for
> symmetrical bidirectional connections,
> > ie p2p constructs only.  It does not work for p2mp connection 
> > constructs
> (as these cannot be bidirectionally symmetric)
> > OAM
> messages here. 
> You make a mistake here. First you have to specify what a 
> bidirectional p2mp connection looks like and how the traffic 
> flows, then you can address the CC and RDI/BDI OAM mechanism.
> 
> 1) A n-port bidirectional p2mp connection consists of either
>   - one unidirectional p2mp connection from A to Z1..Zn-1 and
>   - n-1 unidirectional p2p connections from Zi to A (i=1, .., n-1), or
>   - one unidirectional p2mp connection from A to Z1..Zn-1 and
>   - one unidirectional mp2p connection from Z1..Zn-1 to A.
> 
> Traffic flows from A to Zi.
> OAM flows from A to Zi and from Zi to A.
> 
> Question: is there also traffic from Zi to A? 
> 
> The second case (p2mp + mp2p) connection can be supported in 
> a transport tunnel layer. This p2mp/mp2p connection carries 
> transport service layer unidirectional and bidirectional p2p 
> connections and/or unidirectional p2mp connections, which 
> have unique label values within the p2mp/mp2p tunnel 
> connection. Example: MPLS p2mp/mp2p tunnel with bidir p2p PWs 
> and unidir p2mp PWs, Ethernet asymmetric VLAN without MAC learning.
> 
> The first case can be supported in a transport service layer 
> and transport tunnel layer. 
> 
> 2) For the first case when there is no traffic from Zi to A, 
> the CC function checks the A to Zi (i=1, .., n-1) maintenance 
> entities and the signal fail status at the Zi ends is 
> reported via RDI/BDI function from Zi to A. The CC fucntion 
> between Zi and A checks if the Zi to A connection is 
> operational and thus able to carry RDI/BDI from Zi.
> There is as such no problem to combine CC and RDI/BDI OAM in 
> a single OAM message.
> 
> For the second case (p2mp/mp2p tunnel connection) CC function 
> checks the A to Zi Maintenance Entities and the signal fail 
> status at the Zi ends is reported via RDI/BDI function from 
> Zi to A. The CC fucntion between Zi and A checks if the Zi to 
> A maintenance entity is operational and carries the RDI/BDI 
> from Zi. At A, the status of the mp2p unidir 'transport 
> entity' is computed from the status of the individual p2p 
> maintenance entities; the result is reported from A to Zi via 
> the RDI/BDI inside the CC from A to Zi.
> There is as such no problem to combine CC and RDI/BDI OAM in 
> a single OAM message.
> 
> Regards,
> Maarten
> 
> Sent: 09 July 2008 21:18
> general that you might like to take into account:
> 
> co-cs) is not the same.  For example, AIS is mentioned in the 
> draft.  AIS has its roots in co-cs mode PDH/TDM networks.  
> AIS is about alarm suppression (in co mode clients *above* a 
> server failure) not generating alarms.  It was a direct 
> consequence of old TTL logic when, on failure, the logic 
> 'floated' to +5V (ie binary 1).....so a binary all 1s signal 
> was the natural indication of failure here.  Note in 
> particular it is a passive signal....in the sense that we 
> don't have to actively create special traffic units to mimic 
> it as we would in any packet network.  Further, since the 
> co-cs mode is characterised by a constant bit rate signal AIS 
> is naturally a constant stream of binary all 1s (when 
> replacing the traffic signal).
> 
> AIS is however not a natural signal in packet networks.  And 
> whilst it is understandable to want to have an AIS/FDI OAM 
> function in co-ps mode layer networks (on the assumption they 
> have proper single source connections, ie p2p or p2mp 
> constructs only) it has no meaning in cl-ps mode networks, eg 
> IP, Ethernet.  And this, of course, is why IEEE saw fit to 
> deprecate AIS in 802.1ag for Ethernet OAM.
> 
> the IEEE standards when dealing with Ethernet OAM.
> 
> 
> 
> CC messages in both Y.1731 and 802.1ag.  In the case of co-cs 
> or co-ps mode layer networks this only works for symmetrical 
> bidirectional connections, ie p2p constructs only.  It does 
> not work for p2mp connection constructs (as these cannot be 
> bidirectionally symmetric) and so a CC message and a BDI 
> message need to be distinct/independent OAM messages here.  
> This is something to bear in mind for GMPLS (controlled co-cs 
> mode layer network connections), MPLS and PWs (assuming the 
> case of both these supporting proper single source co-ps connections).
> 
> Now of course Ethernet is a cl-ps mode technology so we don't 
> have connections. However, if we make the OAM CC message a 
> broadcast function between MEPs then we force a condition of 
> symmetry here and so one can, in principle, piggyback BDI in 
> CC messages.....the traffic of course can be, and usually is, 
> unicast (once SA MAC learning has taken place).  So the first 
> observation here is that the OAM is not exercising exactly 
> the same processing path as the traffic.  Further, the 
> indiscriminate broadcasting of BDI to N far-ends wrt to an 
> unknown number of incoming failures is hardly good practice 
> (see section 7.5 in Y.1731).
> 
> However, the key point I am making here is the former one, ie 
> when we are dealing with proper co-cs or co-ps mode p2mp 
> connections we cannot piggyback BDI in CC messages.
> 
> 
> just noted Yaakov also allude to this point in his mail 09 
> July 2008 17:31, viz:
> 
> I am not a great fan of OAM mapping at all, and wouldn't care 
> if the present oam-msg-map draft died a natural death.
> frequently a necessary one.
> transparent client/server layer network relationship).
> 
> 
> reliable...far more so than the intrinsic failure rate of the 
> network it resides in.  So defect detection/handling OAM 
> needs to be as simple/sparse as possible.  Collecting OAM 
> (esp Perf Mon OAM) information also has a real opex cost.  
> bloated/bad OAM (Y.1731 is bloated IMO).  I've just noticed 
> TCM (Tandem Connection Monitoring) has been added to the
> PWE3 charter.  I would strongly advise IETF *not* to go here 
> just because others have included this in their standards.  
> This idea has been around for many years in ITU and there are 
> very good reasons why very little of it is used in practice 
> (I can spell this out if not obvious).
> 
> Regards, Neil
> 
> 
> 
> > FYI...an updated version of the document is also available based on 
> > Subject: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft
> > 
> > minutes of the last meeting do not say that, and in any case we did 
> > not do a list poll.
> >

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 16 Jul 2008 11:57:12 +0200

retry..

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: 14 July 2008 11:02
To: [email-masked]'; [email-masked]'; [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Neil,

> 2	I note that the BDI (or RDI) function has been piggy-backed in CC
> In the case of co-cs or co-ps mode layer networks this only works for 
> symmetrical bidirectional connections, ie p2p constructs only.  It 
> does not work for p2mp connection constructs (as these cannot be
bidirectionally symmetric) and so a CC message and a BDI message need to be
distinct/independent OAM messages here.

You make a mistake here. First you have to specify what a bidirectional p2mp
connection looks like and how the traffic flows, then you can address the CC
and RDI/BDI OAM mechanism.

The second case (p2mp + mp2p) connection can be supported in a transport
tunnel layer. This p2mp/mp2p connection carries transport service layer
unidirectional and bidirectional p2p connections and/or unidirectional p2mp
connections, which have unique label values within the p2mp/mp2p tunnel
connection. Example: MPLS p2mp/mp2p tunnel with bidir p2p PWs and unidir
p2mp PWs, Ethernet asymmetric VLAN without MAC learning.

The first case can be supported in a transport service layer and transport
tunnel layer. 

2) For the first case when there is no traffic from Zi to A, the CC function
checks the A to Zi (i=1, .., n-1) maintenance entities and the signal fail
status at the Zi ends is reported via RDI/BDI function from Zi to A. The CC
fucntion between Zi and A checks if the Zi to A connection is operational
and thus able to carry RDI/BDI from Zi.
There is as such no problem to combine CC and RDI/BDI OAM in a single OAM
message.

For the second case (p2mp/mp2p tunnel connection) CC function checks the A
to Zi Maintenance Entities and the signal fail status at the Zi ends is
reported via RDI/BDI function from Zi to A. The CC fucntion between Zi and A
checks if the Zi to A maintenance entity is operational and carries the
RDI/BDI from Zi. At A, the status of the mp2p unidir 'transport entity' is
computed from the status of the individual p2p maintenance entities; the
result is reported from A to Zi via the RDI/BDI inside the CC from A to Zi.
There is as such no problem to combine CC and RDI/BDI OAM in a single OAM
message.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 09 July 2008 21:18
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Hi Dinesh and Ali,

A few observations on the draft and the subject of OAM in general that you
might like to take into account:

1	Despite what some folks having been trying to do in ITU the OAM
required for each of the 3 network modes (cl-ps, co-ps and co-cs) is not the
same.  For example, AIS is mentioned in the draft.  AIS has its roots in
co-cs mode PDH/TDM networks.  AIS is about alarm suppression (in co mode
clients *above* a server failure) not generating alarms.  It was a direct
consequence of old TTL logic when, on failure, the logic 'floated' to +5V
(ie binary 1).....so a binary all 1s signal was the natural indication of
failure here.  Note in particular it is a passive signal....in the sense
that we don't have to actively create special traffic units to mimic it as
we would in any packet network.  Further, since the co-cs mode is
characterised by a constant bit rate signal AIS is naturally a constant
stream of binary all 1s (when replacing the traffic signal).

AIS is however not a natural signal in packet networks.  And whilst it is
understandable to want to have an AIS/FDI OAM function in co-ps mode layer
networks (on the assumption they have proper single source connections, ie
p2p or p2mp constructs only) it has no meaning in cl-ps mode networks, eg
IP, Ethernet.  And this, of course, is why IEEE saw fit to deprecate AIS in
802.1ag for Ethernet OAM.

My view is that IETF should align its position with that of the IEEE
standards when dealing with Ethernet OAM.

2	I note that the BDI (or RDI) function has been piggy-backed in
CC messages in both Y.1731 and 802.1ag.  In the case of co-cs or co-ps mode
layer networks this only works for symmetrical bidirectional connections, ie
p2p constructs only.  It does not work for p2mp connection constructs (as
these cannot be bidirectionally symmetric) and so a CC message and a BDI
message need to be distinct/independent OAM messages here.  This is
something to bear in mind for GMPLS (controlled co-cs mode layer network
connections), MPLS and PWs (assuming the case of both these supporting
proper single source co-ps connections).

Now of course Ethernet is a cl-ps mode technology so we don't have
connections. However, if we make the OAM CC message a broadcast function
between MEPs then we force a condition of symmetry here and so one can, in
principle, piggyback BDI in CC messages.....the traffic of course can be,
and usually is, unicast (once SA MAC learning has taken place).  So the
first observation here is that the OAM is not exercising exactly the same
processing path as the traffic.  Further, the indiscriminate broadcasting of
BDI to N far-ends wrt to an unknown number of incoming failures is hardly
good practice (see section 7.5 in Y.1731).

However, the key point I am making here is the former one, ie when we are
dealing with proper co-cs or co-ps mode p2mp connections we cannot piggyback
BDI in CC messages.

3	It is a very, very bad idea to have client layer defects
reflected in a server layer network (be this DP/CP/MP).  I just noted Yaakov
also allude to this point in his mail 09 July 2008 17:31, viz:

"However, I would like to reiterate what I said in Philadelphia.
I am not a great fan of OAM mapping at all, and wouldn't care if the present
oam-msg-map draft died a natural death.
Ethernet to Ethernet PW OAM interworking is an evil, but frequently a
necessary one.
Work on it needs to be expedited."

Quite.....need to start getting these things right (here a transparent
client/server layer network relationship).

4	Final, and far more general, point....OAM needs to be uber
reliable...far more so than the intrinsic failure rate of the network it
resides in.  So defect detection/handling OAM needs to be as simple/sparse
as possible.  Collecting OAM (esp Perf Mon OAM) information also has a real
opex cost.  Ops folks will turn-off as much OAM as they can...esp
bloated/bad OAM (Y.1731 is bloated IMO).  I've just noticed TCM (Tandem
Connection Monitoring) has been added to the
PWE3 charter.  I would strongly advise IETF *not* to go here just because
others have included this in their standards.  This idea has been around for
many years in ITU and there are very good reasons why very little of it is
used in practice (I can spell this out if not obvious).

Regards, Neil

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Dinesh Mohan
> Sent: 08 July 2008 16:08
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Stewart Bryant
> Please can we have views on whether to accept as WG draft by COB 15th 
> July.
> 
> Thanks
> 
> Stewart/Danny
> 
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 16 Jul 2008 11:57:12 +0200

retry..

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: 14 July 2008 10:14
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Neil,

AIS/FDI OAM for all technologies is associated with configured
point-to-point, point-to-multipoint, rooted-multipoint and
multipoint-to-multipoint 'transport entities' (i.e.
PDH/SDH/OTN/ATM/MPLS(-TP)connections, Ethernet VLANs (inlcuding a standalone
802.1D network)). AIS will also be associated with the point-to-point and
point-to-multipoint PBB-TE connections.

COCS, COPS and CLPS are three types of forwarding mode within 'transport
entities'. 'Transport entities' itself **connection-oriented**, connection
admission controlled and traffic engineered; they are set up under
management plane control, with or without the help of a control plane.

- COCS is a forwarding mode in a 'transport entity' in which every traffic
unit is treated identically from a forwarding perspective in the switch
functions and link ingress points.
- COPS is a forwarding mode in a 'transport entity'in which every traffic
unit is treated identically from a forwarding perspective in the switch
functions (same as COCS case), but may be treated differently in link
ingress points. In link ingress points the CoS and Discard Eligibility of
the traffic unit determine the forwarding.
- CLPS is a forwarding mode in a 'transport entity' in which traffic units
may be treated differently from a forwarding perspective in switch functions
and link ingress points. In the link ingress points the CoS and Discard
Eligibility of the traffic unit determine its forwarding (same as in COPS
case). In the switch fucntions the value of a label within the traffic unit
(e.g. address label or demultiplexer label) determines the forwarding of a
traffic unit within the 'transport entity'.

CLPS forwarding behaviour within 'transport entities' is specified today for
Ethernet VLANs and IP VPNs. 
The label in the traffic unit that is used to determine which output port or
output ports of the VLAN/VPN 'transport entity' should receive this traffic
unit is the destination address label.

	Note that an 802.1D network is an Ethernet network with a single
VLAN (single 'transport entity'). 
	The 'internet' is an IP network with a single (public) 'IP VPN'
(signle 'transport entity').

In **theory** it is possible to specify CLPS forwarding also in e.g.
point-to-multipoint MPLS tunnels when those tunnels carry
point-to-multipoint MPLS PWs (with each PW carrying e.g. a TV channel).
Forwarding of a traffic unit within a MPLS tunnel connection in a MPLS
tunnel switch will - in a CLPS mode - depend on the value of the PW label
inside the traffic unit. For this purpose PW labels will be registered per
MPLS tunnel output port, and if a PW label value X is not assocaited with a
tunnel output port Y, then the MPLS tunnel traffic unit will not be
forwarded via this output port Y.

OAM mechanisms are specified to monitor these **connection-oriented**
'transport entities'. 
OAM mechanisms are not specified to monitor the individual traffic units or
streams of traffic units that are transported between ports of 'transport
entities'.

AIS/FDI, LCK, OCI/UNEQ are OAM maintenance signals that are generated within
the scope of the **connection-oriented** 'transport entity', including the
Ethernet VLAN 'transport entity'. That is why Ethernet AIS is specified in
Y.1731, G.8021 and G.8051. Without this Ethernet AIS OAM you will get alarm
storms in Ethernet VLAN and VPLS transport networks.

You need the AIS/FDI based alarm suppression mechanism as soon as you deploy
a 'transport entity' continuity check mechanism and you can not guarantee
that a broken 'transport entity' has its connectivity restored within 2
seconds. As PBB-TE tunnel connections are set up under management control,
PBB-TE AIS will be necessary to prevent PBB-TE tunnel Loss of Continuity
alarm storms after a cable with 96 fibers, each carrying e.g. 80 40G
wavelengths is broken.

Note that a Server MEP has nothing to do with TCM. A Server MEP is a MEP in
the server layer. Example of ETH Server MEP function: SDH VC-n termination
plus Sn/ETH adaptation function.

---

Every layer has three types of Maintenance Entity Groups (MEG) within a
'transport entity':
1) Network Connection (NC) MEG level
2) Tandem Connection (TC) MEG level
3) Link Connection (LC) MEG level.

The NC-MEG level is always present in a layer network supporting OAM. It is
however an operator's choice to deploy the available OAM at this NC-MEG
level.

TC-MEG and LC-MEG level presence depend of the layer network's role
(transport service layer, transport tunnel layer, transport link layer),
single/multi-owner status of the 'transport entity' and survivability
(protection) requirements.

A) Transport Link (or Section) layer requires typically support of the
NC-MEG level only; i.e. case of I-NNI and E-NNI. 
Only when this link/section layer signal is treated as a port-based service
TC-/LC-MEG levels will become important; i.e. case of UNI.

B) Transport Tunnel (or Path) layer requires typically support of the NC-MEG
level only; i.e. case of I-NNI and E-NNI.
When this tunnel/path layer signal is treated as an individual or bundled
service entity, then TC-/LC-MEG levels will become important; i.e. case of
UNI and carrier-carrier.
Tunnel protection switching is assumed to be performed between PE nodes
using the NC-MEG level MEP functions to monitor for SF/SD status.

C) Transport service (or Channel) layer requires support for the NC-MEG
level and possibly for TC-MEG and LC-MEG levels as well.
When the service/channel layer 'transport entity' starts/ends inside the
transport network (at UNI-N ports) of a single network operator and if such
'transport entity' is not protected, then the NC-MEG will be the only active
MEG level. 
When protection of a 'transport entity' segment is required, a TC-MEG level
is necessary to monitor the segment.
When two or more network operators provide the 'transport entity', each
operator want to be able to monitor the status/performance of the 'transport
entity' segment in its network; this requires the presence of a TC-MEG
level.
When the 'transport entity' starts/ends in the customer domain, the NC-MEG
level is owned by the customer and the transport network must deploy a
TC-MEG level to monitor the status/performance provided by the transport
network between the UNI-N ports. For this case, the LC-MEG level may be used
to monitor the status/performance of the 'transport entity' segment on each
UNI (CE to T-PE) and E-NNI.

When the PBB-TE tunnel layer is a tunnel/path layer operated within the
administrative domain of a single network operator you will need only the
NC-MEG level. 
As soon as PBB-TE tunnel connections may start/end in the customer domains
or in two network operator domains, PBB-TE tunnel layer will need TC-MEG and
LC-MEG levels.

Regards,
Maarten

-----Original Message-----

> surely still a requirement for a triggered forward error indication of 
NH=> Yes, that is true.  However, it's not as obvious a requirement as you
might think.  FDI requires a persistent binding of a client and server layer
network, ie the sever, on failure, needs to be sure who its clients are in
order to inject FDI into them....it's not much good if those clients change.
This long-lasting client/server permanence has been a traditional truth in
nested PDH/SDH co-cs mode transport layer networks...which is of course
where the notion of AIS comes from as I explained.  But what if the clients
can change more dynamically?  Start by envisioning co-cs or co-ps mode SVC
clients (eg co-cs PSTN) which have shrinking holding times......in the limit
this become a single message of a cl-ps mode client layer network.  So if we
imagine a link connection in such a client layer network (ie a single hop
between 2 adjacent client layer nodes which is provided by a network
connection in some lower layer server network) it becomes quite clear that
we cannot assign any permanence between a specific client communications
instance and their use (or not) of that link (=server network connection).
Hopefully you can see that.  And this is why it makes no sense whatsoever to
carry over the idea of AIS/FDI into cl-ps mode layer networks and explains
why IEEE had the good sense to take AIS out of 802.1ag.

We discussed the issue of FDI within BT when considering the OAM we would
want for PBB-TE (co-ps mode based on using the original cl-ps Ethernet
traffic unit), and on balance we considered it was not a good idea.
However, the CV and BDI OAM functions are essential....but they should NOT
be piggybacked in order that we can properly address the p2mp connection
case.

But as I also noted in my mail, a key requirement on OAM (at least that used
for defect detection) is that it is super reliable, and that tends to mean
as sparse as possible of function with minimal configuration.
Anything that requires lots of config (and the TCM stuff factors heavily
here - see later comment) is really not a requirement.
> cl-ps, Ethernet will be extensively used in a p2p manner, especially 
NH=> Please remember that CV and FDI are very different.  CV checks THIS
layer network, FDI is an indication of failure (possibly from a CV flow
detected defect) in a LOWER layer network.  I've seen folks try and 'do
away' with CV and just use FDI...it's a mistake.....as to get FDI SOME layer
network has to be able to detect it's failures, and it won't always be the
section layer, ie very bottom of stack, that can do this.
No CV means you are blind to defects in your layer network, you only see
server layer defects IFF they generate a FDI into your layer network across
the adaptation function...and as explained above, FDI/AIS is not such a
great idea as folks might think.
> 
> Maybe the problem stems from the fact that SPs are often trying to use 
> Ethernet, that is inherently connectionless, in a connection oriented 
> manner!
NH=> Well yes....but the mere fact that special topology consideration
exists (ie the p2p degenerate network case you mentioned above) is not the
general network case.  
> Yes, seems to be the root of a lot of issues we are running into!
NH=> It is rather important/fundamental....but it is violated all over the
place.  I'll say no more on the matter here.

> "NOTE - A Server MEP needs to support ETH-AIS function, as described 
NH=> This is all about TCM.  One might like to observe that in any general
layer network only the access points are fixed....intermediate points can
change, and indeed MUST change if we want to have resiliency.
(You may be struck here by the similarities to the point I made earlier
regarding FDI and how one can't assume a permanence between a client
communications instance and the links (=server layer connections) it is
using at any epoch).  Now try and get your head around how you would manage
the config of such (moveable) intermediate points, especially if you were
trying to get accurate perf mon (PM) data across failures and restorations.
TCM sounds good on paper, but show me the management solutions for PM across
dynamic changes of routing.  Hint=> I've looked quite closely at doing this
at end points that are time invariant/fixed in the past and this is not a
simple problem even here (eg pkts in-flight, clock differences) now
extrapolate that problem to a raft of nested TCM levels that are not
invariant/fixed....let me know when you have an answer for PM in TCM across
failures/restorations ;-)

Regards, Neil

> > AIS is about alarm suppression (in co mode clients *above* a server
> > failure) not generating alarms.  It was a direct consequence of old 
> > is understandable to want to have an AIS/FDI OAM function in co-ps 
> > cl-ps mode networks, eg IP, Ethernet.  And this, of course, is why 
> > This is something to bear in mind for GMPLS (controlled co-cs mode 
> > layer network connections), MPLS and PWs (assuming the case of both 
> > of course can be, and usually is, unicast (once SA MAC learning has 
> > taken place).  So the first observation here is that the OAM is not 
> > This idea has been around for many years in ITU and there are very 
> > good reasons why very little of it is used in practice (I can spell 
> e-mail security system - powered by MessageLabs. For more information 
> The information contained in this e-mail is confidential and may also 
> recipient(s) named above. If you are not named above as a recipient, 
> information contained in this email. If you have received this e-mail 
> in error, please notify the sender (whose contact details are above) 
> immediately by reply e-mail and delete the message and any attachments