RE: draft-arberg-pppoe-mtu-gt1492-00

Hi,

I'm glad you got that out of your system Karl, but now let us
try and reset the discussion, and deal with some reality.

PPPoE might be a bad idea, but it is very real, and a large percentage
of the top 100 carriers in the world are using it today, and a lot of
them will continue to use it for a long time to come, and as such it
is only natural that PPPoE requirements evolve over time.

Sine PPPoE was made an informational RFC back in 1999, at least
in my mind, will say that IETF and as such the pppext working group is
the right place to discuss enhancements to the protocol.

The draft-arberg-pppoe-mtu-gt1492-00 is in no way looking to be on
the standard track, it is intended to become an informational RFC to
tell people what is deployed and doable today in carriers networks.

It is a lot easier if different carriers and vendors have a common
document to base their discussion on.

The "draft-arberg-pppoe-mtu-gt1492-00" intention is not to solve
every single problem in increasing ethernet MTU, and I will be the first
to admit that it is not the intention of the draft to solve a generic
ethernet aggregation network, and make sure the ethernet MTU from
PPPoE client to PPPoE server is correctly defined and working.

Again as long as this is not intended as a standard RFC, I personally
see no problems in making a disclaimer in the draft as James suggest,
that this draft do not conform to IEEE standards, isn't endorsed by the 
IETF/IESG, and may simply fall apart in some deployments.

Even better I will happily change the draft to outline the scenario in
which the proposed functionality will not work.

Let us agree that networks can always be build in a way where they simply
do not work, even if all functionality follows a defined standard.

The draft is intended to allow a larger negotiated PPPoE MRU in networks
designed for such functionality, and it is the idea that the control 
of enabling such functionality should be in the power of the carrier,
as they can decide if the BRAS is to allow a MRU negotiation larger 
than 1492, and when it will allow it.

Since again the intention is not to solve all network issues when 
increasing the PPPoE MRU, I also do not see a need for introducing a
must support for a new PPPoE tag.

Some BRAS equipment as well as CPE equipment today will allow the 
functionality as it is defined in the draft, and in a well known
ethernet network it will allow MRU increase to PPPoE clients in a 
safe and backward compatible manner based on a simple MRU size
configuration in the CPE and a more advanced configuration in the BRAS
of when to allow this.

Since many (most) broadband networks today is build in a way where the
PPPoE client has the active role in initiating the PPP negotiation, 
a BRAS PPPoE server will based on it's configuration and the initial 
MRU request from the client have a knowledge of when to allow a larger 
MRU and when not to do so. So in such a network a new PPPoE tag will be 
of no value.

Only in a network where the PPPoE server (BRAS) is the active part in
initiating the PPP negotiation will it not be possible to increase
the MRU in a safe backward compatible manner, with a single centralized 
BRAS configuration, and only in such a network design do it make sense to 
me to include an optional new PPPoE tag to be sent from the PPPoE client 
to the server to indicate a larger MRU is acceptable to the client.


thanks,
Peter



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Karl Fox
> Sent: 3. juli 2005 01:23
> To: James Carlson
> Cc: [email protected]
> Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00
> 
> On Jul 2, 2005, at 3:31 PM, James Carlson wrote:
> > Jerome Moisand writes:
> >> Yet we need the mitigation mechanism to deal with legacy cases, and
> >> notably home LANs limited to 1500 Ethernet frames.
> >
> > Ditching PPPoE as an unnecessary expense and just using plain old IP
> > on Ethernet would fix that problem neatly.
> 
> PPPoE was a bad idea from the start.  It was rammed through as  
> Informational by a few industry advocates despite warnings and the  
> stern disapproval of essentially every participant in the PPPEXT  
> working group, simply because some large providers didn't want to  
> change their view that all ISP customers should look like dial-up  
> users.  Get over it and use a real protocol, just as Jim recommends.
> 
> Karl
> 
> _______________________________________________
> Pppext mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pppext
> 



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