Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)
draft-arberg-pppoe-mtu-gt1492-03

[Ballot comment]
I share the concerns about interoperability (how the large frames are exchanged) and IANA registry but I'm happy somebody else is already holding the discusses for those.

[Ballot comment]
The write-up doesn't convince me that there is IETF consensus to move this
work further.

I also keep wondering why the solution of the problem described in
this draft is sought in modifying the PPPoE protocol. Perhaps it would
be more appropriate to use the proper tool for the job and not use
PPPoE at all. I have been involved in very early deployments of DSL service
and we did not have any of these problems because we did not use PPPoE in
the first place.

[Ballot comment]
> By default, the Maximum-Receive-Unit (MRU) option MUST follow the
> rules set forward in RFC1661 [2], but MUST NOT be negotiated to a
> larger size than 1492 to guarantee compatibility with Ethernet
> network segments limited to 1500 octets frames. In such a case,
> the PPPoE header being 6 octets and the PPP Protocol ID being
> 2 octets, the PPP MRU MUST NOT be greater than 1492.

The "MUST NOT be negotiated" actually comes from PPPoE. Perhaps you
could make this clearer, as RFC 1661 does allow > 1492 MRU.  For
instance, you can change the first sentence to "By default, the
Maximum-Receive-Unit (MRU) option MUST follow the rules set forward in
RFC 1661 [2] and RFC 2516 [1]. The latter RFC requires that the MRU
MUST NOT be negotiated to a larger size than 1492 to guarantee
compatibility with Ethernet network segments limited to 1500 octets
frames."

(This relates, by the way, to the discussion that the PPPEXT WG has
had about this protocol extension. It turns out that PPP MRU option
itself would have been sufficient to do this if a value > 1492 were
supplied - in theory. In practise, old PPPoE implementations do not always
get it right, so to confirm that the other side actually can handle a
larger MTU we need something.)

Editorial:

  * There are 4 instances of lines with non-ascii characters in the
    document.

[Ballot discuss]
I hoped that the work on IEEE 802.3as was going to support the large
  Ethernet frames proposed by this specification.  However, it seems to
  exceed the scope of that standard development activity.  See
  http://grouper.ieee.org/groups/802/3/as/index.html (especially the
  "IEEE P802.3as Objectives" link).  A simple Google search shows that
  many vendors support jumbo Ethernet frames, but this document needs
  to clearly indicate that support for this feature that is beyond the
  DIX or 802.3 specification (or any supplement that is currently under
  development) is needed.

[Ballot comment]
A few words of introduction is Section 1 before the list of acronyms
  seems appropriate.  They are simply listed after the RFC 2119 boiler
  plate.

[Ballot discuss]
I hoped that the work on IEEE 802.3as was going to support the large
  Ethernet frames proposed by this specification.  However, it seems to
  exceed the scope of that standard development activity.  See
  http://grouper.ieee.org/groups/802/3/as/index.html (especially the
  "IEEE P802.3as Objectives" link).

[Ballot discuss]
The procedure described in this document do not strictly conform
  to IEEE standards for Ethernet packet size, but rely on a widely
  deployed behavior of supporting jumbo frames on Ethernet segments.

Another DISCUSS points to the fact that jumbo frames are not standard IEEE 802.3 Ethernet compliant. IMO this can be accepted in an Informational RFC, but the text needs to be modified to be clear about the face that we are aware that jumbo frames cannot run on Ethernet segments. For example:

OLD:

... jumbo frames on Ethernet segments

NEW:

... frames with Ethernet packet format, but exceeding the maximum packet length as defined by [REFERENCE - IEEE 802.3]

However, there is another issue that this draft does not deal with. There is actually work going on in the IEEE 802.3 Working Group with the purpose of extending the Ehternet frame length. This is not for jumbo frames (which are 8-9k lenght if I am not mistaken) but for extensions required by new IEEE 802.1 projects - specifically P802.1AE MAC Security that adds security headers and  P802.1ad Provider Bridging which adds a new VLAN tag. To accomodate these needs the IEEE 802.3as is discussing frame length extension for standard Ethernet and the figure being discussed is I believe 2k.

