The MPLS WG Archive

[neil.2.harrison@bt.com]

	TIA wrote <snipped>:
	On another note, I have a question about stat gathering for Network
Management purposes: Is a MPLS router expected to record the same stats
outlined for a regular IP router (ex. rfc1812, MIBs, etc..) ?  My feeling is
that if it's supposed to be multi-protocol, then it shouldn't be snooping
beyond the label stack.

It seems someone else has just realised that an LSP (user-plane) is layer
network in its own right irrespective of its client.  Your observations
(above) are perfectly correct but they do not go far enough.  For example,
there will be defects that affect an MPLS layer network (at some LSP level)
that are relevant only to that LSP and should only be recorded as stats
against that layer network.  There will, however, be client layers that are
effected (and the correct consequent actions need to recurse through all
higher client LSPs and ultimately the top-level LSP client payload, eg
IP)...but the correct defect handling is not to send an ICMP pkt from where
the MPLS layer defect is 1st detected (eg if using BGP4_LSP VPNs then the IP
address is not even known to the (operator's) IGP (ie could not even route
the ICMP pkt), let alone the fact that it is the LSP owner that needs
telling there is a fault and not some external VPN client).

The underlying issue here is correct layering and partitioning (as specified
in G.805).  If one adds O/H at a layer N trail source, that O/H is not
relevant to any client layer or any sever layer......it is only meaningful
(and hence any defect/perf stats dependent on this O/H) between the
source/sink points of the trail at layer N.  O/H handling in MPLS can be
confused in my view....esp wrt to TTL and exp bits, and esp when PHP is
added (PHP is a slightly different issue from other two however, in that O/H
termination occurs at a node earlier than where the trail (=LSP) is actually
supposed to end). 
 
neil