1. A method to monitor active MPLS label Mapping draft-cauchie-opsawg-monitoring-mpls-label-mapping-00 Gregory Cauchie (gregory.cauchie@orange-ftgroup.com)gregory.cauchie@orange-ftgroup.com IETF #79

2. Once upon a time… Received a call from operations “Can you help us? a PW got UP 15 minutes after the IS-IS adjacency went back Up” Issues with the investigation – by that time, PW was UP and everything was OK. – adjacency is between 2 routers from different vendors with two different behaviours implementation issue? protocol issue? configuration issue?

3. The quest Check event timing from the IGP information – alternate path was available and timing OK Explore syslogs and SNMP servers – all label withdrawn/mapping were as expected Explore configuration/behaviour from different vendors – independent vs. ordered label distribution – Revisit the LDP RFC Try to reproduce the situation on the lab

4. Our conclusion sadly, no conclusions  we never found where the tunnel was broken So we stayed with: we love LDP « plug-and-play » but following the LDP events is too hard vendors will not help without clues Problem statement is: -we need a solution to monitor tunnel establishment over time and in details

5. Requirements get the relevant information about tunnel establishment, i.e. label mappings ‘in use’ or ‘active’, over time every routers send their information (because of label mappings local significance) don’t impact the network convergence independence from the label distribution protocol

6. Proposed approach use information from FTN and ILM tables add timestamp encode the whole set in XML compress the XML information send message over TCP session towards a configured server – sending is delayed until convergence is done – new sending is scheduled after any MPLS forwarding decision change (config, reroute, etc)

7. Why not using/upgrading existing stuff?? OAM tools are good for online debugging, not offline troubleshooting SNMP gets comes with a polling issue SNMP traps and Syslog suffer from – no information ACK – no ‘interoperable’ information set – no ‘delay’ feature

8. L3VPN context with PHP Example of information set VRF_1 Push label 11 Push label 22 Swap label 22  3 Pop label 11 R1R2R3 VRF_2 Minimal information set Router ID = @R1 FEC = [ type = VRF_ID ; Loopback IP address = @R3 ; RD = RD2 ] Ingress label value = [ (value = -1 ; origin = 'untagged')] Forwarding operation = [ operation = push ; label = 11 ; next-hop = recursive] Timestamp = 2010/10/10 15:30:01.674842 Message #1 Router ID = @R1 FEC = [ type = IP ; IP prefix = @R3/32 ] Ingress label value = [ (value = 11 ; origin = 'service')] Forwarding operation = [ operation = push ; label = 22 ; next-hop = @R2] Timestamp = 2010/10/10 15:30:01.674842 Message #2 Router ID = @R2 FEC = [ type = IP ; IP prefix = @R3/32 ] Ingress label value = [ (value = 22 ; origin = 'platform')] Forwarding operation = [ operation = swap ; label = 3 ; next-hop = @R3] Timestamp = 2010/10/10 15:30:01.674842 Router ID = @R3 FEC = [ type = VRF_ID ; Loopback IP address = @R3 ; RD = RD2 ] Ingress label value = [ (value = 11 ; origin = 'platform')] Forwarding operation = [ operation = pop ; label = -1 ; next-hop = 'FEC'] Timestamp = 2010/10/10 15:30:01.674842

9. Next steps Next actions on the document – suggestion of using binary rather than XML any preference? – Improve mechanism for service announcements – text for message compression section – text for information sending section – example of Tunnels with ECMP – improve the connection establishment section Get more feedback. Opinions/comments?