headers
Bo Berry | 2 Feb 2005 19:55
Picon
Favicon

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

John:

Sorry if I have missed an email.  What are your
plans for the submitted draft given the expressed
concerns on interoperability. compatability
and its relationship to IEEE standards.

Thanks
-Bo Berry

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: Accommodating an MTU of 1500 in PPPoE
	Author(s)	: J. Fitzgibbon
	Filename	: draft-ietf-pppext-pppoe-mtu-1500-00.txt
	Pages		: 0
	Date		: 2005-1-28
	
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.

_______________________________________________
(Continue reading)

Permalink | Reply | 4 comments |
headers
John Fitzgibbon | 3 Feb 2005 20:05
Favicon

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

> Sorry if I have missed an email.  What are your
> plans for the submitted draft given the expressed
> concerns on interoperability. compatability
> and its relationship to IEEE standards.

Bo,
No, you haven't missed any emails -- I just hadn't noticed that the draft was 
posted.

Looking at the comments:
1) I like the idea of an optional tag -- that's better than negotiating an MRU 
that could break backwards compatability.
2) I also agree that it would be better to restart LCP if MRU-sized 
Echo-Requests go unanswered, (rather than trying to renegotiate).
3) I understand the concern that allowing for a PPPoE header in the frame is 
an IEEE issue, but, frankly, I don't want the hassle of taking this to IEEE.
4) It is entirely appropriate that anything suggested should be an 
informational RFC at best -- I confess I missed the fact that PPPoE is itself 
informational.

I'll try to revise the proposal to reflect these observations and resubmit -- 
even if the result is informational and/or "non-IETF", I value the feedback. 

A question: is this a suitable forum for allocating a new tag?

Some background on my rationale:

This is a real problem for me, and it's not performance related -- I have 
residential DSL service and my provider, SBC, only offer PPPoE, (and they 
seem *very* reluctant to change). Since I write network test software, the
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Carlson | 3 Feb 2005 21:02
Picon

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

John Fitzgibbon writes:
> 3) I understand the concern that allowing for a PPPoE header in the frame is 
> an IEEE issue, but, frankly, I don't want the hassle of taking this to IEEE.

That doesn't quite sound right to me.  I don't think the IETF should
be in the business of approving extensions to IEEE protocols any more
than the IEEE should extend things done in the IETF.

I don't think that ETOOHARD is a good answer here.

> A question: is this a suitable forum for allocating a new tag?

Since the original PPPoE documents were (I believe!) written in the
ADSL Forum and then submitted as individual submissions and published
as RFCs without (substantial) IETF working group review, I'd guess
that ADSL Forum (if it's still active) would probably be more
interested, but that publishing as an RFC wouldn't be entirely wrong.

(Ignoring for the moment my concerns about extending protocols that
are already in conflict with the IETF's stated architectural
direction, namely L2TP.)

> Some background on my rationale:
> 
> This is a real problem for me, and it's not performance related -- I have 
> residential DSL service and my provider, SBC, only offer PPPoE, (and they 
> seem *very* reluctant to change). Since I write network test software, the 
> lack of transparency resulting from an MTU of 1492 causes me some headaches. 

Right.  A lot of people are in that same boat.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vernon Schryver | 3 Feb 2005 21:27
Favicon

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

> From: John Fitzgibbon <fitz <at> jfitz.com>

> This is a real problem for me, and it's not performance related -- I have 
> residential DSL service and my provider, SBC, only offer PPPoE, (and they 
> seem *very* reluctant to change). Since I write network test software, the 
> lack of transparency resulting from an MTU of 1492 causes me some headaches. 
> Given that I'm reasonably sure the hardware is capable of handling a 1500 
> byte MTU, the PPPoE limit seems overly restrictive. My thinking was that if I 
> couldn't change SBC, I'd try to change PPPoE. 

Why won't SBC need to change software, firmware or software at their
end to understand new PPPoE tags?

Is there some evidence that SBC's end of your DSL link will pass
frames with 1500 bytes of IP data over the DSL link to your equipment?
For example, have you tried sending UDP or ICMP packets with the
DF bit set toward your home system to see if and where IP fragmentation
happens?

What CPE do you have that will generate or accept new IEEE tags?
Will it send or accept frames containing 1500 bytes of IP data?
If not, do you have firmware or software source for it so that you
can fix it?

Why isn't this effort too little too late?  PPPoE is an incredibly
nasty, amazingly ill considered kludge, but by the time it came to
the IETF, it seened to be set in concrete.

In many markets there are DSL providers that allow or even require
PPPoA instead of PPPoE.  Their services tend to cost more than what
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bo Berry | 3 Feb 2005 23:51
Picon
Favicon

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

John:

Few comments (to follow suit of Vernon and James)

-Bo

John Fitzgibbon wrote:

>>Sorry if I have missed an email.  What are your
>>plans for the submitted draft given the expressed
>>concerns on interoperability. compatability
>>and its relationship to IEEE standards.
>>    
>>
>
>Bo,
>No, you haven't missed any emails -- I just hadn't noticed that the draft was 
>posted.
>
>Looking at the comments:
>1) I like the idea of an optional tag -- that's better than negotiating an MRU 
>that could break backwards compatability.
>  
>
Good, Breaking things is not allowed

>2) I also agree that it would be better to restart LCP if MRU-sized 
>Echo-Requests go unanswered, (rather than trying to renegotiate).
>3) I understand the concern that allowing for a PPPoE header in the frame is 
>an IEEE issue, but, frankly, I don't want the hassle of taking this to IEEE.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane