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

["Busschbach, Peter B (Peter)" <[e-mail]>]

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:[e-mail]]
> Sent: Monday, May 12, 2003 4:10 AM
> To: Shahram Davari; '[e-mail]'; 'Mustapha Aissaoui'; 'David
> Allan'
> Cc: 'Sasha Vainshtein'; 'George Swallow'; 'Danny McPherson';
> [e-mail]
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
>