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

> From: John Fitzgibbon <[email protected]>

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

How is having some end users with an MTU of 1492 and others with 1500
not a worse tandem situation?


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

What about the recent messages that seem to say the proposal is only
about end users who all already use PPPoA?


> This scenario may be technically simple to implement, but major service 
> providers will not support it. 

Do you know that for a global fact?  My very limited experience in
buying DSL gave me the choice of any DSL flavor I wanted as long as
it was PPPoA--of course I'd eliminated the ILEX without a moment's
thought.  If you're right, why don't you buy from one of the many
smaller service providers that offer PPPoA?

Why did I eliminate the ILEX?--for a zillion reasons starting with
needing to get my IP address block routed and lacking the courage to
try to explain AS numbers to their end-user sales and support people.


>                                It costs them money to train people to test, 
> deploy and support new/different protocols.

As far as service providers are concerned, why is having vanilla
MTU-1492-PPPoE and improved MTU-1500-PPPoE better than vanilla PPPoE
and vanilla PPPoA?  I think it sounds significant worse, because today
"everyone" knows all about PPPoA and PPPoE and that PPPoE implies 1492.
I seem to be confused, but if the proposal has something to do with a
new flavor of PPPoE visible to users, that would imply large scale
support costs.

Note that many and probably most of the contributors to this mailing
list are more directly concerned about support costs for the users who
are the technical people at service providers who would be doing the
training etc. that you are talking about.


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

Do you define "residenial solutions" as something like "retail consumer
grade for less than $40/month probably with port 25 filtered"?  If so,
that sounds more relevant to your needs than a new PPPoE flavor.
See RFC 4084, "Terminology for Describing Internet Connectivity."


> > 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 did not mean to suggest that end users would make choices.  I was
talking about new software switches inside the CPE added to cover
your odd cases.  There's also the training that residential providers
would need to give their offshore call centers to handle users who
insist on fiddling with things and so forth and so on.


> 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 you think anything done here might prevent or encourage such things,
I think you're quite mistaken.  Juniper, Cisco, et al have demonstrated
an ability to agree and disagree without the let, leave, or hindrance
of the IETF.  What is going on here is an effort to get the IETF to
publish an Information RFC that can be pointed as proof that the IETF
requires support for a modified protocol.  That pointing would be done
in sales meetings with the kind of customers who buy train loads of
DSLAMs.  Minor details like the Informational status of the RFC are
irrelevant or at least glossed in such situations.


> 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),

James Carlson's wording screams "DO NOT IMPLEMENT" to technical people
with IETF experience and so concerns about and scars from interoperability
problems.  You JUST DON'T build things that work only in the right
phase of the moon after you've been stuck trying to explain the lunar
cycle to irate customers with million dollar invoices

Note again that "customers" in this context are not end user customers
of providers but the providers themselves.


Vernon Schryver    [email protected]

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