Subject: RE: FR OAM (was RE: PWE3 Arch/CW & RTP Order (Rough Conses us?))

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 15 May 2003 23:55:00 -0400

Ali's email is a good step forward to address the proper layering with respect to OAM. However, I think the biggest controvery is around MPLS OAM versus PW OAM. Ali addresses that specific issue only in one point, where he compares an LSP with an ATM VP and a PW with an ATM VC and argues that therefore both MPLS OAM and PW OAM need to exist. The rest of his email argues that client-layer OAM alone is not enough. That is correct, but it leaves open the question whether server-layer OAM should be MPLS OAM, PW OAM or both.

Neil responded to Ali's VP/VC argument that it doesn't apply because a PW is not a networked entity and begins and ends at the same points as the LSP over which it is carried. That is  indeed the case, although there are indications that people see exceptions. More about that at the end of this email.

So assuming that a PW is not networked, what is the right solution: MPLS OAM, PW OAM or both?

I think it depends on the way the core MPLS network is set up. If the core network is strictly point-to-point (i.e. Neil's ideal co pkt-sw network), I believe MPLS OAM is sufficient. E.g. it is sufficient to do connectivity verification for the LSP. If the LSP is down, obviously all PWs running over that LSP are down and the related NSP entities can be notified of the defect.

Tom argued in earlier emails that LSP Ping is not sufficient and that you need VCCV-Ping for accurate OAM. In the absence of ECMP, I don't agree. Ultimately, one needs to know whether the NSP entities at either side of the PW are bound correctly. However, that can only be verified with a continuity verification in the native service layer (i.e. the client layer). VCCV-Ping might come "closer" than LSP Ping, but in the end it only proves connectivity within the server layer. 

In a network with ECMP, it is almost impossible to determine with full certainty connectivity of an LSP. In that case, VCCV-Ping is required. Maybe this is sophistry, but in my mind the use of VCCV-Ping doesn't turn the PW layer into some nebulous in-between layer. I would argue that it is a sensible way to do MPLS OAM in a network with ECMP.

Currently, the vccv-draft specifies the tools (i.e. VCCV-Ping), but doesn't specify in great detail how they should be used. I propose that the following additions/modifications be made to the draft.

1) In core networks without ECMP, LSP Ping should be used to verify server-layer connectivity. In core networks with ECMP, VCCV-Ping should be used. Which of the two will be used is provisionable by the service provider. To the client layer it will be invisible which of the two is being used. In both cases, the same fault indications will be given (albeit that in the case of LSP-Ping all NSP entities bound to an LSP will be triggered, whereas in the case of VCCV-Ping only the NSP entity bound to that specific PW will be triggered)

2) PEs must support both LSP-Ping and VCCV-Ping. The negotiation process specified in the vccv-draft should be modified to include LSP Ping as an option for OAM. 

3) LSP-Ping or VCCV-Ping requests will be sent by both PEs at regular intervals. A PE will interpret failure to receive a reply to its own ping and/or failure to receive  ping requests from the far side as an error and it will give the appropriate defect indication  to the client layer. The timer interval will be configurable by the service provider and will likely differ depending on the client layer.

4) Practically all client services are bi-directional, whereas LSPs are uni-directional. For the purposes of PW OAM, associated up and downstream LSPs must be seen as a pair. The reply to an upstream ping request will be returned over the associated downstream LSP or PW.

5)A comment on draft-nadeau-pwe3-oam-msg-map-00:
The draft proposes in several instances to tear down the PW in response to error indications in the client layer (e.g. ATM AIS). I believe that that is fundamentally wrong. The ATM AIS and RDI messages are suffient to inform other ATM nodes about failures. The client layer should take care of itself. The PW should stay up. 

Networked PWs
--------------
As stated at the beginning of this email, a PW is not a networked entity. However, there are indications that people see exceptions to that. Eric Rosen mentioned it in several of his emails and the recent discussion on TTL values (concluding that TTL should not always be set to 2) is another example.

If PW becomes indeed a switched entity, we should bite the bullet and turn it into a full-blown MPLS layer. However, because of PW requirements, it would be  strictly point-to-point and it could rightfully be called the "PW Layer". The OAM principles stated above would still apply.

A final note: the fact that this email proposes a solution based on LSP Ping and VCCV Ping does not mean that I don't see the value of Y.1711. On the contrary. However, I think that the use of VCCV Ping over point-to-point paths (which PWs are, after all) avoids many of the problems identified in draft-allan-mpls-oam-frmwk-04. By being specific, I hope that we can get beyond the religious debates. I think there is an urgent need for a good OAM solution and I hope this email will help us get there.

