L1VPN Basic Mode Draft

1. L1VPN Basic Mode Draft draft-fedyk-l1vpn-basic-mode-00.txt Don Fedyk (Editor) dwfedyk@nortel.com Yakov Rekhter (Editor) yakov@juniper.net Dimitri Papadimitriou dimitri.papadimitriou@alcatel.be Richard Rabbat richard@us.fujitsu.com Lou Berger lberger@movaz.com

2. Outline • Scope of the draft • Specify Basic L1VPN mode solutions • Core text for basic mode • Common terminology for L1VPNs • Items addressed by the document • Open items

3. Scope • Show the applicability of existing GMPLS protocols and mechanisms to L1VPNs • Define the terminology for L1VPNs • Identify several areas where additional protocol extensions or modifications are needed to meet the L1VPN service requirements set • applicability of GMPLS protocols and mechanisms for basic mode

4. Basic Mode Requirements • No routing exchange between the CE and the PE • Note: routing operates within the provider network and may be used by PEs to exchange information specific to the VPNs supported by the provider network • LSP setup, deletion, etc. by RFC 3473 signalling between the CE and the PE, and then across the provider network

5. Requirements and Coverage • VPN Port Index Table [Borrowed from GVPN] • Translation of CE port indexes to VPN Provider Index and Provider Port Indexes • Basic Translation mechanism for general scalable control • Allows minimal modification to Provider GVPN signalling • Define signalling procedures • VPN Addressing for CE IPv4, IPv6, NSAP • Some discussion in the DT on NSAP • Need to close on requirement of NSAP

6. Requirements and Coverage • Signalling: CE-CE LSP setup, deletion, modification: • GVPN signalling: • information carried in RSVP-TE messages identifying a LSP (i.e. SESSION and SENDER_TEMPLATE objects) is translated by the ingress and egress PE. • single end-to-end session (i.e., CE-CE), but the identifiers of that session change along the path of the LSP. • Stitching (Not there; Should Be Included)

7. Requirements and Coverage • VPN membership information exchange • [GVPN] covers VPN membership information exchange by protocol running on the PEs. • Other possibility is to use IGP based VPN membership information exchange • No Agreement within design on a particular protocol • Need a transport agnostic way • CE-PE TE link information exchange within the provider network • Same issues as above • Action to split VPN membership protocol out into other IDs • BGP Draft under way

8. Open Points (CE-PE) CE functionality • Status of established CE-CE LSPs L1VPN connections being GMPLS LSPs, re-use of existing GMPLS Overlay signalling of these connections. Provide further details for • PathErr/ResvErr message through CE-PE boundary: IF_ID ERROR_SPEC object TLV • Notify message exchange through CE-PE boundary: • IF_ID ERROR_SPEC object TLV; • Notify Request object processing and routing of the Notify message • Use of LMP between CE-PE • Need to specify the functions that can be ached using LMP

9. Open Points (continued) PE functionality • How to process incoming CE's signalling requests and translate them into internal (within network) GMPLS LSP requests: detail operations Details of : stitching and/or shuffling/index Mapping ? • How to tell CEs about LSP status • PE-PE recovery: Is this more like segment recovery or link protection? • CE-CE Recovery • Pre-configuration of FA LSPs in the PE-PE domain • Allocation of resources versus flexibility of path control

10. Next Steps • Re-spin the draft • Address the Open Points • Address items brought up by first draft review.

11. Questions/Comments?