MPLS-LDP Adjacency Graceful Shutdown Draft

draft-sboutros-mpls-ldp-gs-adj.txt

Sami Boutros Siva Sivabalan Syed Kamran Bob Thomas

Background

• This problem discussed in these slides has been identified as an area for further study in the LDP RFC (section 6 of RFC 5036 page 90):

“ The current specification does not support shutting down an adjacency.  The motivation for doing it and the mechanisms for  achieving it are left for further study.”

Consider the above scenario:

When enabling LDP on both interfaces, the LSRs will have:

• Two Hello adjacencies; one on each interface• One TCP session

LSR-1 LSR-2

Both LSRs will program the MPLS forwarding table to send MPLS traffic on both links

LDP is enabled on both interfaces

Problem Definition

When disabling LDP on one of the parallel interfaces on one LSR (e.g., LSR-1), MPLS traffic from the neighbor (e.g., LSR-2) transmitted over that interface will be black-holed until LDP Hello adjacency timer expires on the neighbor (e.g., LSR-2)

LSR-1 LSR-2

The reason is that once LDP is disabled on the interface, LSR-1 will: • Stop sending Hello messages on the interface• Stop sending MPLS packets on the interface• Drop received MPLS packets on the interface

LSR-2 will stop sending MPLS packets on the interface only when the Hello timer expires

Disabling LDP on this interface

Problem Definition Continued…

• LSR-1 sends a Hello message with an optional TLV to LSR-2 to indicate that it is about to terminate adjacency on a given interface • LSR-2 re-programs the MPLS LDP forwarding entries to stop using the adjacency, and then sends an acknowledgement back to LSR-1• Upon receiving the acknowledgement, LSR-1 can remove the corresponding forwarding entry

LSR-1 LSR-2

Disabling LDP on this interface

Proposed Solution

Goal: to add network resiliency by eliminating traffic loss when disabling LDP on some of the parallel interfaces either intentionally or unintentionally

Operation

LSR-1 LSR-2

Disabling LDP on this interface

On LSR-1 (originating GS)

1. Stop sending MPLS LDP packets on the disabled interface2. Send N Hello messages to indicate LSR-2 that it is about to terminate the Hello adjacency on the

interface3. Stop sending any more Hello message and starts the timer4. Upon receiving the Hello message with the acknowledgement TLV, remove adjacency from the

forwarding table5. If optional TLV is not received, wait for the timer to expire and remove adjacency from the

forwarding table

On LSR-2:

1. If optional TLV is understood, program MPLS LDP forwarding entries to stop transmitting MPLS LDP traffic over the adjacency, and send a Hello message with an acknowledgement TLV to LSR-1.

2. Continue sending Hello messages

A new optional TLV called Graceful Shutdown (GS) added in the hello message.The GS TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| 0x0404 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type is to be assigned by IANA (recommended value is 0x0404)Length is set to 4 indicating that the value field is 4 Octet longR-bit: indicates whether the Hello message is for graceful shutdown request or acknowledgement. This bit is set to 1 and 0 for request and acknowledgement respectivelyReserved: This field is ignoredIf an LSR does not support GS TLV, it should silently ignore the GS TLV and process the rest of the message. Furthermore, the LSR does not forward the GS TLV any further. Thus, the U and F bits are set to 1 and 0 respectively in accordance with RFC5036

Proposed Solution Continued...

Future Enhancements

• GS capability will be advertised to the neighbors to indicate that an LSR is capable of GS via the LDP capabilities.

• This will help operators to identify GS-capable LSRs in maintenance scenario

• This enhancement is based on the review comments from Rajiv Asati