Peter

> -----Original Message-----
> From: Ali Sajassi [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 4:10 AM
> To: Shahram Davari; [email-masked]'; 'Mustapha Aissaoui'; 'David
> Allan'
> Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson';
> [email-masked]
> Subject: RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough Consesus?)
> 
> 
> Shahram, Neil:
> 
> By going through this email thread regarding OAM for PW, I 
> realized that 
> there are several areas of contentions that need further 
> exploration/clarification. So lets go over them in a bit more 
> details and 
> see where we stand.
> 
> 
> We all advocate proper layering for PW OAM but we all have 
> different views 
> of what the proper layering should be. One view which I am 
> hearing is that 
> there should be a single OAM mechanism for the whole MPLS 
> (both LSP tunnel 
> and PW) and some people think that PW is an artificial layer 
> that shouldn't 
> have its own OAM. Another view is that PW OAM can be handled 
> by the service 
> layer (e.g., either segment ATM or segment Ethernet or 
> segment Foo) and 
> thus there is no need for the PW to have its own OAM. Lets 
> look at them a 
> bit more closely.
> 
> First, I think each layer and sub-layer of transport need 
> their own OAM 
> mechanism since they operate independently and the each have 
> different 
> termination points (e.g., I.610 - OAM principles for B-ISDN). 
> So if I have 
> IP over ATM over SONET, there needs to be a OAM for each of 
> these layers 
> and one layer's OAM should not be used to replace another.
> 
> Second if there are sub-layers within a transport layer, then these 
> sub-layers also need their own OAM because again they can 
> have different 
> termination/disposition points. One example that we are all 
> familiar with 
> is ATM where VC and VP have their own end-to-end and segment 
> OAM and one 
> sub-layer OAM doesn't replace the other. So one can consider 
> an MPLS PW 
> analogous to an ATM VC and an MPLS LSP tunnel analogous to an 
> ATM VP and 
> thus similar to ATM each have their own OAM mechanism because 
> each of these 
> transport sub-layers have different termination/disposition points.
> 
> Third, using a service layer OAM to replace/compensate for a 
> transport 
> sub-layer OAM is not the right approach for several reasons:
> A) In ATM network, when you transport FR between two end 
> points over an 
> ATM, you don't use FR OAM in the ATM network to 
> detect/isolate fault but 
> instead you relay on  ATM OAM and as the matter of fact FR PVC status 
> relies on the ATM PVC (FRF.5).
> B) Service layer OAM doesn't give you the right info. For 
> example in a VPLS 
> service, Ethernet OAM ping can span several PWs. Also again 
> for proper 
> layering, Ethernet OAM should be independent from MPLS layer OAM.
> C) There are cases that the service layer doesn't have an OAM 
> mechanism 
> associated with it - e.g., in case of a transport of routed 
> packets over a 
> PW without L2 layer (refer to draft-sajassi-l2vpn-interworking for 
> different interworking scenarios).
> 
> 
> There are other reasons of why it is better for PW to have 
> their own OAM 
> mechanism such as the use of common mechanism for 
> interworking between 
> disparate interfaces but there is no need to get into the 
> details right now 
> since the above reasons should be sufficient.
> 
> So at the end, I think we need to have a mechanism for PW OAM 
> and VCCV as 
> Tom has described it provides such mechanism.
> 
> -Ali
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Fri, 16 May 2003 12:33:48 +0100

Peter....please see below.  regards, Neil

Busschbach, Peter B (Peter) wrote 16 May 2003 04:55

> Ali's email is a good step forward to address the proper 
> layering with respect to OAM. However, I think the biggest 
> controvery is around MPLS OAM versus PW OAM. Ali addresses 
> that specific issue only in one point, where he compares an 
> LSP with an ATM VP and a PW with an ATM VC and argues that 
> therefore both MPLS OAM and PW OAM need to exist.
NH=> This is not a valid analogy for the reasons I gave previously.

> The rest of 
> his email argues that client-layer OAM alone is not enough.
NH=> Yes indeed...as will become crystal clear later.
 
