2.6.6 Layer 1 Virtual Private Networks (l1vpn)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-20

Chair(s):

Hamid Ould-Brahim <hbrahim@nortel.com>
Adrian Farrel <adrian@olddog.co.uk>
Tomonori Takeda <takeda.tomonori@lab.ntt.co.jp>

Routing Area Director(s):

Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>

Routing Area Advisor:

Alex Zinin <zinin@psg.com>

Mailing Lists:

General Discussion: l1vpn@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/l1vpn
Archive: http://www.ietf.org/mail-archive/web/l1vpn/index.html

Description of Working Group:

The L1VPN Working Group's task is to specify mechanisms necessary for
providing layer-1 VPN services (establishment of layer-1 connections
between CE devices) over a GMPLS-enabled transport service-provider
network.

The following two service models will be addressed:

1. Basic mode: the CE-PE interface's functional repertoire is limited
to
path setup signalling only. Provider's network is not involved in
distribution of customer network's routing information.

2. Enhanced mode: the CE-PE interface provides the signaling
capabilities as in the Basic mode, plus permits limited exchange of
information between the control planes of the provider and the customer
to help such functions as discovery of reachability information in
remote sites, or parameters of the part of the provider's network
dedicated to the customer.

The WG will work on the following items:

1. Framework document defining the reference network model, L1VPN
service model, fundamental assumptions, and terminology.

2. Specification of the L1VPN signaling functionality between the
customer and the provider network to support the basic mode.

3. Specification of the L1VPN signaling and routing functionality
within
the provider network to support the basic mode.

4. OAM features and MIB modules and/or extensions required for the
basic
mode.

5. Specification of the L1VPN signaling and routing functionality
between the customer and the provider network to support the extended
mode.

6. Specification of the L1VPN signaling and routing functionality
within
the provider network to support the extended mode.

7. OAM features and MIB modules and/or extensions required for the
extended mode.

8. Applicability guidelines to compare the basic and extended modes.

At this point the WG will address the single-AS scenario only. The
multi-AS/provider scenario may be considered in future.

Protocol extensions required for L1VPN will be done in cooperation with
MPLS, CCAMP, OSPF, IS-IS, IDR, L3VPN, and other WGs where necessary.

L1VPN WG shall also cooperate with ITU-T SG13 through the established
IETF process, and use documents Y.1312 and Y.1313 (describing L1VPN
requirements and network architectures) as input to its design process.
The documents will be available at the IETF liaison web-site.

Goals and Milestones:

Sep 2005  Submit first Internet Drafts of basic mode specifications
Done  Submit first Internet Draft of L1VPN framework
Dec 2005  Submit first Internet Drafts of MIB modules for basic mode
Apr 2006  Submit basic mode specifications to IESG for publication as Proposed Standard
Jun 2006  Submit first Internet Drafts of enhanced mode specifications
Aug 2006  Submit MIB modules for basic mode to IESG for publication as Proposed Standard
Dec 2006  Submit enhanced mode specifications to IESG for publication as Proposed Standard
Dec 2006  Submit L1VPN framework to IESG for publication as Informational RFC
Aug 2007  Submit MIB modules for enhanced mode to IESG for publication as Proposed Standard
Dec 2007  Recharter or disband

