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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf