Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Thu, 8 Dec 2005 13:20:05 -0500

James, 
 >
>  The techniques described in this document are intended for use with
>  a particular deployment technique that uses a PPP termination
>  separated from a radio termination by an Ethernet, and that has
>  radio-side flow control for a slower PPP-only link to remote nodes.
>

I, for one, would be OK with this text. 

Regards,
Stan

>-----Original Message-----
>From: James Carlson [mailto:[email-masked]] 
>Sent: Thursday, December 08, 2005 1:06 PM
>To: Stan Ratliff (sratliff)
>Cc: [email-masked]
>Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit
>
>Stan Ratliff (sratliff) writes:
>> >Ethernet supports multiple protocols.  What would you do if someone
>> >ran some protocol *other* than PPPoE over this pseudo-Ethernet?
>> >Wouldn't you be forced to fix the problem all over again?
>> >
>> 
>> I don't understand what you mean here. In our implementation, the 
>> radio and router are connected via a real Ethernet, not a pseudo-
>> Ethernet. There is no intersection I'm aware of with other devices 
>> on the Ethernet communicating with each other via different 
>protocols. 
>> The intent isn't to create a pseudo-Ethernet with the extensions,
>> rather, 
>> the intent is to create a group of pseudo point-to-point links,
>> representing
>> the individual TDMA radio links, tunneling over the Ethernet 
>connection 
>> from radio to router. 
>
>It's Ethernet ... but with a kind of L2 backpressure mechanism that
>regular Ethernet itself doesn't quite have.
>
>My point is that if you had something *other than* PPP to transmit to
>those nodes over the radio, then you'd be sunk.  You'd have to start
>over because PPPoE carries only PPP.
>
>Your assertion seems to rest on a particular deployment and
>combination of protocols: PPP (and nothing else) between radio and
>remote nodes, Ethernet (and nothing else) between radio and router,
>and no way to implement the patently obvious solution -- just
>terminating PPP in the radio and using regular L2 forwarding or IP
>routing outside of that context.  No PPPoE required.
>
>Its narrowness makes it extremely suspicious.  I agree that there may
>well be a problem here that needs to be solved.  I'm deeply concerned
>that this doesn't actually address the problem in any lasting way and
>is instead a diversion for developers.
>
>>   "The techniques described in this document will not be applicable
>>   to all radio implementations. This document describes extensions 
>>   better applied to radios with point-to-point transmission 
>>   characteristics (e.g. TDMA). When used with multi-access, broadcast
>>   capable radios such as 802.11, these techniques may have 
>unpredictable
>>   interactions with higher and lower layers."
>
>How about:
>
>  The techniques described in this document are intended for use with
>  a particular deployment technique that uses a PPP termination
>  separated from a radio termination by an Ethernet, and that has
>  radio-side flow control for a slower PPP-only link to remote nodes.
>
>-- 
>James Carlson, KISS Network                    
><[email-masked]>
>Sun Microsystems / 1 Network Drive         71.232W   Vox +1 
>781 442 2084
>MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
>781 442 1677
>

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

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 09 Dec 2005 05:55:17 -0500

> I, for one, would be OK with this text. 
While I, for one, would not! Merely describing the protocol deployment
environment is a part of the specification, not a WG warning about the
poor design.

Going back 20+ years, I have had considerable experience deploying
protocols over radio links.  The best design would be to put a router
at every radio link.  Goodness gracious, TAL did it commercially going
on 15 years ago!  Simple 2 port routers are cheap!

Also, we have seen a long history here of problems with inter-layer
interactions -- multimedia bridges, L2TP, PPPoE, etc, etc.

Something close to the original warning is required:

   The PPP Extensions Working Group (pppext) has reservations about
   the desirability of the feature described in this document.  In
   particular, it solves a general problem at an inappropriate layer
   and it may have unpredictable interactions with higher and lower
   level protocols.  The consensus of the working group is that
   implementors would be better advised either to seek ways of making
   the underlying radio link suitable for general Ethernet-like use, or
   to abandon the incomplete emulation of Ethernet entirely.

-- 
William Allen Simpson
     Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: James Carlson <[email-masked]>
Date: Fri, 9 Dec 2005 08:17:57 -0500

