Re: I-D ACTION:draft-ietf-pppext-pppoe-mtu-1500-00.txt

Vernon

According to the submitted abstract

   Point-to-Point Protocol Over Ethernet, (PPPoE), as described in RFC
   2516, mandates a maximum negotiated MRU of 1492. This memo proposes
   relaxing that restriction to allow a maximum negotiated MRU of 1500.
   This can be achieved by treating the PPPoE Header and Protocol ID as
   part of the Ethernet Header, taking advantage of the fact that most
   network devices have buffers for the Ethernet Header and Payload that
   are at least 1522 octets in size. To aid backward compatability, the
   proposal recommends testing the link with MRU-sized Echo-Request
   packets if an MRU greater than 1492 has been assumed or negotiated.

this is PPPoE related, not PPP.  PPPoE, RFC2516, includes a provision for
optional tags 

RFC 2516             Transmitting PPP Over Ethernet        February 1999

   The PPPoE payload contains zero or more TAGs.  A TAG is a TLV (type-
   length-value) construct and is defined as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          TAG_TYPE             |        TAG_LENGTH             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          TAG_VALUE ...                                        ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TAG_TYPE is a sixteen bit field in network byte order.  Appendix A
   contains a list of all TAG_TYPEs and their TAG_VALUEs.

   TAG_LENGTH is a sixteen bit field.  It is an unsigned number in
   network byte order, indicating the length in octets of the TAG_VALUE.

   If a discovery packet is received with a TAG of unknown TAG_TYPE, the
   TAG MUST be ignored unless otherwise specified in this document.
   This provides for backwards compatibility if/when new TAGs are added.
   If new mandatory TAGs are added, the version number will be
   incremented.

 
Agree, IETF is not the place to redefine IEEE stds.  


-Bo Berry   [email protected]


Vernon Schryver wrote:

>>From: Bo Berry <[email protected]>
>>    
>>
>
>  
>
>>Agree with the interoperability concerns brought forth
>>by J. Carlson.  This is a real problem.  Also performance
>>gain from 1492 to 1500 in the scheme of things is negligible.
>>    
>>
>
>except when the PPPoE link is not directly connected to the sending host
>and you get the problems of IP fragmentation
>
>or except when path MTU discovery is used and something doesn't
>generate or filters ICMP messages, and you get intermittent blackholes
>
>
>  
>
>>If you are really set on gaining 8-bytes, consider defining
>>optional tags to negotiate the extended/longer MTU.  This
>>method would be backward compatible. 
>>    
>>
>
>What is an "optional tag"?  I kind of understand various PPP
>Configure-Request options, but they are not what I'd call tags.  As
>James Carlson wrote, the IETF seems an unlikely forum for modifying
>IEEE standards.
>
>Is there no way to use the LCP MR option to negotiate an effective MTU
>of 1500 on media that differs from classic IEE 802.3 by having a data
>size of 1508 or larger?  Why can't an advanced PPPoE box offer an MRU
>of 1508 or ask for an MTU of 1508 using a Configure-Nak?
>
>The PPPoE 8 byte overhead hassle is far from unique in the PPP world.
>MP (multilink) and CCP (compression) are two common examples.  For
>that matter, why couldn't advanced PPPoE boxes use PPP MP fragmentation
>much as other PPP boxes handle the CCP and MP headers?
>
>
>  
>
>>                                      Another suggestion
>>is to publish as an Informational RFC.
>>    
>>
>
>Whether the proposal RFC is Informational or on the standards track 
>would not affect the interoperability problems.
>
>
>Vernon Schryver    [email protected]
>
>_______________________________________________
>Pppext mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/pppext
>
>  
>


-- 
Warning: This document contains technical data whose export 
is restricted by the Arms Export Control Act (Title 22, U.S.C., 
Sec 2751, et seq.) or the Export Administration Act of 1979, 
as amended (Title 50, U.S.C., App. 2401 et seq.). Violations 
of these export laws are subject to severe criminal penalties.


_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext