MPLS Multiple Topology Support draft-zhao-mpls-ldp-multiple-topology-01 draft-zhao-mpls-rsvp-te-multiple-topology-01 IETF 80 – Prague

Quick Review for These Two Drafts In the previous version of the drafts, we have discussed a few application scenarios; The basic ldp and rsvp-te protocol extensions to support mpls multiple topology; The forwarding options to support mpls multiple topologies; When we presented these two drafts in IETF77, one of the comments we got is to work with service providers to pin down the exact application scenarios where mpls multiple topology can provide unique solutions;

The extended FEC TLV has the format as below: Review: Extensions to LDP FEC Element 1 MT-ID reserved FUFEC(TBD) FEC Element n IETF 80 – Prague

Review: Extensions to RSVP-TE Add MT Information into an object in a message Add MT Information into SESSION object Extended P2P SESSION object for IPv4 IPv4 Tunnel End Address Extended Tunnel ID Tunnel IDMT-ID (12 bits)Resv IETF 80 – Prague

Review: MPLS Forwarding in MT Option 1: MT is implied by Label On a LSR, same FEC with different MT-ID mapped to different Label Advantages: No hardware changes Disadvantages: Label space is limited Option 2: MT is indicated by stacked Label One extra label is stacked to indicate a topology Advantages: Each topology has a full label space Disadvantages: Forwarding is complicated

What is Done in this Version of the Drafts? The prototyping is done and has been demonstrated for a few service providers; There are a few scenarios added in these drafts: Protection Solution using MPLS Multiple Topology Simplify the inter-AS VPN solutions; IETF 80- Prague

Application Scenario Example 1: End-to-End mLDP P2MP backup LSP The primary P2MP LSP set up in the red topology is backed up by the secondary P2MP LSP setup in the blue topology, where the red topology and blue topology dont share the common links and nodes if it is required.

Application Scenario Example2 backbone MAN AS x MAN AS y Province Network AS9808 O&M server Backbone router Province router In order to deploy MPLS VPN with entire network, there is a strong demand to support inter-AS connection and E2E O&M ASO&M backbone network Public AS: 9808 headquarte r province network Private AS: x province Headquarter O&M Province O&M

Solution for Inter-AS MPLS VPN Three mature mechanisms have been used to Inter- AS MPLS VPN Optioin A Option B Option C Option A/B/C can build inter-AS connection of MPLS VPN, but E2E O&M cant be achieved by them We hope to use single AS to solve E2E O&M problem based on the original multiple ASs network

Inter-AS VPN E2E O&M Solutions AS #1 AS #2 AS #3 AS #2 AS #1 A B AS #3 AS #2 AS #4 AS #1 Virtual Router Solution ASolution BSolution C Goal of the Solutions: Transfer inter-AS to Single AS Inter-ASSingle AS A B Expand backbone AS with new routers Expand backbone AS with virtual routers Build new AS with multiple-topology

CMnet backbone Province A Province B Router with default topology Inter-AS VPN E2E O&M Router with VPN topology CMnet backbone AS #1 AS #2 AS #3 AS #2 AS #4 AS #1 Province A Province B O&M server Headquarter O&M Build New AS for MPLS VPN Using MPLS Multiple Topology – Use multiple-topology to create a new AS which merges virtual topologies from backbone and province ASs together – Backbone can achieve E2E O&M within the new AS

Analysis Most of Existing network routers cant support the virtual router by software update. Its also a high cost solution because of substituting the hardware and software Multiple-Topology Virtual Router New Construction is simple and reliable. But the high cost and the inefficient use of existing network resources are not preferable New Construction Considering cost and scalability, utilization and evolution of the existing network, Multiple-Topology is the preferable solution Multiple-Topology is an easy way to deploy by software update. With MT existing network resources could be efficiently used and the network can be of resilent expansion. But the standard is not mature enough

Next Steps We would like to identify more application scenarios in the next version of the draft. We will update the protocol extensions based on the findings from the prototyping in the next version of the drafts; The demonstrations will be given to customers who are interested; We would like to get more feed back from the working group for this draft. IETF 80 - Prague