> That is correct, but it leaves open the question whether 
> server-layer OAM should be MPLS OAM, PW OAM or both.
> 
> Neil responded to Ali's VP/VC argument that it doesn't apply 
> because a PW is not a networked entity and begins and ends at 
> the same points as the LSP over which it is carried. That is  
> indeed the case, although there are indications that people 
> see exceptions. More about that at the end of this email.
> 
> I think it depends on the way the core MPLS network is set 
> up. If the core network is strictly point-to-point (i.e. 
> Neil's ideal co pkt-sw network),
NH=> This is something else entirely Peter (albeit yet another consequence
of mp2p).  Under *ALL* conditions of running mp2p when carrying XoverMPLS
one must provide a p2p LSP *client* layer to the underlying mp2p LSP server
layer to recover from the effects of merging. This is a forced requirement
in order to be able to identify the source.  It has nothing directly to do
the additional PW creations.  These exists to fix *other* problems caused by
mp2p....such as:
-	the fact that misordering is allowed......this really should not be
the case;
-	the fact that ECMP algorithms are being run over multiple layer
networks (in a single layer network load-sharing is OK, but not over
multiple layers) which, because of the 1st nibble hack on the payload leads
to the other kludge on the client layer (X) PID...and BTW one should not be
using a *client* layer PID field for *same/lower* layer OAM
identification....further evidence of bad architecture;
-	the fact that some believe a bit of BW squeezing by compressing the
client (X) is a worthwhile thing.

Further, it is also related to the desire to force X/MPLS solutions to look
like X/IP solutions.....this may seem laudable at 1st glance, but the
behaviour of these 2 server modes ought to be different (else why have
them?) and trying to force alignment is not really a 'good thing' IMO.

-	I believe MPLS OAM is 
> sufficient. E.g. it is sufficient to do connectivity 
> verification for the LSP. If the LSP is down, obviously all 
> PWs running over that LSP are down and the related NSP 
> entities can be notified of the defect.
NH=> But can't you see that since one is *forced* to always run p2p LSPs
above any mp2p construct for X/MPLS then the PW OAM stuff is a
non-issue.....you simple do the proper OAM on these p2p constructs!
> 
> Tom argued in earlier emails that LSP Ping is not sufficient
NH=> Agreed.  LSP-Ping is a heavyweight diagnostics tool....and this is
quite different to a lightweight detection/handling function that should
(nay must) be an intrinsic design component the data-plane.  I refer those
who wish to do this right to use Y.1711, and I would rather not see any
further misinformation being stated about the Y.1711.

> and that you need VCCV-Ping for accurate OAM.
NH=> I believe VCCV is required to cater for limitations of LSP-Ping because
of the way (one at least) vendor's ECMP algorithm works.....that is LSP-Ping
uses an IP client payload and so requires a v4 exp null label,  but X/MPLS
client uses normal forwarding label and thus may not hash to the same
forwarding path.  However, I digress......

The simple fact is this:  mp2p merging in a co pkt-sw forwarding mode is a
topologically bizarre thing to do, and it leads to all sorts of
problems...fault-management is but one of these.  If one wants any-any
connectivity use IP for goodness sake.  However, the most obvious
topological problem/consequence of mp2p is that it forces an extra client
level of p2p LSP to allow demerging (ie recover the source identification).
So, if we get the fault-management right on these p2p LSPs then we are
done....PW OAM, and the problems this additionally creates (see next para),
is simply not required for *OAM interworking* with the real client X.  I am
amazed this is not obvious to everyone....it is so simple.

However, just to really ram home this point.....consider the case of
FR<=>MPLS<=>ATM interworking.  If FR/MPLS uses one type of PW adapatation
and ATM/MPLS uses another type of PW adaptation (as indeed is the case) then
there is a BIG problem.....because we also now have to interwork the
different PW types.  What nonsense!  So FR<=>MPLS<=>ATM interworking really
brings home the point that we *must* have clear native service-interworking
between FR, MPLS and ATM and that PWs make very little sense here.....esp PW
OAM.  The PW notion can only be tolerated (note the word 'tolerated') in the
simpler network-interworking case of X/MPLS as a client/server pair.....but
network-interworking is not the only required case, we operators want
service-interworking.....and we want to see it done properly, esp with ATM.

In fact the need to recognise the above point was even brought out in a
Cisco paper to a SG13/Q3 mtg I have been attending this week in Nice.  Once
the consequences were understood by all the engineers attendng this mtg
there was unaminmous agreement that this needs fixing properly.....the logic
is simply irrefutable.
<snipped>

> 
> 1) In core networks without ECMP, LSP Ping should be used to 
> verify server-layer connectivity. In core networks with ECMP, 
> VCCV-Ping should be used. Which of the two will be used is 
> provisionable by the service provider. To the client layer it 
> will be invisible which of the two is being used. In both 
> cases, the same fault indications will be given (albeit that 
> in the case of LSP-Ping all NSP entities bound to an LSP will 
> be triggered, whereas in the case of VCCV-Ping only the NSP 
> entity bound to that specific PW will be triggered).
NH=> Please distinguish *detection/handling* and *diagnostics*
functions.....these are not at all the same.  LSP-Ping is a useful
diagnostic tool that operators who have deployed mp2p LSPs will probably
need.  But remember what I said above, ie mp2p forces p2p LSPs above these.
So the right answer is to run Y.1711 on the p2p entities and if/when these
show a problem *and* L1 shows 'clear' then wheel-out LSP-Ping.  The wrong
answer is to invent unnecessary PW OAM and/or try and run LSP-Ping in some
detection/handling mode that (i) it was not designed for and (ii) is really
not capable of delivering against anyway.
<snipped>

