Subject: L1VPN Work Status and Discussion Points

From: [email-masked]
Date: Thu, 5 May 2005 22:09:53 +0200

Folks,

During the evaluation of the L1VPN work status, several technical
discussion points where identified concerning the CE and PE functionality
that require
further debate.

Here below, a summary of this status and discussion points - indicated by
(*)

Please provide your comments/thoughts on this list

CE functionality
----------------

 1) Reachability information (what prefixes are behind other CEs)
    Note: in the general case, those don't have to be IP

    Signaling model:
    - Manually configuration and/or transparent exchange
    (*) Discuss the need for an address resolution mechanism (note: as this
       mechanism is not L1VPN specific further discussion required as
whether
       within or outside the scope)

    In any case need to ensure proper reachability information exchange
    among PE's such that incoming request can be routed toward the
    appropriate egress PE

    In a first phase, all VPN sites are managed by a single administrative
    entity (operator), and this entity knows prefixes behind other CEs. In
    the single carrier context, two cases are possible single vs multiple
AS

 2) Set of signaling parameters: the minimal set is the remote CE interface
    and basic connection characteristics (LSP Encoding Type, BW, etc). The
    current set of parameters in existing GMPLS RSVP-TE signaling documents
    (and related) are good enough to handle this case.

    Note: advanced traffic parameters may include more TE information to
    influence the LSP trajectory.

    Manually configured in the the sig-only and sig+rtg case.

 3) How to signal the connection through the provider's cloud

    Parameters in existing GMPLS RSVP-TE signaling documents (and related)
    are good enough to signal the connection through the provider's cloud.

    As Provider's core nodes (PEs and Ps) and CEs all use GMPLS signaling,
    so no special procedures are required.

 4) Status of established connections

    L1VPN connections being GMPLS LSPs, re-use of existing GMPLS control
    mechanisms can be used to monitor the status of these connections.

    (*) Provide further details for PathErr/ResvErr, Notify message
    exchange through (CE-PE boundary) e.g. IF_ID ERROR_SPEC object TLV; the
    Notify Request object processing and routing of the Notify message

    Note: mechanisms such as data plane OAM mechanisms are out of the scope

PE functionality
----------------

 1) In the sig+rtg model, how to help CEs distribute reachability
    information + (in the per-VPN peer mode) may also need to expose some
    internal topology to the CEs

    Several mechanisms for CEs to distribute reachability information are
    detailed in the GVPN I-D.

    (*) The per-VPN peer model is conceptually similar to virtual routers;
    however as the implementation may be different additional thoughts
    could be required

 2) CE's signaling notation

    As above (2) and 3) for CE functionality

 3) How to process CE's signaling requests and translate them into
    internal GMPLS LSP requests.

    Several mechanisms are possible i.e. stitching and shuffling
    (application of the contiguous LSP signaling to the L1VPN context is
    introduced in Section 2.2 of the GVPN I-D). The latter requires address
    translation at PEs.

    (*) Further details required to support CE functionality (point 4)

    Nesting of the incoming CE-to-CE LSP into a network LSP also requires
    further details.

    (*) Further discussion expected concerning the set of signaling
    mechanisms to be progressed for L1VPN.

 4) How to tell CEs about connection status

    Same as (4) for CE functionality