Internet-Drafts:

  • draft-ietf-l1vpn-framework-00.txt
  • draft-ietf-l1vpn-applicability-00.txt

    No Request For Comments

    Current Meeting Report

    Layer-1 VPN WG (l1vpn)
    ======================
    
    WEDNESDAY, November 9, 2005
    1300-1500 Afternoon Session I
    
    CHAIRS: Hamid Ould-Brahim <hbrahim@nortel.com>
            Tomonori Takeda <takeda.tomonori@lab.ntt.co.jp>
            Adrian Farrel <adrian@olddog.co.uk>
    
    NOTES: Adrian and Deborah
    
    ===============================
    Chairs: Agenda bashing
            Status update
    Slides
    
    Hamid reviewed agenda
    - No issues raised
    
    Adrian reviewed working group status and milestones
    - No quesitons or issues
    ===============================
    
    ========================================
    Tomonori: Update on Framework draft
      draft-ietf-l1vpn-framework-00.txt and
      Framework draft discussion
    Slides
    
    Specific questions
    - Anyone interested in scheduling of services?
      - no response from meeting
      - anyone interested should voice on list or send mail
    
    - Does anyone want to do TDM emulation?
      (i.e. use pseudowires to build a virtual TDM mesh that is managed as a L1VPN)
      - no response from meeting
      - anyone interested should voice on list or send mail
    
    Noted further changes needed as per slides
    
    Planned action
    - keep alive for a while and update
      - WG last call around end of 2006
    - align with protocol solutions
    - liaise to SG13
    
    Adrian observed that the default position, if no one has anything to add on the
    open questions, is that the text will remain as is in the draft and the WG will
    move on.
    ==============================
    
    ==============================
    Basic Mode Discussion
    Don:  draft-fedyk-l1vpn-basic-mode-00.txt
    Slides
    
    Several questions were discussed
    - Is there a requirement to support NSAPs?
      The mechanisms for embedding NSAP in IPv6 (RFC 1888) is now marked as historic
      We could bring this back alive simply by republishing, if we need the function
      Question is whether we actually need the function.
      - A poll of room showed slight interest in supporting NSAPs , and no opposition
      Since there is very low cost to supporting this it is easy, but we don't usually
      do things without specific demand
    
    - What protocols should be available for PE-PE basic mode auto-discovery?
      Currently we have a proposal for using BGP (see Hamid's slides later)
      Is anyone interested in proposing an IGP alternative?
      - Lou and Dimitri indicated that they would write a draft
    
    - Can we us LMP for CE-PE?
      - Is the use of LMP for CE-PE discovery/management a basic mode or extended
        mode function?
        - Agreed that there is value in discovering local CE-PE link parameters
        - Agreed that LMP is an option not a requirement
        - Agreed to limit this to vanilla LMP in the basic model at the moment
    
    - Shuffling and Stitching
      - Noted that in Stitcing there are two LSPs i) PE-PE ii) CE-CE
      - RFC 4208 seems to meet the requirements, but some additional documentation
        of process may be required. Not expecting any protocol changes
      - Stitching and Shuffling text to be clarified with reference to CCAMP
        multi-domain work
    
    - All agreed handle pre-config of PE-PE FA LSPs as well as dynamic establishment
    
    - Recovery
      - CE-CE recovery is opaque to the PE, and the problem reduces to how to
        configure/compute/route protection paths
      - We need to look at the GMPLS UNI (RFC 4208) because this does not include
        CE-PE recovery.
        - We need a common approach with CCAMP to solve this
        - We may also need a way to request PE-PE recovery when signaling at the
          CE-PE interface
    
    Plan is to respin this draft once more before debating whether to make it a WG
    document.
    ==============================
    
    ================================================================
    Hamid:  draft-ouldbrahim-l1vpn-bgp-auto-discovery-00.txt (10 min)
    Slides
    
    - Discussion of the BGP parameter exchange.
      - The advertisement of reachability include the port-id and if-id
      - The exchange will support numbered and unnumbered interfaces
          - Hamid: yes
            - Tomonori: if numbered, exchange number else unnum?
              - Hamid yes
    - Are all ports of homogenous capability?
      - Currently this is open with only basic information documented, but could
        carry extended capabilities information
      - Dimitri will send mail to the list with a suggestion of which additional
        parameters might be provided
    ================================================================
    
    ============================
    Extended Mode (10 minutes)
      Discussion led by chairs.
    Slides
    
    - The Extended Mode is considered to offer greater optimality. What is
      "optimality"?
      In general this may mean the ability to have a "better" LSP compared with
      basic mode
      But is this optimality in the client network, the core, or both?
      Discussion is to continue on the list
    
    - In the pictures on the slides, where does the TDM connection start? Is C-C
      connectivity supported.
      C-C is technically out of scope, but we do not want to prevent it
      - We do need to represent the L1VPN model including C-C connectivity
      Thus, since the CE-CE connection is just a TE link in the C-network, C-C
      connectivity may reduce to just an applicability statement
      Note that C may initiate signaling for C-C connectivity and this may trigger
      CE-CE connectivity across the L1VPN or may use existing CE-CE connectivity
      This is nothing special - it is just RFC 4208 (GMPLS Overlay)
    
    - Control plane connectivity service between CEs
      This is a separate service for the provider to offer. We need to be sure we
      can enable it.
      - Solution depends on how you architect the control plane
        Comapre virtual node model with overlay model
      - There is a clear need to exchange out of band control plane information
        between CEs in the extended mode unless we limit to soft-permanent
        connectivity
      Need further discussion on the list for this issue
    
    - The slides don't show the overlay extension properly because the CE-CE links
      are missing and the C nodes are not always shown
    
    - Valuable exercise would be to examine the routing instance modeling
      - cf BGP
      - where are the routing exchanges?
      We need to clarify where the routing happens for each model i.e. where the
      TE links are and where the routing instances are
    
    - Need to think about how to treat/flood routing information in the per-VPN
      model
      - are the P-nodes visible to Cs?
      - is the information flooded to the VPN network?
      - do we need per-VPN address spaces?
      It seems that answer to all of these question may be "yes" but more thought
      is needed
      It would be possible to block flooding at the CE (i.e. prevent core topology
      from reaching the Cs)
    
    - Which extended models to do first?
      There are four main models and several variants and options
      We will not work on all of them at once
      Need to analyse architecture to decide which model we want to look at
      Should be driven by early deployment plans where CE is a packet router
      - Suggestion from the floor
        - not per VPN peer
        - overlay is good
        - after that virtual node
      Provision of control plane connectivity should be part of this discussion
    ============================
    
    ============================
    Next steps:
    
    - further discussions on list
    - continue to work on I-Ds
    - send liaison to ITU-T SG13 to report status
    ============================
    

    Slides

    Agenda
    Update on Framework draft
    Basic Mode solution
    BGP auto discovery
    Enhanced Mode discussion