> environment is a part of the specification, not a WG warning about the

I had intended to integrate that text into the previous warning, not
replace, and was just word-smithing the subset to get the commentary
on the original usage case right.  Something like this:

  "The PPP Extensions Working Group (pppext) has reservations about
  the desirability of the feature described in this document.  In
  particular, it solves a general problem at an inappropriate layer
  and it may have unpredictable interactions with higher and lower
  level protocols.  The techniques described in this document are
  intended for use with a particular deployment technique that uses a
  PPP termination separated from a radio termination by an Ethernet,
  and that has radio-side flow control for a slower PPP-only link to
  remote nodes.  Implementors are better advised to avoid split
  termination and use traditional IP routing instead."

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: Karl Fox <[email-masked]>
Date: Fri, 9 Dec 2005 08:24:34 -0500

Welcome back, Bill!  It's nice to have one of the voices of reason  
and wisdom back in our group.

This group, and the IETF in general, tend to be divided into two  
camps: those who remember the IETF's original purpose and strongly  
advocate clean designs and proven interoperability, and those who  
strongly advocate a conclusion decided in advance by a vendor or a  
group of vendors.

We are supposed to be protocol designers to the world, not a rubber  
stamp for companies who want an official-looking Band-Aid (tm) to fix  
their badly designed product.  That's why PPPoE is not standards  
track, and that's why the latest "patch" (to undo a foolish choice  
made by the original gang of companies) is also not standards track.

Let me cite an example from the dim, dark past:  In 1997, Bill sent a  
message to this list describing a certain company that had sold  
inexpensive routers with a bug in the FCS calculation on PPP links.   
They originally wanted everyone to recognize them as a special case  
(sound familiar?), seeing as how they had already fielded a large  
number of units.  But Bill and the group held firm, and they fixed  
their broken units.

Broken.  Yes, I said broken.  PPPoE is broken.  A PPP-over-Ethernet- 
over-radio design that needs new options to work properly is, by  
definition, also broken.  Broken because the designers designed their  
product improperly.  And now they want us to accept their broken  
design as OK by standardizing it.

Design your products properly and you won't need all these broken  
options.  Listen to experienced (and smart!) people like Bill  
Simpson, Vern Schryver and Jim Carlson and your products will work  
better without all the cruft.

Karl

P.S. My copy of "How to Win Friends and Influence People" lies on a  
shelf at home, gathering dust, never cracked.  Sorry about that!

---

From: Karl Fox <[email-masked]>
Date: Fri, 9 Dec 2005 08:32:30 -0500

Can't we work the work "broken" in there somehow?

:-)

Karl

---

From: James Carlson <[email-masked]>
Date: Fri, 9 Dec 2005 09:19:01 -0500

> design as OK by standardizing it.

Agreed; the whole thing is swilly.

However, I disagree with that last bit.  The only intent here is to
publish as Informational (not Standards Track), and to make sure it's
specified to be minimally harmful.

In an ideal world, we would have been able to argue the authors away
from this split-termination design.  There wouldn't have been any
issue here at all, and no draft to write.  However, we haven't quite
managed to do that, and they've asked the IESG to publish.

In an ideal world, the IETF wouldn't have a vanity press feature such
as Informational.  Instead, we'd just tell people working on things
that are tangential (or inimical) to our agreed-on technical direction
to go find or form another standards body.  However, the IETF does
have this feature, and we've got some built-in limits to what we can
stop.

I agree it's not pretty, but I think we're getting the best of world
that we can have.  The authors were directed here to get input from
folks who know these protocols, even though they were under little
obligation to do so.  They got the input and may be mostly
disregarding it, but at least the resulting document will have an
appropriate warning.

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 9 Dec 2005 08:50:18 -0700 (MST)

> From: James Carlson <[email-masked]>

> specified to be minimally harmful.

Let's be honest with ourselves.  If the difference between "Informational"
and "Standards Track" were real, there would be no need to add the
deprecating text to this proposal.  The intent is for the IETF to OK
or standardize the proposal exactly as much as PPPoE was OK'ed or
standardized by the IETF.  Some original advocates of PPPoE as well as
some advocates of this notion have doubtless convinced themselves that
there is a difference between the status as a standard of RFC 2516 or
this proposal and RFC 793, but that difference is imperceptable to all
implementors, buyers, installers, maintainers, and users.

