Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling
draft-kompella-l2vpn-l2vpn-10

[Ballot comment]
Where do the L2VPN TLVs go in the VPLS NLRI?  Does the TLV(s) appear immediately after the VPKS NRLI when sent between the two PEs?

[Ballot comment]
One non-blocking comment from the Gen-ART Review by Roni Even on
  7-Sep-2011 has not been resolved.  Please consider it:
  >
  > Section 4.2 refers to section 4 but I am not sure where this
  > mechanism in section 4 is.

[Ballot comment]
1. In section 1:

> It may be instructive to compare the approach in [RFC4447] and
  [RFC6074] (these are the IETF-approved technologies for the functions
  described in this document, albeit using two separate protocols) with
  the one described here.  Devices implementing the solution described
  in this document must also implement the approach in [RFC4447] and
  [RFC6074].

This mislead me at first reading. I believe that it would be more clear if the non-capitalized 'must' is avoided completely, as [RFC4447] and  [RFC6074] are supported as part of the L2VPN functionality and not as a reuirement for this document.

2. Expand at first encountered instance: DLCI, VPI / VCI, NLRI.

3. It makes sense to bring the Contributors and the Acknowledgments sections one near the other.

[Ballot discuss]
Benson Schliesser reviewed the document (version 07) for OPS-DIR and sent hos review to the authors on 9/29. His review was never answered. Please address the following issues from Benson's review, or in case these were answered and addressed in the meantime provide the appropriate pointers:

1) It is not clear to me whether L2-native end-to-end OAM mechanisms are supported. It seems that the IP-based interworking proposed by this document would be incompatible with native OAM. A discussion on whether this is true, when and how native OAM is supported, etc, would be useful.

2) While there is a brief discussion of "adding" a new site, there is no discussion of "removing" sites.

3) I'm also unclear about behavior during the transition timeframe. When label blocks are growing or shrinking, and PEs might have mismatched label block sizes, what is the correct behavior for label selection, dropping packets, etc?  Is there an implementation mechanism for managing label space correctly, to ensure that blocks can grow? Are these behaviors something that should be configured correctly by the operator?

4) The document doesn't clearly describe the AC-to-label-to-AC mapping, specifically how egress frames are mapped to an AC's local identifier (e.g. DLCI). The operator needs a way to know in advance and/or lookup the local/remote VC identifier mappings for each AC. It seems pretty obvious to me, but the text is not explicit on this point. (Section 3.2.1 talks about ingress DLCI-to-CE mappings; section 5 para 3 says the label is used to determine egress AC; section 6 reiterates these points, but says that the label identifies the CE rather than the AC. Perhaps I overlooked some other text; otherwise the egress mapping should be described explicitly.)

5) Section 4 includes n-to-1 encapsulation types. Given my comments in #4 above regarding identifier mappings, it is even less clear how these types of circuits would work.

6) On the ingress, what happens when the PE receives a frame addressed to itself? In other words, if CE-N sends a frame to the DLCI associated with the Nth index, does it get looped back? Is this a useful operational mechanism for testing connectivity etc?

Supplementary to these please address the following:

IANA has questions about the IANA Actions requested in the IANA
Considerations section of this document.

IANA understands that, upon approval of this document, there are two
IANA actions that must be completed.  IANA further understands that the
two actions involve the creation of two new registries.

IANA Question --> Should these two new registries be standalone
registries, or should they be grouped with, or perhaps subregistries of
existing registries? For example, should these be created at
http://www.iana.org/assignments/bgp-parameters?

IANA understands the actions to be as follows:

First, IANA will create a new registry called the "BGP L2 Encapsulation
Types" registry.  The registration policy for new entries up to and
including value 127 is "Standards Action".  The allocation policy for
values 128 through 251 is "First Come First Served".  The values from
252 through 255 are for "Experimental Use".  The following initial
registrations will be made in this new registry:

+-----------+-------------------------------------------+-----------+
| Encaps    | Description                              | Reference |
| Type      |                                          |          |
+-----------+-------------------------------------------+-----------+
| 0        | Reserved                                  | -        |
|          |                                          |          |
| 1        | Frame Relay                              | RFC 4446  |
|          |                                          |          |
| 2        | ATM AAL5 SDU VCC transport                | RFC 4446  |
|          |                                          |          |
| 3        | ATM transparent cell transport            | RFC 4816  |
|          |                                          |          |
| 4        | Ethernet (VLAN) Tagged Mode              | RFC 4448  |
|          |                                          |          |
| 5        | Ethernet Raw Mode                        | RFC 4448  |
|          |                                          |          |
| 6        | Cisco HDLC                                | RFC 4618  |
|          |                                          |          |
| 7        | PPP                                      | RFC 4618  |
|          |                                          |          |
| 8        | SONET/SDH Circuit Emulation Service      | RFC 4842  |
|          |                                          |          |
| 9        | ATM n-to-one VCC cell transport          | RFC 4717  |
|          |                                          |          |
| 10        | ATM n-to-one VPC cell transport          | RFC 4717  |
|          |                                          |          |
| 11        | IP Layer 2 Transport                      | RFC 3032  |
|          |                                          |          |
| 15        | Frame Relay Port mode                    | RFC 4619  |
|          |                                          |          |
| 17        | Structure-agnostic E1 over packet        | RFC 4553  |
|          |                                          |          |
| 18        | Structure-agnostic T1 (DS1) over packet  | RFC 4553  |
|          |                                          |          |
| 19        | VPLS                                      | RFC 4761  |
|          |                                          |          |
| 20        | Structure-agnostic T3 (DS3) over packet  | RFC 4553  |
|          |                                          |          |
| 21        | Nx64kbit/s Basic Service using            | RFC 5086  |
|          | Structure-aware                          |          |
|          |                                          |          |
| 25        | Frame Relay DLCI                          | RFC 4619  |
|          |                                          |          |
| 40        | Structure-agnostic E3 over packet        | RFC 4553  |
|          |                                          |          |
| 41        | Octet-aligned payload for                | RFC 4553  |
|          | Structure-agnostic DS1 circuits          |          |
|          |                                          |          |
| 42        | E1 Nx64kbit/s with CAS using              | RFC 5086  |
|          | Structure-aware                          |          |
|          |                                          |          |
| 43        | DS1 (ESF) Nx64kbit/s with CAS using      | RFC 5086  |
|          | Structure-aware                          |          |
|          |                                          |          |
| 44        | DS1 (SF) Nx64kbit/s with CAS using        | RFC 5086  |
|          | Structure-aware                          |          |
+-----------+-------------------------------------------+-----------+

Second, IANA will create a new registry called the "BGP L2 TLV Types"
registry. The allocation policy for new entries up to and including
value 127 is "Standards Action".  The allocation policy for values 128
through 251 is "First Come First Served".  The values from 252 through
255 are for "Experimental Use".
The following initial registrations will be made in this new registry:

TLV Type  Description                  Reference
---------- ----------------------------- --------------
    1      Circuit Status Vector        [ RFC-to-be ]

IANA understands that the creation of these two registries are the only
actions required upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Layer 2 Virtual Private Networks Using BGP for Auto-discovery and
  Signaling'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM
  circuits have been around a long time; more recently, Ethernet VPNs,
  including Virtual Private LAN Service, have become popular.
  Traditional L2VPNs often required a separate Service Provider
  infrastructure for each type, and yet another for the Internet and IP
  VPNs.  In addition, L2VPN provisioning was cumbersome.  This document
  presents a new approach to the problem of offering L2VPN services
  where the L2VPN customer's experience is virtually identical to that
  offered by traditional Layer 2 VPNs, but such that a Service Provider
  can maintain a single network for L2VPNs, IP VPNs and the Internet,
  as well as a common provisioning methodology for all services.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kompella-l2vpn-l2vpn/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1149/

PROTO writeup for draft-kompella-l2vpn-l2vpn

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Ross Callon is the document shepherd for draft-kompella-l2vpn-l2vpn. He has reviewed the document and believes that it is ready to forward to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has been reviewed by the L2VPN working group, and has been implemented and deployed. It was also reviewed by the IP/MPLS Forum.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

No concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

This is an individual contribution with AD sponsorship, and is not a WG document. It was presented to and reviewed by the L2VPN working group. However, there was not WG consensus to make it a WG draft.  Instead, the L2VPN chairs (along with the AD's) ultimately determined that it was best to proceed forward as an Individual Informational Draft in order that it was permanently published, along with its codepoint registry, for other implementers to reference.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits?

The document passes ID nits with no errors. There is no formal language used.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?

References are appropriate split. All normative references are to existing RFCs. Since this document is informational, downrefs are not applicable.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?

The IANA section exists and is clear. Appropriate new registries are requested.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

n/a

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

Technical Summary
       
  Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM
  circuits have been around a long time; more recently, Ethernet VPNs,
  including Virtual Private LAN Service, have become popular. This document
  presents a new approach to the problem of offering L2VPN services
  where the L2VPN customer's experience is virtually identical to that
  offered by traditional Layer 2 VPNs, but such that a Service Provider
  can maintain a single network for L2VPNs, IP VPNs and the Internet,
  as well as a common provisioning methodology for all services. This is
  offered for a variety of layer 2 services, such as ATM, Frame Relay, TDM,
  point to point Ethernet, and so on. This approach uses BGP within the
  service provider for autodiscovery and signaling.

Working Group Summary

  This is an individual contribution with AD sponsorship, and is not a WG
  document. It was presented to and reviewed by the L2VPN working group.
  However, there was not WG consensus to make it a WG draft.  Instead, the
  L2VPN chairs (along with the AD's) ultimately determined that it was best to
  proceed forward as an Individual Informational Draft in order that it was
  permanently published, along with its codepoint registry, for other
  implementers to reference.

Document Quality

  There are at least two vendors who have implemented this protocol.  The
  protocol has been implemented and deployed in operational networks.