> The draft proposes in several instances to tear down the PW 
> in response to error indications in the client layer (e.g. 
> ATM AIS). I believe that that is fundamentally wrong. 
NH=> Too right it is!  You simply don't start tearing down connections like
this.

> The ATM 
> AIS and RDI messages are suffient to inform other ATM nodes 
> about failures. The client layer should take care of itself.
NH=> Quite so.
 
> The PW should stay up. 
NH=> No, the PW should not exist....at least with the direction its going
now.  The only thing required between the true client X and MPLS is simple
adapatation.  It is only X and MPLS that require functional interworking,
like OAM.
> 
> 
> Networked PWs
> --------------
> As stated at the beginning of this email, a PW is not a 
> networked entity. However, there are indications that people 
> see exceptions to that. Eric Rosen mentioned it in several of 
> his emails and the recent discussion on TTL values 
> (concluding that TTL should not always be set to 2) is 
> another example.
NH=> Huh?  Eric was talking about the TTL of the p2p LSP......not the
artificial PW above this. PWs are not part of the MPLS layer network and
they don't have a TTL field.
> 
> If PW becomes indeed a switched entity, we should bite the 
> bullet and turn it into a full-blown MPLS layer.
NH=> It would not be an MPLS layer network at all....but some new layer
network.  However, I am not at all clear you understand this given you
immediately prior point.  But what a further serious mistake this would be
if one did this.  Operators require the removal of layer networks to reduce
opex/capex....not the adding of unnecessary layers (and the PW case this is
hardly a proper layer network anyway, its just a set of 1/2-baked fixes to
problems that exist elsewhere....most of which are in fact consequences of
mp2p).
<snipped to end>

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 16 May 2003 14:43:17 -0400

Neil,

You keep stressing the point that constructs like mp2p and ecmp create problems and should not have been adopted in MPLS. I agree, but for now I think we should accept these as a given. I would be interested to see if we can define acceptable OAM on the foundation that we have today. You seem to propose a more rigorous approach: get rid of the rotten foundation and build the right framework from the ground up.

Further comments in-line

Peter

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 16, 2003 7:34 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: FR OAM (was RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough
> Conses us?))
> 
> 
> > layering with respect to OAM.

[snipped]

> client (X) is a worthwhile thing.

I interpret your comments as a critique of bad design decisions in the past. I believe you are right, but given that ECMP exists and packet-ordering is not guaranteed, I think we need to find a solution that works around those problems. 

> NH=> Further, it is also related to the desire to force X/MPLS 
> solutions to look

Perhaps we are in violent agreement :-) That is exactly my point: if the underlying MPLS layer has properties that force you to create p2p PWs, then you should do OAM on those PWs.

Maybe I have interpreted earlier email exchanges incorrectly. I thought the notion of PW OAM was rejected by some as wrong and unnecessary. Anyway, I would like to see if we can get agreement on what it means to do proper OAM for these p2p constructs.

> further misinformation being stated about the Y.1711.

I mentioned LSP-Ping because in the IETF it seems to have a wider acceptance than Y.1711. I agree that it is primarily a diagnostics tool, but if PEs would use LSP-Ping periodically, it could serve for connectivity verification.

I think the fundamental issue is that for proper OAM you at least need a periodic connectivity verification. If you can do that with a Ping message, good. If Ping is too heavyweight, use something else.

I would be interested to hear from the proponents of Ping how they think it should be used.  

[snipped]

> NH=> So, if we get the fault-management right on these p2p LSPs then we are

