Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00

From: "Jerome Moisand" <[email-masked]>
Date: Fri, 1 Jul 2005 14:28:04 -0400

Not exactly sure what non-IEEE-compliant mechanism you are referring to?

Using a PPP MRU of 1500 over PPPoE clearly implies the use of an
Ethernet frame size larger than 1500 bytes, but IEEE standards now
support such technology (aka jumbo-frames, mini jumbo frames, etc).

So if all network segments between the PPPoE "newer" client and the
PPPoE server support such larger frame as a deployment rule, then we
have no issue, and this seems to me as being fully IEEE compliant.
Practically speaking, the DSL topologies that we have in mind would
indeed have such property.

Yet we need the mitigation mechanism to deal with legacy cases, and
notably home LANs limited to 1500 Ethernet frames.

Am I missing something?

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Friday, July 01, 2005 1:35 PM
To: Jerome Moisand
Cc: [email-masked]
Subject: RE: [Pppext] draft-arberg-pppoe-mtu-gt1492-00

Jerome Moisand writes:
> ==> This feature is intended as a "safety net" and a troubleshooting
> mechanism, but using it for every PPP session establishment would
> significantly lower call setup performance, while not adding any
> meaningful value to typical broadband environments. Personally, I am
> actually not entirely convinced this feature is worth the trouble!

Performance will be much worse if there's a bridged link in path
between PPPoE client and server that restricts the MTU to the
IEEE-specified maximum.  Worse still, if you have a network with
multiple paths for redundancy (using Spanning Tree), the path you take
during PPPoE/PPP session set-up may be different than the one you take
after a successfully-handled L2 link failure, and you get no
notification that this has happened, and the restrictions on the new
path through the L2 network may differ.

In other words, I remain skeptical that this can actually be deployed
safely without having the IEEE itself redefine the L2 header/payload
split to conform to what this proposal is actually doing.  And I think
it's somewhat outside the bounds of normal IETF activity to have a
published RFC that suggests doing something that isn't supported by
the underlying non-IETF standards.

If the draft authors are going to go ahead anyway with publication as
an Informational document, I'd like to see a disclaimer near the top
of the document stating that the procedure described does not conform
to IEEE standards, isn't endorsed by the IETF/IESG, and may simply
fall apart in some deployments.

> ==> I'd like to propose that we introduce a new PPPoE tag where the
> PPPoE client indicates if the 1492 constraint can be lifted (in its
best
> assessment of its own capabilities and of the network it is connected
> to), and to which extent (up to 1500, possibly more). If such new
option
> isn't included by the client, then the existing behavior must be
> assumed.

I agree.  That fixes the naive-client problem; thanks.

-- 
James Carlson, KISS Network                    <[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

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

---

From: James Carlson <[email-masked]>
Date: Sat, 2 Jul 2005 15:31:38 -0400

> support such technology (aka jumbo-frames, mini jumbo frames, etc).

Really?  Can you cite which published IEEE standard actually supports
jumbo frame operation?  (And, better still, describes how the
interoperability problems are mitigated, as that's the crucial bit I
think we're missing here.)

I can't seem to locate the standard that supports this idea.

I know that many products (even from Sun and Juniper) support jumbo
frame operation, but unless I'm missing something I don't see where
it's actually been adopted as a standard.

The last I'd heard was that the 802.3 WG "feels that Jumbo frames are
a bad idea."  Has this been amended?

> have no issue,

Right.  But we simply have no way of knowing that this is true, and
failure modes are both catastrophic and potentially (due to STP)
latent.

I'm really uncomfortable with publishing an RFC that clearly depends
on essentially arbitrary deployment rules in order to function
correctly.  It seems like bad practice to me.

> and this seems to me as being fully IEEE compliant.

That's the part I'm missing.

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

---

From: Karl Fox <[email-masked]>
Date: Sat, 2 Jul 2005 19:23:13 -0400

> 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

---

From: "Peter Arberg" <[email-masked]>
Date: Sun, 3 Jul 2005 02:07:36 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Karl Fox
> Sent: 3. juli 2005 01:23
> To: James Carlson
> Cc: [email-masked]
> Subject: Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00
>

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 2 Jul 2005 18:39:53 -0600 (MDT)

> From: "Peter Arberg" <[email-masked]>

> try and reset the discussion, and deal with some reality.

Yes, let's.  For the many years that I've known them, Karl and Jim
been be too willing to suffer foolishness.  I suspect that what they
are really thinking is vastly stronger than what you have probably
understood from their gentle words.

> is only natural that PPPoE requirements evolve over time.

Those facts do not in any way justify standardizing something that
will have even more interoperability problems that the original PPPoE.
The IETF is not a vanity publish house.  It exists only to minimize
and prevent interoperability problems.

> the right place to discuss enhancements to the protocol.

That reasoning might justify moving all of IEEE's work to the IETF,
since there are RFCs that are standards instead of mere Informational
documents.  Still, if your proposal required changing only IETF
documents, this would be the right place.  However, you have
consistently ignored the point that your proposal depends on changes
in IEEE standards.

> tell people what is deployed and doable today in carriers networks.

The IETF has been trying in recent years to reduce the incidence
of disasters like PPPoE by requiring technical review of even
Informational RFCs.  Unless you can get some consensus that your
proposal has sufficient technical merit and is unlikely to cause
harm, you might and certainly should have problems getting it
published even as an Informational RFC, at least not without some
of the "DANGER DO NOT IMPLEMENT OR EVEN READ THIS!" warnings that
James Carlson has suggested.

> document to base their discussion on.

The IETF has no monopoly on printing presses.  Be honest about what
you are doing and admit that you don't merely want to publish a document
for discussion.  If that's all you wanted to do, you could have done
it on your own web site.  Having had an I-D published would also be
sufficient if you only wanted to float some ideas.  What you are really
doing is what many people have done and many more have tried to do.
That is to get the IETF's imprimatur on a protocol.  You will then go
to other vendors, carriers, and even the IEEE and say "The IETF has
approved this changed as you can see from RFC 98765, so you must go
along with it."

Vernon Schryver    [email-masked]

---

From: Jeff Haag <[email-masked]>
Date: Thu, 07 Jul 2005 20:06:30 -0400

>on Ethernet would fix that problem neatly.

This sounds like the Split PPP approach that we tried to convey in

Network Working Group                                       Jeffrey Haag
Internet-Draft                                           Vince Mammoliti
<draft-haag-pppext-spppoe-00.txt>                       W. Mark Townsley
February 2005                                              cisco Systems

                    Simple PPP over Ethernet (sPPPoE)

Maybe the fact that it was an all Cisco author staff, or that other
companies have already developed/deployed proprietary interworking
technologies, seems to have made this unattractive.  This draft solves the MTU
issue by removing PPPoE from the equation, and using native IP on the
GigE side of the DSLAM:

                      PPPoA            sPPPoE
                CPE ---------- DSLAM ------------ BRAS
                       ATM               GigE

PPP Control frames on the GigE side are encapsulated in a new ethertype, and
IP frames use their native ethertype.

We solicit input on this.  We would like to see an interworking solution
that does not affect the CPE, solves the MTU issue, and does not require
changes to PPP.  We think this is a good start toward that.

Thanks,

Jeff Haag
Cisco Systems