Let's also admit that, as the stronger title and words in RFC 1055
proved, the suggested deprecating words for this proposal will have very
little and probably no effect on implementors, buyers, etc.
These deprecating words can only salvage a little of the self-respect
of all of use including advocates for the idea and warn off advocates
of worse ideas such as the recent proposal concerning quantum mechanics.
The words might at most affect the IETF itself, much as the deprecating
words in RFC 1055 built momentum for PPP.

Vernon Schryver    [email-masked]

---

From: Karl Fox <[email-masked]>
Date: Fri, 9 Dec 2005 11:13:25 -0500

Frankly, I agree with Vern.  Why can't the WG simply tell the IESG  
that it's a bad idea because the need is based on a defective product  
design?  Surely they'd understand that--they're protocol designers,  
too.  Who knows, maybe they'd say no, too.

Karl

---

From: James Carlson <[email-masked]>
Date: Fri, 9 Dec 2005 11:15:35 -0500

> deprecating text to this proposal.  The intent is for the IETF to OK

Yes, I'm an implementor, and I have certainly noticed that many
(though not exactly _all_; I think that's a bit of hyperbole)
customers, users, and other implementors ignore the overly subtle
distinction between Standards Track and the rest.

I even agree that ditching Informational as a failed experiment would
likely work out for the best.

That doesn't imply that this is really the right forum to redesign the
IETF/IESG process.  As long as that process exists, we might as well
respect it as best we can.

I agree that many people will breeze right past the Informational
warning as well as any text (no matter how clear) indicating that the
document shouldn't be viewed by anyone ... ever.[1]  Just the same, as
long as publishing is going to happen no matter what we say here, I
think we're in a better place with the text than without.

Again, as an implementor, I like being able to say to a customer,
"gee, did you notice the warning message?  That's why I'm just not
going to put a high priority on fixing your bug.  Pony up some serious
cash or just go away."  ;-}

[1] Apologies to Trey Parker for stealing^Wborrowing that phrase.

---

From: Bo Berry <[email-masked]>
Date: Fri, 09 Dec 2005 11:27:07 -0500

Well, we do agree on one point, this is silly.

Guess it would not be unexpected to say that we disagree
with the text and addition of the disclaimer.  It appears
from these emails (and from emails of past as well), that
there is a lot of disagreement on PPPoE.  We're not
trying to to correct PPPoE.  We're not here to debate the
process and value of IETF Informational specs.

We have proposed and documented extenstions to the PPPoE
spec, which are within the context of that spec.  These
are documented as optional.

The draft went through the IETF process and has gone through
the expert review period. At this point we can agree to
disagree.  Therefore we request that the draft be published
as is, without any inserted (bias) text, and without any
further delay.

Sincerely
-Bo Berry

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 9 Dec 2005 09:28:19 -0700 (MST)

> From: Karl Fox <[email-masked]>

> too.  Who knows, maybe they'd say no, too.

I see reasons not to tell the IESG "No":

 - The IESG might refuse to go along, which would encourage more results
    like PPPoE itself.  (I have no recollections of debate about PPPoE
    here.  Am I wrong in thinking it bypassed this WG?)

 - If the IESG went along, the idea would be published in some
    "PPPoE Forum" as the best thing since sliced bread and without any
    caveats, and perhaps even without the improvements that have been
    made to it here.

 - We should save our very limited power to say "No" and mean it
    for worse things.

---

From: Karl Fox <[email-masked]>
Date: Fri, 9 Dec 2005 11:41:56 -0500

Yes, it did do an end run around PPPEXT, but since then I've seen  
more hints that the IESG might be willing to listen to the WG as  
expert on the topic and act accordingly.  I say we ask them to nix  
the whole thing, and come back to us for text mods if they disagree.

Why can't the company just fix their design?

Karl

---

From: James Carlson <[email-masked]>
Date: Fri, 9 Dec 2005 11:55:38 -0500

>     here.  Am I wrong in thinking it bypassed this WG?)

There've been on-and-off discussions for many years.  Back in 1992,
there was a discussion about doing just this.