I am not sure what point you are making. In the case of Service Interworking you terminate one layer and carry the payload over another layer. So the fact that PW encapsulation of FR differs from PW encapsulation of ATM is irrelevant, because in the case of service interworking you wouldn't carry FR or ATM over MPLS, but the respective payloads.

You know that, so obviously that is not the point you are making.

I think you are saying that:

1) PW is designed for network interworking, i.e. the emulation of specific protocols over MPLS. Each protocol has its own adaptation function and therefore PW is not the right tool for Service Interworking. (Nobody said it was, so I don't think there is disagreement about that)

2) Service Interworking, especially between ATM and MPLS, requires proper OAM in the MPLS layer

3) Once you define a solution for ATM - MPLS Service Interworking (which according to point 1 does not include PW), then you have basically proven that you don't need PW in the first place (or am I reading too much into your statements?)

Anyway, I think that with respect to OAM you end up in the same situation: if you set up point-to-point LSPs for service interworking, then you can do OAM over those connections. However, if you would try to do service interworking over a general MPLS core with MP2P LSPs and ECMP, then you will have a problem defining proper OAM and you will be forced to use an additional PW-like p2p construct for OAM purposes.

That brings us back to the point I made in the beginning of this email: do you rebuild the foundation or do you build on the foundation that you have (i.e. MPLS with ECMP and MP2P)
  
> NH=> In fact the need to recognise the above point was even 
> brought out in a

So we agree that in the given situation the right answer is to run proper OAM over the p2p constructs introduced by PW. The question then is: what is proper OAM. 

I believe that proper OAM at a minimum requires a periodic verification of connectivity and proper binding between sink and source. Is there consensus in the WG that such a periodic verification is required? If so, the question is what messages to use. Is there any chance that we will get consensus around that without getting into another acrimonious debate around Y.1711 versus LSP-Ping?

> NH=> Too right it is!  You simply don't start tearing down 
[snipped]
> they don't have a TTL field.

There was a recent email exchange with subject line: "[PWE3] TTL value of VC Label?". Unless I am completely mistaken, this thread discussed the TTL value in the PW label and decided that one could not set it to 2 in all cases.

> immediately prior point. 

PW Labels are MPLS labels. When you use MPLS labels; when you assume that there are intermediate aggregation points and TTL values > 2; when you use LDP for PW label distribution; and when you consider BGP for autodiscovery; how far away are you from creating a full-blown MPLS layer? 

> But what a further serious mistake 
> this would be

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Sat, 17 May 2003 14:20:04 -0400

> From: Mark Seery [mailto:[email-masked]]
> Sent: Monday, May 12, 2003 10:49 PM
> Subject: FR OAM (was RE: [PWE3] PWE3 Arch/CW & RTP Order (Rough
> Consesus?))

[snipped]

> 
> This all begs the question that if OAM is so important, then 
> how did Frame
> Relay become so successful without it? Well ultimately that 
> is a question
> for a service provider to answer, I would just observe that a 
> number of SPs
> view FR as a best effort service. Undoubtedly QoS is part of that
> assessment, but there are probably other considerations as 
> well; and of
> course some SPs view a strong OAM capability as being key to 
> being offer
> strong QoS.
> 

There is another aspect to this. In many (most?) cases, Frame Relay services are carried across an ATM backbone. Therefore, service providers can rely on ATM's OAM functionality for fault sectionalization etc. In fact, I think ATM's OAM features were a major driver in the decision to carry FR over an ATM backbone.

Therefore, in answer to Mark's question below, I think the PWE's OAM needs to resemble ATM's OAM in order to make PWE a suitable vehicle for carrying Frame Relay services.

Peter

> I suggest SPs define what OAM requirements they want/need for 
> PWE3 and the
> group goes from there. Arguing about FR OAM is not likely to prove
> constructive or instructive given that it has been 
> none-existent, for all
> intents and purposes, for most of FR's history.
> 
> Perhaps one thing for the group to consider is whether 
> PWE-based services
> are intended to be viewed as having similar quality to Frame Relay, or
> similar quality to ATM services. Frame Relay has essentially, in the
> enterprise data services context, essentially been a service 
> interface, and
> not a service transport - something else to bare in mind.
> 
> Mark
> 
> 
>

---

From: Mark Seery <[email-masked]>
Date: Sat, 17 May 2003 11:41:01 -0700 (PDT)

Thanks for the response Peter,

Comments below,
Mark

--- "Busschbach, Peter B (Peter)"
<[email-masked]> wrote:

