1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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