Applicability Statement for Layer 1 Virtual Private Networks (L1VPNs) Basic Mode draft-takeda-l1vpn-applicability-basic-mode-00.txt Deborah Brungard (AT&T) Adrian Farrel (Old Dog Consulting) Hamid Ould-Brahim (Nortel Networks) Dimitri Papadimitriou (Alcatel) Tomonori Takeda (NTT) 67th IETF San Diego November 2006

67th IETF San Diego November 2006 History draft-ietf-l1vpn-applicability-01 Applicability analysis (gap analysis) covering both of the basic mode and the enhanced mode Agreed to split into the basic mode part and the enhanced mode part in the IETF65 The intent is to complete the basic mode part immediately following the basic mode solution work This I-D is the basic mode part The document is more like applicability statement 67th IETF San Diego November 2006

67th IETF San Diego November 2006 Document Scope Describe how basic mode solution I-Ds can be used to support the L1VPN Basic Mode service model Signaling draft-ietf-l1vpn-basic-mode Auto-discovery draft-ietf-l1vpn-bgp-auto-discovery draft-ietf-l1vpn-ospf-auto-discovery (Manual) Do not define or require any new protocol extension 67th IETF San Diego November 2006

67th IETF San Diego November 2006 Document Summary Supported Network Types Addressing May use private addresses (both for data plane and control plane) Provider Control of its Infrastructure Provisioning model PE-PE segment control Connectivity restriction Customer Control of its VPN Topology control Note on routing Scalability, Resiliency Scalability Data plane resiliency Control plane resiliency Security, Manageability 67th IETF San Diego November 2006

67th IETF San Diego November 2006 PE-PE Segment Control PE-PE segment is strictly under the provider control, possibly based on the contracts with the customer Example three modes of operation Policy1: On-demand establishment, on-demand path computation Policy 2: On-demand establishment, pre-computed path Policy 3: Pre-establishment, pre-computed path CE PE PE CE PE-PE part is strictly under the provider control 67th IETF San Diego November 2006

Note on Routing Once a VPN connection is established between CEs, this connection is a (TE) link for a customer A customer may configure a routing adjacency over this VPN connection for its own IP/MPLS/GMPLS network This is transparent to the provider (as overlay model), which is different from the enhanced mode VPN connection IP/MPLS/ GMPLS network IP/MPLS/ GMPLS network CE PE PE CE May configure a routing adjacency 67th IETF San Diego November 2006

67th IETF San Diego November 2006 Data Plane Resiliency Nesting, stitching Shuffling PE-PE Segment recovery (but may use other techniques for PE-PE. Will clarify.) Segment recovery CE-PE and PE-PE Link recovery (but may use other techniques for PE-PE. Will clarify.) Link recovery P CE PE PE CE P CE-PE PE-PE CE-PE CE-CE is not supported in the basic mode. Relevant I-D in CCAMP Isn’t it possible to protect only CE-PE link?  Segment recovery for CE-PE link? Will be added 67th IETF San Diego November 2006

67th IETF San Diego November 2006 Next Steps No major known issues Comments are appreciated Ready for WG document? Possible items for enhancement More on use cases of nesting, stitching and shuffling Clean-up text, e.g., remove redundant text with other I-Ds (framework, solutions) Manageability considerations Then ready for WG last call? 67th IETF San Diego November 2006