[snipped]
> There is another aspect to this. In many (most?)
> cases, Frame Relay services are carried across an
> ATM backbone. Therefore, service providers can rely
> on ATM's OAM functionality for fault
> sectionalization etc.

Agreed, on that part of the network. On the tail
circults, and indeed all parts of the network, TDM OAM
can be used, with the only limitation that it doesn't
understand the logical topology of the client layers.

> In fact, I think ATM's OAM
> features were a major driver in the decision to
> carry FR over an ATM backbone.

If that is true, and I don't know one way or the other
- I assumed that pipe size was a component, then that
would be a very telling data point in terms of what
OAM capabilities are desired by providers.

Also, an alternative interpretation of this logic
might be that a (robust) PSN (e.g. MPLS) OAM is
sufficient to carry clients (i.e. FR) and their
adaptation glue (PWE), and that it is up to the
clients to determine what OAM they need, which may be
similar or different; of course for true plug-and-play
architectures, I guess all OAMs must be robust so that
assumptions about underlying layers can be ignored.

> Therefore, in answer to Mark's question below, I
> think the PWE's OAM needs to resemble ATM's OAM in
> order to make PWE a suitable vehicle for carrying
> Frame Relay services.

Which still leaves the question is PWE adaptation glue
or a layer. If it is a layer, then I am a little
confused about why MPLS and L2TP were created, but
that's probably a different thread ;-)

---

From: [email-masked]
Date: Mon, 19 May 2003 09:01:14 +0100

Hi Peter,

Busschbach, Peter B (Peter) wrote to Mark Seery 17 May 2003 19:20
> There is another aspect to this. In many (most?) cases, Frame 
> Relay services are carried across an ATM backbone. Therefore, 
> service providers can rely on ATM's OAM functionality for 
> fault sectionalization etc. In fact, I think ATM's OAM 
> features were a major driver in the decision to carry FR over 
> an ATM backbone.
NH=> You may also like to observe that FR/ATM *service* interworking is
key....why?  For the simple reason that operators don't want to run a
stovepipe 'technology per service' regime and customers don't want to do a
fork-lift change-out of CPE.....both of these communities have a need to
reduce opex/capex and protect investments.

Exactly the same issues hold for MPLS.....that is, when technologies belong
to the *same* networking mode (in this case co pkt-sw) one should be
striving for functional convergence across those technologies (and this
implies a need for service interworking). {Note - This is *not* the same as
convergence across all modes (cnls, co pkt-sw and co cct-sw) as that simply
does not work technically/commercially.} 

So, for those operators who have large FR/ATM networks deployed which are
earning real revenue and who have MPLS on the road-map as the core co pkt-sw
technology, then I would suggest they should be thinking very carefully
about this and looking at what is going on in PWE3 and what it means for
their networks....ditto the key suppliers to those operators who also show
MPLS as the core technology. 

One factor that becomes obvious when *service* interworking is considered is
that the PW entity as currently defined is not required.....its just
something else to manage/interwork and thus represents an  unecessary
cost/problem for an operator.  We need simple clinet->server adaptation and
simple OAM applied to the p2p LSPs that run between PE devices as defined in
Y.1711 (and we don't want PW OAM that resides *above* this).  Any mp2p LSPs
underneath this can use LSP-Ping.  
> 
> Therefore, in answer to Mark's question below, I think the 
> PWE's OAM needs to resemble ATM's OAM in order to make PWE a 
> suitable vehicle for carrying Frame Relay services.
NH=> Peter, it is not the *PW's* OAM that is required its the LSP's OAM that
is required, ie the OAM is relevant to the networked entities and not the
adapatation entities (ie the client->server mapping).  One final point that
some people may not be aware of:  When I wrote the orginal drafts of Y.1710
(requirements) and Y.1711 (mechanisms) I did so with the 3 mode functional
convergence vision in mind.  That is, the functional behaviour of Y.1711 can
be applied to *any* co pkt-sw mode technology.  Further, it is about as
lightweight yet powerful as you can get....it only defines 3 basic pkts for
defect detection/handling:  CV pkts to ensure correct connectivity and
FDI/BDI pkts (forward/backward defect indicators) to indicate failures (inc
'where' and 'which').  All the defects are fully specified (ie entry/exit
criteria) together with their required consequent actions.  Further,
availabiilty states (both directions) are also defined (and you need this if
you then want any sort of sensible measurement basis for up-state QoS
metrics/objectives).  Unless one has considered/specified all these aspects
then one does not have a proper OAM solution.

regards, Neil
<snipped to end>