Protocol Action: 'Layer 1 VPN Basic Mode' to Proposed Standard

The IESG <> Fri, 30 May 2008 17:02 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 5B9953A6B32; Fri, 30 May 2008 10:02:29 -0700 (PDT)
Received: by (Postfix, from userid 30) id A5BA33A698F; Fri, 30 May 2008 10:02:27 -0700 (PDT)
X-idtracker: yes
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'Layer 1 VPN Basic Mode' to Proposed Standard
Message-Id: <>
Date: Fri, 30 May 2008 10:02:27 -0700
Cc: l1vpn chair <>, Internet Architecture Board <>, l1vpn mailing list <>, RFC Editor <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Announcements <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The IESG has approved the following document:

- 'Layer 1 VPN Basic Mode '
   <draft-ietf-l1vpn-basic-mode-05.txt> as a Proposed Standard

This document is the product of the Layer 1 Virtual Private Networks 
Working Group. 

The IESG contact persons are David Ward and Ross Callon.

A URL of this Internet-Draft is:

Technical Summary

This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM).
L1VPN Basic mode is a port-based VPN. In L1VPN Basic Mode (BM), the
basic unit of service is a Label Switched Path (LSP) between a pair
of customer ports within a given VPN port-topology. This document
defines the operational model using either provisioning or a VPN
auto-discovery mechanism, and the signaling extensions for the L1VPN

Working Group Summary

Nothing of note.
There was some juggling of definitions between this I-D and the two
autodiscovery I-Ds (draft-ietf-l1vpn-bgp-auto-discovery, draft-ietf-
l1vpn-ospf-auto-discovery) as they all three need to encode the same
data elements. The end result was that this I-D contains the encoding
expressed in a protocol-neutral away.

Document Quality

The protocol described in this I-D is largely specified in RFC 4208
which is itself almost entirely a restatement of RFC 3473. RFC 3473 is
widely implemented and well enough deployed. RFC 4208 has been deployed
in a small number of cases, and specific interoperability has been
shown in private labs and at an interoperability event.

The signaling mechanisms to build a L1VPN service have been shown
experimentally by several vendors. In some cases this has required
configuration of the PITs, and in other cases it has used auto-
discovery, but that distinction is not germane to this I-D. Interop
demos of L1VPN services have been performed, and several service
providers are actively looking at the technology and the business case.

RFC Editor NOTE:

Section 4.1.2

  A two octets field whose value indicates address
  family of the CPI. This value is assigned in [L1VPN-BGP-AD].
  A two octets field whose value indicates address
  family of the CPI. This value is taken from [RFC1700].
Section 8.2

  [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers",
            RFC 1700, STD 2, October 1994.

IETF-Announce mailing list