Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
draft-ietf-l2tpext-pwe3-ethernet-09

[Ballot comment]
Would be nice if the applicability statement explained that this protocol ran over many types of networks including the "public internet". (I'm not sure I could defined what the "public internet" is :-)

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following assignments in
the L2TPv3 Pseudowire Types - per [RFC3931] registry which is located at:

http://www.iana.org/assignments/l2tp-parameters

Value Description
------ ------------------------------
0x0004 Ethernet VLAN Pseudowire Type
0x0005 Ethernet Pseudowire Type

We understand the above to be the only IANA Actions for this document.

[Ballot discuss]
I may not understand the congestion control technique but it looks like it says,  "in case of congestion, pull the plug". I don't believe anyone will implement this congestion control suggestions - and if they do, I don't believe the resulting systems will be usable - they will be impossible to manage not to mention the incredible DOS opportunities. No advice on the threshold is provided. I think this needs to be updated to either be clear no congestion control is provided.

The section titled "Applicability Statement" gives me no idea where this is applicable and where it is not.

[Ballot discuss]
I made the following two comments during the IESG LC. The comments were not addressed:

1. The I-D speaks about 'Ethernet' but does not provide any reference.
What version of the Ethernet standard is targeted here? The latest approved version of the Ethernet standard is IEEE Std 802.3-2005, but the IEEE 802.3 WG also has in works an extension of the frame size as IEEE 802.3as. One cannot talk about Ethernet PDU and MTU without a proper reference.

2. The I-D speaks about 'Ethernet VLAN'. Strictly speaking there is no such thing, Virtual LANs are being defined by IEEE 802.1 and not only for Ethernet. However accepting terminology license based on the de-facto reality that most if not all VLANs run over Ethernet, there still is a need to specify if the document refers to IEEE 802.1Q VLANs (one 12-bit tag) or IEEE 802.1ad which accommodate multiple tags and introduce the concepts of Customer VLAN and Service VLAN. Maybe the VLANs referred in this I-D are transparent to the type of VLANs that are being connected, but even so there should be text explaining this.

[Ballot discuss]
Points from Gen-ART review by Francis Dupont:

>  - 2.2 c): must -> MUST?

...

>  - 3.2: may -> MAY?

...

>  - (technical) 3.3: I am not convinced at all by the very last part
>    (fragmentation/reassemble recommendation) because it is a layer violation
>    and the goal (manage the issue at only one place as explain in
>    L2TPFRAG section 5.1) is not explained.


...

>  - 4: For Ethernet VLAN PW, VLAN tag rewrite ...: can't parse this statement


[BC] I think I can, but the sentence is very hard to understand. For clarity,
shouldn't it be something like

    The VLAN tags of an Ethernet VLAN PW may be rewritten by NSP at
    the egress LCCE, which is outside the scope of this document (see
    Section 3.1).

>  - 4: there is no TOS octet or QoS field in the IP header (look at RFC 2474?)


[BC] Indeed, there is no "for example" about it; there only the DSCP.

>  5: should -> SHOULD ??

[Ballot discuss]
Section 5., paragraph 3:

>    LCCEs SHOULD monitor for congestion (by using explicit congestion
>    notification, or by measuring packet loss) in order to ensure that
>    the service using the Ethernet or Ethernet VLAN PW may be maintained.
>    When severe congestion is detected (for example when enabling
>    Sequencing and detecting that the packet loss is higher than a
>    threshold) the Ethernet or Ethernet VLAN PW SHOULD be halted by
>    tearing down the L2TP session via a CDN message.  The PW may be
>    restarted by manual intervention, or by automatic means after an
>    appropriate waiting time.  Note that the thresholds and time periods
>    for shutdown and possible automatic recovery need to be carefully
>    configured. This is necessary to avoid loss of service due to
>    temporary congestion, and to prevent oscillation between the
>    congested and halted states.

  RFC3985 also says: "Where congestion is avoided by shutting down a PW,
  a suitable mechanism must be provided to prevent it from immediately
  returning to service and causing a series of congestion pulses." I
  don't see such a mechanism in this draft, only the above
  acknowledgment of the issue and the recommendation of careful
  configuration.

  (This is identical to the DISCUSS I have raised
  against draft-ietf-pwe3-atm-encap. As far as I know, PWE3 is working
  on an approach for addressing this. This document, however, belongs to
  a different WG, so I'm not sure if any resolution that PWE3 comes up
  with would apply to this document as well. I'd hope that it would -
  can the authors/ADs confirm?)

June 5, 2006: After discussion, suggested a resolution of the congestion and fragmentation issues. Awaiting author comments. In any case a revised ID will be needed.

AD review resulted in a number of questions and comments. Mail sent to authors and chairs on May 22, 2006. Expecting reply before deciding whether the document needs a revision.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Yes. Ignacio Goyret will be the WG Chair Shepherd for this document.


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

The document has been reviewed in the l2tpext WG. There are no concerns
about the extent of the reviews.

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

I believe the document has received sufficient review since its
initial publication in 2001.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

All concerns raised in the mailing list have been addressed.
The single comment received during WG LC can be found here:
http://www1.ietf.org/mail-archive/web/l2tpext/current/msg01038.html
which was addressed with a new section in the document.
To my knowledge, there aren't any outstanding concerns from anyone.

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?

There have been no dissenting voices during review and/or LC.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).

No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes. The document checks out without any errors.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area Director in
the Last Call downref procedure specified in RFC 3967.

References are properly split. All the references are to already
published RFCs.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

This document describes transport of Ethernet frames over Layer 2
Tunneling Protocol (L2TPv3). This includes the transport of Ethernet
port to port frames as well as the transport of Ethernet VLAN frames.
The mechanism described in this document can be used in the creation
of Pseudo Wires to transport Ethernet frames over an IP network.

* Working Group Summary

The l2tpext WG has reviewed this document. All concerns raised during
review and last call have been addressed.

* Protocol Quality

This is a fairly simple and straight-forward application of L2TPv3
to transport another type of traffic.