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

At 03:31 PM 7/2/2005, James Carlson wrote:
>Jerome Moisand writes:
> > 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).
>
>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?
>
> > 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,
>
>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.
>
> > 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.
>
>Ditching PPPoE as an unnecessary expense and just using plain old IP
>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


>--
>James Carlson, KISS Network                    <[email protected]>
>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 protected]
>https://www1.ietf.org/mailman/listinfo/pppext

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