The first mention of PPP over Ethernet "as we know it" that I can find
on this list was from Luca Fantolino back in July 1997.  Uri Shabi
(and many others) told him that L2F, PPTP, and L2TP were good ways to
do this.

It popped up again as a draft notice in August 1998, but there was no
discussion about it at all until December 1998, and even then no
substantive discussion of why it was all a mistake.

I don't think it bypassed the WG.  It was even on the agenda for the
44th IETF.  I do think there just wasn't much in the way of
discussion, and was just published as Informational.

>  - We should save our very limited power to say "No" and mean it

Indeed.

---

From: Mark Lanzo <[email-masked]>
Date: Fri, 9 Dec 2005 11:57:12 -0500 (EST)

> on 15 years ago!  Simple 2 port routers are cheap!

Hmm ... but this does not address the problem; it is not the issue.

The issue is that the routers have to _connect_ to the radios
somehow.  The radios aren't integral to the router; the radios and 
router aren't even made by the same company.  Ignoring the proposed 
extensions here, the router is a perfectly ordinary router; it doesn't 
know anything about radios or radio links in particular.  The desired 
goal is that the router be able to establish ordinary PPP sessions to 
remote peers, and be none the wiser about the media between itself
and its peers.  

In this particular instance, the router has a plain old ethernet port on 
it.  So do the radios in question.  The radios aren't integral to the
router, but the desire is make the radios look somewhat as if they were.
So the ethernet is being used as the "backplace" for connecting radios
to router.  -Some- sort of protocol is needed, to allow both for exchange 
of ordinary data and out-of-band information such as congestion conditions 
on the radio.  Some way to emulate a system where radios were plugged into
the router's bus and could appear more like local serial ports.

A whole new protocol could have been devised for the purpose; however, it was
recognized that with relatively minor modifications, PPPoE (which the router
in question already supports) could be adapted to be this "backplane" protocol.
The interesting thing here is that there is not really any "PPP" in this at 
all - it is actually irrelevant that the payloads which will eventually
be traded between radio and router for over-the-air transmission be PPP
packets.  It is the out-of-band signalling capabilities, not the in-band
data, which is the aspect of interest here.  The name "PPPoE" seems an
unfortunate choice, both because PPP wasn't the real point and because 
PPPoE is already a sore subject with many folk.

Meanwhile, I believe it was thought that not reinventing the wheel, and 
trying to have a published standard which radio manufacturers and router
vendors could agree to use for interconnecting their equipment, would be 
a Good Thing.  Is there some other protocol out there already, which is a
better choice [especially one whose very mention won't automatically 
trigger a knee-jerk negative reflexive action]?

Note please that I am writing merely as an interested party and am not 
part of the group submitting the proposal, nor am I trying to endorse
the proposal in any particular way.  I have talked to that group though,
and I have read the dialogs on this list, and I think that there is a 
bit of a disconnect, and that the group in question is suffering from
the unfortunate backlash that results from association with a protocol
that historically is not well-received. 

Would it help if the proposal began with a clearer explanation that 
although it "extends" PPPoE, that the usage is not in fact for PPPoE
as traditionally recognized, but instead is being used as a protocol
for using an ethernet as a backplace for communicating with external
serial-port "concentrators"?  Is there a different RFC this group 
should be looking at, which already provides just this sort of thing?

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 9 Dec 2005 10:01:46 -0700 (MST)

> Yes, it did do an end run around PPPEXT, 

I think I'd rather have been told I was wrong about about that.

>                                          but since then I've seen  

Are you sure that the PPPoE end-run was not the result of a perception
of PPPEXT as obstructionist?

> Why can't the company just fix their design?

because they won't fix their design.
Even if you doubt the literal accuracy of the comments about umptygazillion
units already installed, you must take them as indications of flexibility.

The most and best the IETF can do is refuse to allow the draft to be
withdrawn and insist that it be published with what have been called
biased words.

This is clearly not the place to debate fixing the IETF.
If it were, I'd point out that the IETF was built on the publication
of RFCs and that those Requests For Comments were just that.
The last 20 years have demonstrated that the IETF is, like every
bureaucracy or committee system, almost purely political and incapable
of self-discipline.
Therefore perhaps the best course for the IETF would be more willingness
to publish good and bad ideas, but with evaluations.
Or perhaps not.