I do not know whether the configurations described in the I-D will be impacted by these new standards, but I believe that at this point in time when the IEEE 802.3 WG is working on such a change it would be appropriate to send this draft to the IEEE 802.1 and IEEE 802.3 Working Groups for review before approving it in the IESG.

[Ballot discuss]
Section 4.

  Tag-name:  PPP-Max-Payload
  Tag-value:  0x0120
  Tag-length: 2 octets
  Tag-value:  binary encoded value (max PPP payload in octets)

How is the tag values keept unique? I don't find any IANA registry for it, so how is this ensured? Or have I missed the registry and the IANA section is wrong?

[Ballot discuss]
Section 2, para. 0:

>    The procedure described in this document do not strictly conform
>    to IEEE standards for Ethernet packet size, but rely on a widely
>    deployed behavior of supporting jumbo frames on Ethernet segments.

        DISCUSS: So we're putting out an RFC on something that violates specs
        from another SDO, or at least depends on vendor-specific extensions
        of those specs?

>    Since next generation broadband networks are built around Ethernet
>    systems supporting baby-giants and jumbo frames with payload sizes
>    larger than the normal Ethernet MTU of 1500 octets, a BRAS acting
>    as a PPPoE server MUST support PPPoE MRU negotiations larger than
>    1492 octets in order to limit the amount of fragmented packets in
>    network designs shown in section 1.

        DISCUSS: So the proposed mechanisms depend on the deployment of
        specific underlying network technologies with extensions beyond the
        IEEE standards?

Section 7., para. 1:

>    No IANA action is required.

        DISCUSS: I'm no PPP expert, but shouldn't the value of 0x0120
        for the PPP-Max-Payload tag be registered somewhere?

[Ballot comment]
Section 4., para. 1:

>    If a PPPoE client wants to use a higher MTU/MRU than 1492 octets,
>    then it MUST include an optional PPP-Max-Payload Tag in the PADI
>    and PADR packets.
>    If the PPPoE server can support a higher MTU/MRU than 1492 octets, it
>    MUST respond with an echo of the clients tag in the PADO and PADS
>    packets when the PPP-Max-Payload tag is received from the client.

        This text doesn't prohibit the inclusion of the tag with values
        less than 1492 octets - is it desired to allow this? (Seems like it,
        considering the text in Section 5.1.)

Section 1., para. 0:

>    If the PPP-Max-Payload tag isn?t present, or is present but below
>    1492, then the existing MRU constraint of 1492 octets MUST stay
>    applicable, hence preserving backward compatibility.

        Nit: s/isn?t/is not/

PROTO

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?

    Yes, I have personally reviewed this version of the Internet-
    Draft, and I believe it is ready to forward to the IESG.

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?

    Yes, it has had adequate review from many folks on the WG mailing
    list.  My only concerns are about continuing to breath life into
    a protocol that should have been stillborn, and the likelihood
    that implementors will produce reasonable implementations.

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, etc.)?

    The document requires users to violate IEEE standards in a
    knowing way (jumbo frames).  Other than that, it requires no
    other review.

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.

    Ongoing WG discussion has shown that some implementors are likely
    to forgo important safeguards included in the draft in a
    misguided attempt to "streamline" the operation.  The effect will
    probably be mysterious failures for some users, but probably no
    more tragic than the current Path MTU problems on the Internet
    today.

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?

    The consensus seems relatively weak to me, with a handful of
    PPPoE advocates strongly voicing support for the draft, and
    relative skepticism or apathy elsewhere.  As it seems to be a
    minor change to an Informational protocol, and in general should
    enable some folks who are currently plagued with MTU problems to
    have a better experience, I think it's mostly helpful.

    A much better answer would be to see PPPoE removed from the
    landscape, and replaced by more functional alternatives, such as
    PPPoA or just plain old synchronous PPP on raw bit pipes.
    (Better still to go back in time and not publish 2516 ...)

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.

    No.

1.g) Have the chairs verified that the document adheres to all of the
    ID nits? (see http://www.ietf.org/ID-Checklist.html).

    Yes.  There are non-ASCII (Windows PC) characters in the draft
    that need to be filtered out and some lines are over the 72
    character limit.

    It is missing the required "disclaimer of validity."

    I know of no other nits.

1.h) Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

    No, but all of the references are normative references to other
    published RFCs.