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

> From: John Fitzgibbon <[email protected]>

> > I've not noticed an answer to the question of why it would not be
> > better to switch to ordinary IP/PPP ...
> > ... Why wouldn't that be at just as easy to implement
>
> Re-architecting "zillions of DSL lines" that work today, (albeit with a sucky 
> MTU of 1492), to use plain old IP, while a laudable goal, would be a 
> provisioning nightmare. It means every customer's setup needs to change. I 
> don't believe any of the big providers would have the stomach for it.

Why would there be any more "re-architecting" to change to real PPP
than to change to the new version of PPPoE?

(If you answer, please do not assume this audience is ignorant of IP,
PPP, PPPoE, PPPoA, etc.  Not to put too fine a point on it, some of
the statements in support of the proposal suggest an odd view of PPP
and at worst marketing smoke and mirrors.  For one example, there was
the recent referenc to "PPP fragmentation" without any mention of the
only PPP fragmentation mechanism I know about, the multilink protocol (MP).
MP sounds like an unlikely addition to PPPoE.


> Running PPPoE and IP in tandem might be feasible, but it still imposes 
> additional administrative costs. The provider I have spoken to about this 
> issue assured me that they will not support multiple delivery protocols any 
> time soon.

What do you mean by "running PPPoE and IP in tandem" as if it were
radicatlly different than the current case?  How many PPPoE DSL customer
gets only PPPoE service without IP service?

Have you used the (or an) other very common IP encapsulation over DSL,
PPPoA?  The several brands of customer premises equipment DSL boxes
I've played with make almost no user-visible distinction between PPPoE
and PPPoA.  They all require about the same configuration choices,
with the choice between PPPoA and PPPoE being merely one among static
vs. DHCP IP address, routing options, and zillions firewall knobs and
switches such as DMZ hosts, VPN help, and internal address block (NAT).


> A point-release software upgrade to a provider's PPPoE-based equipment is a 
> more attainable goal, and it is certainly easier to implement, since it does 
> not break or change the existing client-side provisioning. 

That is true only if the new MTU feature the proposal is not used.
You must at least install new client-side firmware or software to use
the larger MTU.  As James Carlson has repeated pointed out, end users
will probably need to make an additional client-side provisioning
choice of "network is transparent for jumbo 802.3 frames or not."

>                                                            That would at 
> least offer a DSL customer like myself the possibility of getting a compliant 
> IP service, without altering the service for customers that are happy 
> with/unaware of the limitations of their current service. 
>
> This may not be a "technically satisfying" solution, (it's a kludge to fix 
> something that was a bad idea to begin with), but it seems to me like it is 
> the only compromise that stands a chance of getting existing DSL customers 
> out of the "1492" hole, without requiring a massive re-provisioning exercise. 

I cannot see how that can be true.  If you do not change client-side
hardware, perhaps only with "firmware download" but quite possible
with a "fork lift upgrade," you will remain stuck in the "1492 hole."


> I would rather see this "kludge", (and its limitations), formalized in an 
> Informational RFC than implemented in an ad-hoc way.

PPPoE is itself "implemeted in an ad-hoc way."   PPPoE is not an offical
standard but an ad hoc kludge.  There is *ABSOLUTELY NO* chance this
proposal ever being anything published as other than an Informational
RFC with "DO NOT IMPLEMENT" warnings.  If implementations of such a
thing aren't ad hoc, what are?


Vernon Schryver    [email protected]

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