---

From: James Carlson <[email-masked]>
Date: Fri, 9 Dec 2005 12:04:01 -0500

> there is a lot of disagreement on PPPoE.  We're not

Indeed, but that's not the point at all.  PPPoE isn't actually needed
to solve the problem here.

> process and value of IETF Informational specs.

Nor are we.

> are documented as optional.

"Optional" does not mean "without cost" or "quality is unimportant" or
even "I get to publish without addressing issues from reviewers."

> as is, without any inserted (bias) text, and without any

Sorry, but that's not the way it's going to happen.  You don't own
this particular vanity press.

The IESG intends to publish the document with a suitable warning to
summarize that there is no consensus that this protocol addition is a
good idea.  This could have happened without input from any of us; the
process allows that (see section 4.2.3 of RFC 2026 if you're
unfamiliar with the process).  Our AD politely asked for input, and I
suggested taking it to the list because I wasn't one of the principals
involved in the original discussion, and I wanted to capture the
problem accurately and succinctly.

I believe we've managed to do that.

If you want it published without "bias," then I suggest that you
withdraw the request to publish and use your own press instead.

---

From: James Carlson <[email-masked]>
Date: Fri, 9 Dec 2005 12:19:53 -0500

> Hmm ... but this does not address the problem; it is not the issue.

Actually, it is exactly the issue.

> router aren't even made by the same company.

This is the part that's completely broken.

You're implicitly assuming that the device labeled "radio" is able to
implement Ethernet and PPPoE, and be modified to accept this new PPPoE
feature, and that you can modify the box labeled "router" accordingly,
but that it is impossible to terminate PPP or route IP in the "radio,"
and that device couldn't possibly manage to do the work without having
an external router as a crutch.  Why is that?

The answer likely revolves around some notion of what's "too hard" or
"too expensive" to implement in a small embedded system.  Assuming
that's the case, it's easy to reject the proposal on the grounds that
designing protocols based around today's hardware limitations is both
short-sighted and without merit.

("Without merit" because by the time you actually get all this stuff
deployed and widely interoperable, the original problem is long since
forgotten.)

> trigger a knee-jerk negative reflexive action]?

Yes.  Terminate PPP in the device labeled "radio," and put plain old
IP on the Ethernet.

No new protocols required.

> should be looking at, which already provides just this sort of thing?

L2TP can do such a thing, but it's clearly, just like PPPoE, an
unnecessarily complex solution.

---

From: William Allen Simpson <[email-masked]>
Date: Sun, 11 Dec 2005 19:59:17 -0500

>   termination and use traditional IP routing instead."
OK.  I'd say "... split termination with inter-media protocol translation,
and use standard Internet Protocol routing instead."

Just so it's very clear that there's a box there doing work, probably
involves software, monitoring, passing packets between two interfaces
that require packet translation, and most other features of an INTER-net
router, but not actually meeting the router requirements.

After all, as the Cisco folks are saying, it's not "THE router" -- by
which they mean their expensive router, as opposed to the other vendor's
simpler box.

---

From: William Allen Simpson <[email-masked]>
Date: Sun, 11 Dec 2005 20:36:02 -0500

> should be looking at, which already provides just this sort of thing?
Ah yes, I remember when it was thought that implementing PPP was too
complex for a "serial port concentrator" until Telebit did it on a 286,
and then many other firms.  Took Cisco years to catch up.

And I remember when it was thought PPP was too complex for end user
terminal devices, until Vocal did it in a modem that could sit in the
palm of your hand, and Qualcomm did it in a cell phone (IIRC, both were
186 embedded processors with something like 4K RAM).  The Qualcomm
phones could run *2* PPP sessions, one over the radio link, and
another over the serial port to a laptop, _and_ emulate a fax/modem,
_and_ run simultaneous voice.

(Disclaimer: I helped design and implement all products mentioned above,
so I'm probably biased.)

You might look at EIA/TIA/CTIA IS-99, although it's probably not an
Interim Standard anymore (having written the thing circa 1993).  And
that also would still require modification to the radio....

Really, just because there are "dumb" ethernet-radio bridges doesn't
mean they're a good idea.  Especially in these days of cheap memory.
Caveat emptor.