Skip to main content

Layer 1 VPN Basic Mode
draft-ietf-l1vpn-basic-mode-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    l1vpn mailing list <l1vpn@ietf.org>, 
    l1vpn chair <l1vpn-chairs@tools.ietf.org>
Subject: Protocol Action: 'Layer 1 VPN Basic Mode' to Proposed 
         Standard 

The IESG has approved the following document:

- 'Layer 1 VPN Basic Mode '
   <draft-ietf-l1vpn-basic-mode-06.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:
http://www.ietf.org/internet-drafts/draft-ietf-l1vpn-basic-mode-06.txt

Ballot Text

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
BM.

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

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

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

RFC Editor Note