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

[Pekka Savola <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf