MPLS draft-chang-mpls-path-protection-02.txt

["Ken Owens" <keno@erlangtech.com>]

Subject: MPLS draft-chang-mpls-path-protection-02.txt                      
NAME OF I-D:

 http://www.ietf.org/internet-drafts/draft-chang-mpls-path-protection-02.txt

SUMMARY

It is expected that MPLS-based recovery could become a viable option for obtaining 
faster restoration than layer 3 rerouting. To deliver reliable service, however, 
multi-protocol label switching (MPLS), requires a set of procedures to provide 
protection of the traffic carried on the label switched paths (LSPs). This imposes 
certain requirements on the path recovery process, and requires procedures for the 
configuration of working and protection paths, for the communication of fault 
information to appropriate switching elements, and for the activation of appropriate 
switchover actions. This document specifies a mechanism for path protection switching 
and restoration in MPLS networks.  

RELATED DOCUMENTS

1. Framework for MPLS-based Recovery, draft-ietf-mpls-recovery-frmwrk-02.txt
2. Requirements for Traffic Engineering Over MPLS, RFC 2702
3. Shared Backup Label Switched Path Restoration, draft-kini-restoration-shared
-backup-00.txt
4. RSVP Label Allocation for Backup Tunnels, draft-swallow-rsvp-bypass-label-01.txt
5. Reservation Protocol with Traffic Engineering Extensions: Extension for Label 
Switched Path Restoration, draft-kini-rsvp-lsp-restoration-00.txt
6. A Method for Setting an Alternative Label Switched Path to Handle Fast Reroute, 
draft-haskin-mpls-fast-reroute-05.txt
7. A Path Protection/Restoration Mechanism for MPLS Networks, draft-chang-mpls-path
-protection-02.txt
8. Extensions to CRLDP for MPLS Path Protection, draft-owens-crldp-path-protection-
ext-00.txt
9. Extensions to RSVP-TE for MPLS Path Protection, draft-chang-mpls-rsvpte-path-
protection-ext-01.txt
10. Generalized Multi-Protocol Label Switching (GMPLS) Architecture, draft-many-
gmpls-architecture-00.txt
11. Enhanced LSP Services, draft-papadimitriou-enhanced-lsps-03.txt
12. Generalized MPLS Recovery Mechanisms, draft-lang-ccamp-recovery-00.txt
13. Open Shortest Path First (OSPF) protocol extensions for Label Switched 
Path restoration, draft-kini-ospf-lsp-restoration-00.txt
14. ReSerVation Protocol with Traffic Engineering extensions. Extension for 
Label Switched Path restoration, draft-kini-rsvp-lsp-restoration-00.txt


WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

  Applications         +-------+  +-------+        (new) Hour glass
  that use CCAMP: \    | TE-WG |  | PPVPN |  ...           /
                   \   +-------+  +-------+               /
                    \     +----------------------+       /
                     \    |         CCAMP        |      /
                      \   |-----------+----------|     / 
                      /   |   C       |    M   --|------ IGP LSA ext
                     /    | control   | measure  |     \ 
                    /     +----------------------+      \
  Technologies to  / +----+ +----+ +----+ +----+ +----+  \
  measure/control:/  |MPLS| |OPT | |RPR | |ATM | | FR |...\
                     +----+ +----+ +----+ +----+ +----+

This work is targeted for MPLS, however TE-WG and CCAMP could use this document as 
a starting point for IP Network Restoration mechanisms.

WHY IS IT TARGETED AT THIS WG

 The following text is taken from the MPLS Charter goals:
"6. Specify MPLS-specific recovery mechanisms to allow one label-switched path to be 
used as backup for a set of other label-switched paths, including cases which permit 
local repair. What constitutes the necessary set of MPLS-specific recovery mechanism 
should be ascertained through cooperation with the CCAMP and TE working groups."

This draft directly addresses MPLS WG's Charter Goal 6 since it specifies MPLS specific 
recovery mechanisms to support path-based restoration in MPLS networks.

JUSTIFICATION

The justification for this document is simple, the MPLS Charter goals are to address 
MPLS specific restoration and that is exactly what this MPLS mechanisms document provides. 
This is not a new work item, it has been worked on for the last year on the WG mailing 
list and discussed at IETF meetings. Once the approval is given to progress this draft, 
it will go for WG consensus, WG last call, and then progress for Informational RFC.