Re: Last Call: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 16 Feb 2006, The IESG wrote:
The IESG has received a request from the Point-to-Point Protocol Extensions WG to consider the following document:

- 'Accommodating an MTU/MRU greater than 1492 in PPPoE '
  <draft-arberg-pppoe-mtu-gt1492-02.txt> as an Informational RFC

I think this is addressing one of operationally important aspects, but I'm not so sure about a couple of particular design decisions made, and would like to see them justified (or points to earlier discussions) or changed.

major discussion points
-----------------------

1)

This doc seems to define a PPPoE option 'PPP-Max-Payload'. It talks of using PPP MRU option. There is no PPP MTU option that I could see.

My question here is, should there be a PPP MTU option instead of a PPPoE option? This would be a more generic solution to this part of the problem, and would also apply in non-PPPoE scenarios for signalling MTU. Am I missing something ?

2)

MRU test procedure using MRU-sized Echo-Requests is disabled by default and to be used for debug purposes only. I'm questioning whether this is wise. The protocol would be much more robust against errors if it always used, once, during the PPP set-up, one roundtrip of MRU-sized packets. This is not a bandwidth issue, because we're talking about fast DSL networks or Gigabit Ethernet. This ensure that the higher MTU is actually supported and actually works as well (e.g., someone hadn't turned off jumbo frames).

So I'd argue it might make sense to put sending/receiving MRU-sized packets (e.g., some padding) right into the negotiation phase.


substantial comments
--------------------

==> first off, a major clarification request: RFC1661 does not mention 'MTU' anywhere,




      <-------------- PPPoA -------------> <- PPPoE session ->

                                       +-----+            +-----+
    +--+              +---+            |     |            |     |
    |PC|--------------|CPE|------------|DSLAM|------------| BRAS|
    +--+    <ATM>     +---+    <ATM>   |     |   <GigE>   |     |
                                       +-----+            +-----+

    Fig. 3: Broadband network designs with PPPoA to PPPoE conversion.

==> surely the <ATM> part between PC and CPE should be something else? It's difficult to believe someone would be considering developing a new PPPoA mechanism which would require deploying ATM on the PCs :-)
This requires some tweaking to the figure and text.

   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 bytes in order to limit the amount of fragmented packets in
   network designs shown in section 1.

5.1 MRU Negotiations

==> this is a very confusing section. It seems you're saying almost the same things about 3 times: at PPPoE pseudo-code, after that in a very confusing explanation of the pseudo-code, and then at the summary of the behaviour. As these use slightly different terms, this left me uncertain of what the actual behaviour is. This section needs a rewrite to remove duplication of specification and to make it clearer.

mostly editorial
----------------

==> This has over half a dozen ID-nits, many of them blocking:
http://tools.ietf.org/wg/pppext/draft-arberg-pppoe-mtu-gt1492/draft-arberg-pppoe-mtu-gt1492-02.nits.txt

==> no refs in the abtract

    In the network design shown in figure 1, fragmentation is typically
    not a problem since the subscriber session is PPPoE end-to-end from
    the PC to the BRAS, so a PPP negotiated MRU of 1492 bytes is
    fully acceptable as it makes the largest PPPoE frame adhere to
    the standard Ethernet MTU of 1500 bytes.

==> well, there is ample evidence that fragmentation is a problem here as well (due to broken firewalls dropping ICMP errors that BRAS'es send), but the text is protocol-wise correct. Maybe reword to describe the problem, to something like:

    In the network design shown in figure 1, fragmentation is typically
    unavoidable since the subscriber session is PPPoE end-to-end from
    the PC to the BRAS, and the standard Ethernet MTU of 1500 sets
    the limit of the frames to 1492 octets.  As this causes issues
    with e.g., Path MTU Discovery, it would be desirable to be able to
    raise the maximum PPP payload size to at least 1500 octets.

.....


    In the network design shown in figure 2, fragmentation becomes a
    major problem since the subscriber session is a combination of
    IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes.

==> the last sentence is misleading: IP over Ethernet does not 'negotiate' anything. You use the default 1500, or you manually configure both ends. Slight reword needed.

      If (PPP-Max-Payload-Tag) Not Present
        Then PPP_MRU_Max = 1492
        Else PPP_MRU_Max = min (PPP-Max-Payload-Tag, Interface MTU-8)

==> for clarity, I'd move 'Else ...' indentation left by two spaces.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]