Re: [Pppext] draft-arberg-pppoe-mtu-gt1492-00

[John Fitzgibbon <[e-mail]>]

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

Changing to real PPP would mean customers need to change their equipment. I 
believe the point of the PPPoE proposal is to maintain compatability so that 
existing customers with PPPoE and an MRU of 1492 will continue to have PPPoE 
with an MRU of 1492. No customer-facing changes required. Only whiners like 
myself would bother to upgrade software and/or hardware to take advantage of 
the 1500 byte MRU.

Having me on "real PPP" and everybody else on PPPoE is the "in tandem" 
scenario I was talking about. More below...


> If you answer, please do not assume this audience is ignorant of IP,
> PPP, PPPoE, PPPoA, etc.

Certainly. I assume quite the opposite, that the audience are the experts on 
IP, PPP, PPPoE, PPPoA, etc. I readily confess that I am not, and apologise if 
my lack of knowledge disappoints. (I am an interested observer, not involved 
with the current proposal, though I did propose a similar idea earlier.)


> What do you mean by "running PPPoE and IP in tandem" as if it were
> radicatlly different than the current case?

This is probably a misleading choice of wording on my part. What I meant:

Customer A uses PPPoE, (and runs IP over PPPoE).
Customer B uses PPPoA, or "raw" IP, or whatever....

This scenario may be technically simple to implement, but major service 
providers will not support it. It costs them money to train people to test, 
deploy and support new/different protocols. I wish they hadn't chosen PPPoE 
as their protocol-of-choice, but wishful thinking won't change the current 
deployments. Of course you can argue that these are economic, not technical, 
considerations, and are none of the IETF's beeswax, but that doesn't help the 
equipment and service providers who are trying to find a low-cost, workable 
solution to a widespread problem. If the concensus IETF opinion is that the 
proposed "cure" is worse than the "disease", then we should probably just end 
the discussion here.


> Have you used the (or an) other very common IP encapsulation over DSL,
> PPPoA?

Yes. Ironically, my service provider, (apparently like many others), changed 
from using PPPoA to PPPoE. They will no longer allow me to connect to their 
upstream equipment using PPPoA. There are no non-PPPoE residential solutions 
in my area that meet my needs. I am not alone.


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

Agreed.


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

I agree with the theory here, but I'm not sure that this would necessarily be 
a major issue in practise. For most "closed" networks, the providers can 
verify that the new upstream equipment works with the originally provisioned, 
provider-approved, downstream equipment. Therefore, there should not be any 
client-side changes required to maintain the status-quo, (i.e. PPPoE with 
MRU=1492). Only users who upgrade to MRU=1500 would need to make additional 
provisioning choices.

I completely agree that any proposed change should err on the side of caution 
to help mitigate against compatability problems. Again, if the concensus IETF 
opinion is that the proposed change is only likely to make a bad situation 
worse, then we should probably end this discussion.


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

By "ad hoc" I mean a scenario more like Juniper implementing support for an 
MRU > 1492 only when a new tag is specified, while Cisco implement support 
for a higher negotiated MRUs without a tag, or with a different tag. At least 
if there is an Informational RFC, then there is an increased likelihood that 
the implementations would maintain some level of compatability. 

If the concensus IETF view is that such an RFC would not be accepted without a 
warning that says "DO NOT IMPLEMENT", (as opposed to the wording James 
Carlson suggested), then I would think that this whole discussion is moot. A 
detailed description of a protocol change that is not to be implemented would 
surely be a waste of time.

John Fitzgibbon




On Thursday 07 July 2005 03:15 pm, Vernon Schryver wrote:
> > From: John Fitzgibbon <[e-mail]>
> >
> > > 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    [e-mail]
>
> _______________________________________________
> Pppext mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pppext


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