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

From: "Jerome Moisand" <[email-masked]>
Date: Thu, 7 Jul 2005 13:15:25 -0400

James and al.

1. You made me check, and you are indeed correct about the lack of IEEE
standard for jumbo-frames. This is such a widely supported practice
though and DSL providers have enough control on the access/aggregation
network to easily enforce support for jumbo-frames on each network
segment. 
=> Agreed, you have a point, a disclaimer might be in order.

2. New PPPoE tag: we're in agreement here. I'm going to make a proposal
for including such mechanism in an update to the proposed I-D, after
syncing up with the existing co-authors. 

Please note that this entire discussion applies to tens of millions of
DSL lines worldwide. So this is quite a real-life situation.

Tx
Jerome

-----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: Vernon Schryver <[email-masked]>
Date: Thu, 7 Jul 2005 13:30:48 -0600 (MDT)

> From: "Jerome Moisand" <[email-masked]>

> DSL lines worldwide. So this is quite a real-life situation.

Please!  There are zillions of DSL lines, but the proposal is not about
real-life until and unless it becomes a widely implemented de facto
standard.  If theoretical or claimed market size were tantamount to
real-life, then we'd be using ISO OSI suite today, along with a lot
of other things that somehow ever crossed from claimed market potential
to what some of us understand as reality.

I've not noticed an answer to the question of why it would not be
better to switch to ordinary IP/PPP, perhaps BP instead of IPCP,
from PPPoE.  Why wouldn't that more of any available MTU increase from
802.3 jumbo frames?  Why wouldn't that be at just as easy to implement
in in all of the boxes that will need new firmware or software for
any change?  Why wouldn't it be at least as robust?

Vernon Schryver    [email-masked]

---

From: John Fitzgibbon <[email-masked]>
Date: Thu, 7 Jul 2005 14:16:31 -0700

On Thursday 07 July 2005 12:30 pm, Vernon Schryver wrote:

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

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.

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 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 would rather see this "kludge", (and its limitations), formalized in an 
Informational RFC than implemented in an ad-hoc way.

John Fitzgibbon

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 7 Jul 2005 16:15:33 -0600 (MDT)

> From: John Fitzgibbon <[email-masked]>

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

> issue assured me that they will not support multiple delivery protocols any 

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

> 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 

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

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

---

From: Diamantis Kourkouzelis <[email-masked]>
Date: Thu, 07 Jul 2005 15:53:34 -0700

Hi Vernon,

 What are your thoughts on figure 3 of the draft? The modem is pppoa,
 the dslam initiates the pppoe connection (transparent to the modem)
 and the bras accepts the 1500 mru requested by the modem (assuming
 the port mtu on the bras can support at least 1508).

 How does that affect the user or impose any requirement for a modem
 firmware upgrade? Any data being sent by the dslam towards the modem will
 still be at 1500 max (pppoa).

 Diamantis

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 7 Jul 2005 18:23:12 -0600 (MDT)

> From: Diamantis Kourkouzelis <[email-masked]>

>  still be at 1500 max (pppoa).

What magic switches the customer premises equipment (CPE or end
user DSL modem) from PPPoE to PPPoA?  How do you reach out and
toggle switches in those bazillions of CPE that were just today
mentioned as justifying this proposal without a problematic remote
reconfiguration and reboot of zillions of CPE and probably a new
firmware download to change the hold-reset-button-with-paper-clip
default for the PPPoE/PPPoA switch?

I wonder also how much market there would be for a protocol that would
give providers more classes of customer, new DSLAM+CPE that likes PPPoA
vs. old DSLAM+CPE that prefers PPPoE, merely so that some customers
would have MTUs of 1500.

However, as far as I'm concerned, switching the CPE-DSLAM link to PPPoA
would amount to switching to from PPPoE to standard IP over PPP as far
as the IETF is concerned.  The provider's internal, private links seem
outside the perview of the IETF.  It strikes me as perverse to
re-encapsulate perfectly good IP/.../ATM packets in and out of
IP/.../PPPoE/.../ATM in the broadband remote access server (BRAS), but
none of my business.  If a vendor has a wonderful SuperDuperUltra-
WideBandSpreadSpectrum or other magic to move IP packets between a
DSLAM and a service provider's routers, then great and why should the
IETF interfere, give permission, or be involved at all?

---

From: Diamantis Kourkouzelis <[email-masked]>
Date: Thu, 07 Jul 2005 18:15:04 -0700

Hi Vernon,

 The modem was never pppoe to begin with. The pppoe
 session will be initiated by the dslam when it receives
 the lcp confreq from the modem and will forward it
 to the bras (over pppoe) once the pppoe session gets
 established.

 When the dslam receives the lcp confack from the bras,
 it will strip the pppoe header and send it to the modem.
 The dslam is responsible for the vpi/vci to pppoe session-id
 mapping. As far as the modem is concerned, there is no pppoe
 segment in the network, unless the bras naks the 1500 mru
 down to 1492, as it would do today.

 Diamantis

---

From: John Fitzgibbon <[email-masked]>
Date: Thu, 7 Jul 2005 19:06:12 -0700

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

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

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

> the larger MTU. 

Agreed.

> As James Carlson has repeated pointed out, end users

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.

> 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:
> > 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.
>
> > issue assured me that they will not support multiple delivery protocols
> > any time soon.
>
> > 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.
>
> > 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.
>

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 7 Jul 2005 21:08:37 -0600 (MDT)

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

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

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

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

> MRU=1492). Only users who upgrade to MRU=1500 would need to make additional 

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.

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

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