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

From: Bo Berry <[email-masked]>
Date: Wed, 02 Feb 2005 13:55:46 -0500

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.

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

---

From: John Fitzgibbon <[email-masked]>
Date: Thu, 3 Feb 2005 11:05:59 -0800

> 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 
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. Upon investigation, (google), 
it turned out that I was not alone -- many people have reported problems 
arising out of the widespread use of PPPoE by broadband providers. 
Presumably, there are many, many more who simply aren't aware that certain 
relatively obscure connectivity issues may be related to the PPPoE link to 
their service provider.

Thanks to all for the feedback,
John Fitzgibbon

---

From: James Carlson <[email-masked]>
Date: Thu, 3 Feb 2005 15:02:19 -0500

> 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.)

> lack of transparency resulting from an MTU of 1492 causes me some headaches. 

Right.  A lot of people are in that same boat.

Running plain old IP over Ethernet and using DHCP for both address
assignment and accounting, rather than resorting to tunneling IP over
PPP over PPPoE over Ethernet over ATM over DSL, might have been a
better idea.

> couldn't change SBC, I'd try to change PPPoE.

Their equipment, as I understand it, terminates your DSL link and
sends the ATM directly to your ISP.  There it should hit an Ethernet-
over-ATM bridge and end up in some kind of PPPoE concentrator.

What's your plan for upgrading your ISP's equipment to handle the new
oversize frames?

> Upon investigation, (google), 

Indeed.  It's a widespread problem with PPPoE.  There might be other
options.

> relatively obscure connectivity issues may be related to the PPPoE link to 

What about Vern Schryver's suggestion that you use RFC 1990 MP with a
single link instead?  Doing so would not involve inventing any new
protocols, and would involve changing fewer of the boxes in the
picture.  Just your system and the ISP's concentrator would need
standard Multilink PPP support.  It's possible that at least one of
these already supports it.

-- 
James Carlson, IP Systems Group?               <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 3 Feb 2005 13:27:37 -0700 (MST)

> From: John Fitzgibbon <[email-masked]>

> 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
you get from the ILEX, but I think you rarely get more value than what
you pay for.  My DSL link uses PPPoA and handles 1500 byte IP packets.

Vernon Schryver    [email-masked]

---

From: Bo Berry <[email-masked]>
Date: Thu, 03 Feb 2005 17:51:04 -0500

John:

Few comments (to follow suit of Vernon and James)

-Bo

>that could break backwards compatability.
Good, Breaking things is not allowed

>A question: is this a suitable forum for allocating a new tag?
for PPPoE tags, yes

>Some background on my rationale:
If SBC does not sign up to make the corresponding PPPoE changes, you
are still stuck.  Given that they are reluctant, you better be sure
they will make the changes.  Suggest you ask about cost and schedule.

It may be wise to review the google based 'marketing assessment'
with ISPs, such as SBC, to determine if this really has market
value and justifies the effort.