Applicability of Existing Solutions to the Problem Space draft-takeda-l1vpn-applicability-03.txt

Outline Purpose of draft –expose areas for further work –convert to an applicability statement as solutions are completed Basic mode solutions –exposure of existing solution for base mode –list of missing functions/capabilities Open discussion on applicability to the Basic mode

Scope Shows the applicability of existing GMPLS protocols and mechanisms to L1VPNs Identifies several areas where additional protocol extensions or modifications are needed to meet the L1VPN service requirements set –applicability of GMPLS protocols and mechanisms for base and extended mode –along with additional work areas needed to fully support the requirements for each model.

Base Mode 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 signaling between the CE and the PE, and then across the provider network

Requirements and Coverage Signaling: CE-CE LSP setup, deletion, modification: –Shuffling [GVPN]: 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 (see [Stitching]) properties of the PE-PE LSP segment are such that exactly one end-to-end LSP can be stitched to the LSP segment i.e., the PE- PE LSP and the CE-CE LSP correspond exactly one to one. there are two sessions (i.e., CE-CE and PE-PE). –Note: Both can be used in combination with LSP nesting [GMPLS-UNI][LSP HIER]

Requirements and Coverage VPN membership information exchange –[GVPN] covers VPN membership information exchange by BGP running on the PEs. –Other possibility is to use IGP based VPN membership information exchange CE-PE TE link information exchange within the provider network –[GVPN] describes potential use of BGP for exchanging CE-PE TE link information. Detailed protocol specifications are needed as additional work. –Other possibility IGP to advertise CE-PE TE links. Since a CE does not participate in routing exchange with the provider network, TE link information must be properly constructed by the PE advertising full CE-PE TE link information

Open Points (CE-PE) CE functionality 1) Status of established CE-CE LSPs L1VPN connections being GMPLS LSPs, re-use of existing GMPLS control mechanisms to monitor the status 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

Open Points (CE-PE) PE functionality 1) How to process incoming CE's signaling requests and translate them into internal (within network) GMPLS LSP requests: detail operations Side question: stitching and/or shuffling ? 2) How to tell CEs about LSP status Same as for CE functionality

Open Points (PE-PE) Resource management per VPN (signaling of PE-PE LSP) –Centralized (no protocol extensions) –Distributed (routing extensions e.g resource coloring) VPN membership information exchange within the provider network –Base mode does not support VPN membership exchange between CE and PE and so such information is assumed to be configured within the provider network (usually on the PEs) –Two existing mechanisms for the functional option of exchanging VPN membership information within the provider network (between PEs) –Detailed analysis of options 1 (BGP) and 2 (IGP) is FFS CE-PE TE link info. exchange within the provider network –To prevent from LSP setup failure due to lack of resources on remote CE-PE TE links, this information may be optionally propagated within the provider network to be used for path computation. –Detailed analysis of options 1 (BGP) and 2 (IGP) is FFS