1 / 14

MPLS-TP BFD for CC-CV proactive and RDI functionalities

MPLS-TP BFD for CC-CV proactive and RDI functionalities. draft-asm-mpls-tp-bfd-cc-cv-02 MPLS WG, 77th IETF - Anaheim . 1. Authors. Annamaria Fulignoli (Ericsson) Sami Boutros (Cisco Systems) Martin Vigoureux (Alcatel-Lucent). Current contributors. George Swallow ( Cisco Systems)

vito
Download Presentation

MPLS-TP BFD for CC-CV proactive and RDI functionalities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MPLS-TP BFD for CC-CV proactive and RDI functionalities draft-asm-mpls-tp-bfd-cc-cv-02 MPLS WG, 77th IETF - Anaheim 1

  2. Authors • Annamaria Fulignoli (Ericsson) • Sami Boutros (Cisco Systems) • Martin Vigoureux (Alcatel-Lucent)

  3. Current contributors • George Swallow (Cisco Systems) • David Ward (Juniper)

  4. Why draft-asm-mpls-tp-bfd-cc-cv • Specify the BFD extension and behavior to satisfy the CC, proactive CV monitoring and the RDI functionality. • BFD behavior needs to be PROFILED ( it’s not only a trivial packet extension) in order to: • meet all MPLS-TP requirement • to have a very simple and fast tool as transport operator require

  5. Problem Statement In the case of bidirectional LSPs, if a bidirectional BFD session is used, it will go down in the event of a failure (or mis-configuration) affecting a single direction, while the expected behaviour, from a transport point of view, is that the up-and-running other direction is still polled at the configured rate. eet at IETF Registration desk

  6. B A Solution Overview Use “Unidirectional” BFD sessions • On bidirectional path two unidirectional BFD sessions MUST be configured, one for each direction of the bidirectional path to be monitored. • Each MEP is aware of the relationship among the MEP source function and MEP sink function of the two unidirectional BFD sessions. • The unidirectional BFD uses the state machine defined in draft-katz-ward-bfd-multipoint-02 • The M bit MUST be always set to 1. • Slow rate startup requires further analysis and is under study.

  7. Unidirectional BFD session M =1 ; Tx = 10 ms; Rx = 0; My Dis = 10; Your = 0; State = UP; Diag = 0 MEP A MEP B M =1 ; Tx = 10 ms; Rx = 0; My Dis= 20; Your = 0; State = UP; Diag = 0 B Sink direction goes in Down State due to a failure from A direction M =1 ; Tx = 10 ms; Rx = 0; My Dis = 10; Your = 0; State = UP; Diag = 0 MEP A MEP B M =1 ; Tx = 10 ms; Rx = 0; My Dis= 20; Your = 0; State = UP; Diag = 1 MEP B needs tosend RDI

  8. Solution applicability • on p2p bidirectional (corouted or associated) • but also on p2p unidirectional and p2mp • RDI simply not required

  9. Non exclusive solution • Possible to run existing BFD • The state machine and behavior are as detailed in draft-ietf-bfd-base for asynchronous BFD. • M bit set to 0

  10. Two modes of operation • Two modes of operation (as for previous draft versions) • CC • Existing ACH codepoint (0x0007) - BFD w/o IP/UDP • Supports CC & RDI • CV/CC • New ACH codepoint • Header contains the Source MEP Identifier (unique per transport path) • BFD control packet format is identical to CC mode • Supports CV & RDI (Implicit CC) • Both apply to PWs, MPLS LSPs (including tandem connection monitoring), and sections

  11. Demultiplexing and the Discriminator Fields • MPLS labels at peer MEPs are used to provide context for the received BFD packets. • On MPLS-TP context the discriminator values have either only local or no significance.

  12. Next Steps • Add more implementation details: • Behaviour of MEP receiving a BFD packet with AdminDown State • Complete the security section • Address comments received • Ask for workgroup adoption

  13. QUESTIONS ? THANK YOU

  14. B A APPENDIX: why going at slow rate when transit from DOWN to UP state does not meet all MPLS-TP requirement • Bidirectional LSP with node A and node B configured MEPs • TX and RX is fixed by operator at 10 msec; detection time multiplier = 3 • Unidirectional failure occurs from node A to node B • In this scenario, node B goes in DOWN state while node A goes in DOWN and than soon in INIT state as it still receives right packets from node B. • If node B starts sending at 1 second rate, as requested by draft-ietf-bfd-base, node A receives right BFD packets from node B , but just one packet per second while the configured detection timeout is 3 * 10 ms . As a consequence: • MEP A flips between DOWN and INIT State due to intermittent Loss Of connectivity defect condition. • a false failure is detected on A node and if protection switching is enabled A switches to protection path even if the worker path is good. • The conclusion is that the Unidirectional protection switching, that is a MUST requirement for MPLS-TP, is not supported .

More Related