Subject: Re: L1VPN evaluation status?

From: [email-masked]
Date: Tue, 3 May 2005 20:26:25 +0200

alex - ok no problem concerning me

in order to streamline the technical discussion, here below a sum'up and
pointers to the discussion items to be provided on the list indicated with
(*)

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
  (*) Need for an address resolution mechanism (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

Note: concerning reachability information exchange in the (sig+rtg model)
further discussion about homogeneity of the protocols i.e. same protocol
b/w CE-PE and PE-..-PE or different protocol between CE-PE and between PE's
(*)

---

From: Alex Zinin <[email-masked]>
Date: Thu, 5 May 2005 10:03:46 -0700

Dimitri,

  Please go ahead and take this to the list.

-- 
Alex
http://www.psg.com/~zinin