Presentation on theme: "Protection Mechanisms for LDP P2MP/MP2MP LSP draft-zhao-mpls-mldp-protections-02.txt Quintin Zhao, Emily Chen, Tao Chou Huawei Technology Daniel King OldDog."— Presentation transcript:
Protection Mechanisms for LDP P2MP/MP2MP LSP draft-zhao-mpls-mldp-protections-02.txt Quintin Zhao, Emily Chen, Tao Chou Huawei Technology Daniel King OldDog Consulting 83 rd IETF @ Paris
Updates for Version 02 Since IETF82, We have received a number of comments and suggestions both from the Taipei meeting and after the meeting. Notable thanks to Ijsbrand Wijnands and Alia Atlas for their comments. Using the aforementioned feedback. The major updates in the new version include: 1.Protocol extension and procedure details have been added for: -The backup p2p LSP’s cleanup for p2p based mLDP node protection. -P2MP based mLDP node protection. 2.Two switchover modes for backup path forwarding have been added: -One mode is for the case when node failure detection from the PLR node is not available -Second mode is for the case when the node failure detection from the PLR node is available; 3.Further Examples for p2p based mLDP node protection and p2mp based mLDP node, providing emphasis on procedures. 83 rd IETF @ Paris
3 Solution 1: Node protection using P2P backup LSP Two Options Exist for Cleanup of Backup Path: Method 1, timer based cleanup of the backup path: ① A label reserve timer on both Merge Point (MP) and Point of Local Repair (PLR) is synched during the LSP setup through the node being protected; ② MPT will set up this timer after network convergence, and delete the old forwarding entry after MBB finished or reserve timer timeout. Note that MPT MUST keep the old label resource until reserve timer expire, this is a local behavior. ③ After the failure is detected, PLR: removes the backup path after a reserve timer timeout. Method 2, T-LDP cleanup of the backup path: ① A T-LDP session between MP and PLR is setup during the LSP setup; ② MPT will delete the old label if: session down, network convergence, or MBB has finished. The MP will send the notification message, with withdraw flag, to the PLR MPT using T-LDP. ③ The PLR will cleanup the backup path after it receives this notification message from MPT via the T-LDP session. 83 rd IETF @ Paris
4 Example for Timer Based Node Protection using P2P LDP Backup LSP 1.R2 send notification message to R3 including its downstream LSR’s information: R1 and R4 node addresses & label reserve time(5s) & forwarding labels(L1 and L4) & other optional parameters respectively. 2.When R3 detects the R2 failing, it will send traffic over the two P2P LDP backup tunnels to R1 and R4 : a)Tunnel Red : R3->R6->R5->R4 using inner label L1; b)Tunnel Blue: R3->R6->R5->R4->R1 using Inner label L4; 3.R1 and R4 will process the packets just as they receive from the R2 after they pop the tunnel label; 4.The backup traffic will be stopped when PLR’s reserve timer timeout. R2 R6 R3 R4 R5 R1 12.0.0. 1 Root Receiver Label L1 5s Label L4 5s Label L2Label L3 L4 Tunnel L4 Tunnel L4 L1 Tunnel L1 Tunnel L1 Tunnel L1 Label L1’ 5s Label L4’ 5sLabel L5 Label L6 P2P based protection Capability Config timer 5s Reserve timeout 83 rd IETF @ Paris Notification: R1 node address&L1&5s R4 node address&L4&5s
5 T-LDP Based Node Protection by P2P LDP Backup LSP with T-LDP There still has another choice to cleanup the backup path information. Following is the differences between the previous solution: 1. PLR need trigger the T-LDP between PLR and MPs, T-LDPs of ‘R3-R1’ and ‘R3-R4’ in the example. 2. MP will send notification message to PLR when it finish the procedure of MBB or convergence. PLR will delete its backup path when receives this notification message. R2 R6 R3 R4 R5 R1 12.0.0. 1 Root Receiver Label L1 Label L4 Label L2Label L3 L4 Tunnel L4 Tunnel L4 L1 Tunnel L1 Tunnel L1 Tunnel L1 Label L1’ Label L4’Label L5 Label L6 P2P based protection Capability T-LDP Session Notification: L1 delete Notification: L4 delete T-LDP Session Note: Ice and Alia will present another alternative to this next using the T-LDP to setting up and cleanup of the backup LSP. 83 rd IETF @ Paris Notification: R1 node address&L1 R4 node address&L4
83 rd IETF @ Paris Protocol Extensions for P2P Based Solution (1) A new type of LDP MP Status Value Element is introduced for notifying downstream LSRs and respective labels. The encoding is as follows:
83 rd IETF @ Paris Protocol Extensions for P2P Based Solution (2) The Downstream Element encoding is : Backup Label: The label assigned by MP for PLR Downstream Node Address: Downstream node’s LSR-ID address D Bit: Delete Flag, The type of deleting backup label: 1 = ’explicit-delete’, delete by MP’s notification message through T-LDP 0 = ’implicit-delete’, delete by reserve-timer expire N Bit: Node Failure Required Flag, the occasion of switching traffic’s on PLR 1 = ’Y’, switch traffic to backup path only when PLR detects the node failure 0 = ’N’, switch traffic to backup path when PLR detects failure Res-time:The time of MP’s reserve-timer, synchronizing to PLR. It is effective when D bit set as ’implicit-delete’ and MUST be ignored when D bit set as ’explicit-delete’.
8 Solution2: Node Protection Using P2MP LDP Backup LSP 1.N sends its up-stream’s(PLR) information in notification message to its downstream LSRs(MPs).This message triggers MP setting up a backup P2MP LSP toward PLR. PLR’s address, P2MP FEC key, N’s address is the key of this backup path. This backup path will avoid N if possible. 2.When PLR detects N failure, it switches the traffic to backup P2MP LSP path. 3.This backup P2MP LSP will be destroyed by label mapping withdraw message, after MP convergence. 83 rd IETF @ Paris label L64 label L74 label L21 label L42 R1(ROOT) Notification PLR Notification PLR Notification PLR Backup label L65 Backup label L53 Backup label L32 Label L65’ Label L75’ Label L53’ Label 32’ Withdraw L65 Withdraw L75 Withdraw L53 Withdraw L32 R2(PLR) R3(Pn1) R5(Pn2) R7(MP2)R6(MP1) R4(N)
83 rd IETF @ Paris Protocol Extensions for P2MP Based Solution (1) A new type of LDP MP Status Value Element is introduced, for notifying upstream LSR information. It is encoded as: mLDP FRR Type: Type 3 (to be assigned by IANA) Length:If the Address Family is IPv4, the Length MUST be 5; If the Address Family is IPv6, the Length MUST be 17. PLR Node Address: The host address of the PLR Node.
83 rd IETF @ Paris Protocol Extensions for P2MP Based Solution (2) A new type of LDP MP Status Value Element is introduced, for setting up secondary mLDP LSP. It is encoded as: mLDP FRR Type: Type 4 (to be assigned by IANA) Length: If the Address Family is IPv4, the Address Length MUST be 9; if the Address Family is IPv6, the Address Length MUST be 33. Status code: 1 = Primary path for traffic forwarding 2 = Secondary path for traffic forwarding PLR Node Address: The host address of the PLR Node. Protected Node Address: The host address of the Protected Node. N Bit: Node Failure Required Flag, which indicates the switchover timing on PLR. 1 = ’Y’, switch traffic to backup path only when PLR detects the node failure. 0 = ’N’, switch traffic to backup path when PLR detects failure.
Scenario: The Protection of Node N with 100 Merge Point (MP) and each Merge Point with 10 leaves. Backup path Bandwidth Cost on Path Per PLR ( LSP Bandwidth is M) T-LDP Sessions (for the whole tree) P2P Based Solution Cleanup by timer1 00M0 Cleanup by T-LDP100M >100*10 P2MP Based Solution 1 M (assuming that MPs Share the same alternate N) 0 Analysis for An Example Scenario 83 rd IETF @ Paris L1 L10 MP1 MP2 MP100 PLR N N’ L100
Summary & Next Steps The authors will update the draft to include the following points raised during IETF83 discussions: –No additional effort required for MP2MP since the solution is defined based on the PLR and N and MP; Any node, including root, leaf, transit or branch in the MP2MP or P2MP, will function as either PLR, N or MP; –Backward compatibility: all other features such as GR, MBB and Wildcard features should work “as is” now; we will explain this more in the next version of the draft. A need for further evaluation of Timer and T-LDP mechanisms, via more topology, scalability analysis and continued prototyping. Use Cases and input from users would also be welcome; We will continue to work with Ice and Alia (draft-wijnands-mpls-mldp-node- protection), merging drafts is a potential option. 83 rd IETF @ Paris
Thanks! Questions & Comments? 83 rd IETF @ Paris
Your consent to our cookies if you continue to use this website.