Subject: RE: OAM functionality (Was: RE: can egress know the ingressof a packet?)

From: [email-masked]
Date: Thu, 8 Jun 2000 12:52:35 +0100

Peter, good observations from someone who designs/runs IP networks and hence
has operational experience of these matters.....few additional remarks
below:

Regards, Neil

> Problems with Ping and Traceroute Alone as OAM Tools For MPLS
> -------------------------------------------------------------
> 
> 1 - Failure of LSP does not imply ping will fail.
> 	An LSP X is established between PE A and PE D. To test continuity
> 	a ping process runs on A pinging D. If LSP X fails the ping may
> 	still be successful because D may still be reachable via per-hop
> 	routing. Example fault is that the LSR process on LSR C fails but
> its
> 	destination based per-hop routing process continues.
	[Harrison,N,Neil,INC1 X]  One should not be using OAM tools in a
client layer to detect faults in a server layer....this is the wrong layer
and not good architectural practice.  It gets worse if one then tries to use
OAM mechanisms in one layer to effect actions in another layer (either
direction up/down stack).  Each layer needs its own OAM tools for the
specific defects that the layer could produce......and these also need
splitting between user-plane and control-plane since (i) one cannot always
assume these will be congruent, (ii) go through same functional processing
or (iii) have the same failure mechanisms or fault behaviour.

> 2 - Complexity of using ping as a proactive continuity check.
> 	It is essential to a network operator that failures in any LSP are
> 	raised as alarms to its NMS ASAP. To this end we have alarms from
> 	SDH, ATM, FR, PPP, HDLC and L2TP that causes routers to send traps 
> 	to NMS.  We need a similar function from MPLS. Even if pings fail
> 	when LSPs fail the complexity of running ping processes on all
> routers
> 	to test all LSPs is not acceptable and not current practice for
> other
> 	network technologies.
> 	Ping is ideally suited as a fault finding tool but lacks the 
> 	integration with the network protocols to be an effective pro-active
> 	monitoring tool within a complex network.
	[Harrison,N,Neil,INC1 X]  Ping will not detect/diagnose (at the MPLS
layer) where various forms of misbranching/mismerging defects are occurring.
Further, one should be very careful with OAM tools that assume some
reliability from the network for their sucessful operation......under fault
conditions the network is, by definition, not reliable, eg any trace-route
type of function requiring a loopback-like response must assume misbranching
failures are bi-directionally symmetric.  One cannot guarantee networks will
know they have to fail in such a well behaved manner.

	But Connectivity Verification and Route-Tracing are not the total
picture anyway.......we need distributed local consequent actions on
detection of failures.  For example, to make sure we don't get alarm storms
and that prot-sw is correctly targetted.  This is particularly important for
nested LSP scenarios.

> 	- Especially in an IP VPN Environment.
> 	In an IP VPN environment only CEs within a VPN can ping other CEs
> 	within the same VPN. That is a ping can not run from the PE routers
> 	to test LSP connectivity between CEs. It is possible to run pings
> 	from the CEs and by making every CE also a member of the NMS VPN we
> 	can get the CEs to send network performance information back to the
> 	NMS. However how many CEs does 1 CE have to ping to measure LSP
> 	connectivity? The CEs have to be owned by the network operator in
> 	order for the network operator to provider this service. It is not
> 	acceptable to network operators to force customers to monitor their
> 	VPN service in order to raise alarms of LSP failures where customers
> 	own their own CPE.
> 
> 3 - Non-uniqueness of IP Addresses in an IP VPN Service.
> 	In an IP VPN service different customers will be reusing the same
> 	address space. This leads to the possibility that if a LSP is
> 	misdirected that a ping test would still suceed. Usually this
> 	will require 2 faults, that is the outgoing and return LSPs to
> 	be misdirected however this is feasible as a single bug on a single
> 	LSR could lead to this. There is also the possibility that if
> 	CE a is using registered addresses to source the ping and pinging
> 	a private address, in the event of a misdirection of an LSP, the
> 	wrong device would respond and send the response back to the
> 	registered address via the Internet (I've actually seen this
> happen!).
	[Harrison,N,Neil,INC1 X]  This is 'the wrong layer' issue again.

> 4 - Failure of Traceroute where customers have their own MPLS network in
> an
> 	IP VPN environment.
> 	In the simple IP VPN service where we only offer standard IP 
> 	connectivity to customers traceroute may suffice (Although
> tracerouting
> 	to a customer's private address from within the provider core is
> 	not possible!) However if in the future there is a market for
> selling
> 	MPLS connectivity to customers in an IP VPN service traceroute
> 	will have many shortcommings. (I can imagine large corporate
> customers
> 	running their own MPLS networks and wanting to buy some service from
> 	network operators to connect their large MPLS networks together).
> 	In this situation traceroute is an insufficient tool for the
> 	customer to use and for the network operator to use. (I don't ever
> 	see how the network operator could traceroute into the customer's
> 	network but if the customer has tools to traceroute across their
> 	nets and the providers nets in an end-to-end manner it would be
> useful.)
	[Harrison,N,Neil,INC1 X]  Wrong layer issue again.

> 5 - Seperation of IP-FEC failures from MPLS LSR label switching failures 
> 	requires seperate tools.
> 	It is true that MPLS OAM would not detect failures in with IP FEC
> and
> 	other possible IP routing failures. However this is reasonable,
> 	similarly ATM OAM does not spot IP failures. The question is can
> 	we depend on IP customers doing their own continuity tests and
> 	reporting failures to the network operators? If MPLS has OAM then
> 	at least the network operator can detect a significant number of
> 	failures in their customers' service. 
> 	In the event of failures in the IP FEC would it be helpful to have
> 	information that rules out failures in the LSRs label switching?
> 	I've run an ISP with a FR backbone and it was always useful to be
> 	able to tell if the fault was in the IP routing or the FR switches.
> 	MPLS OAM would give us the same ability to tell the difference
> 	between "simple" LSR label switching failure and more "complex" IP
> 	routing failures.
	[Harrison,N,Neil,INC1 X]  Wrong layer issue again.

> Peter.

---

From: [email-masked]
Date: Thu, 8 Jun 2000 22:37:47 +0100

Peter Willis observerd.......
	<SNIP>
	>In such a
	situation to get end-to-end MPLS OAM would require integration at
the NMS 
	level,
	an MPLS OAM standard would be an easier way of facilitating this
interworking

If you wait for this (ie TMN-like solutions) then you/I will have
retired....and probably our children too.  This has to be agreed at the
network user/control-plane level.

Neil