[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-dasilva-l2tp-relaysvc-06.txt
Randy Bush <randy@psg.com> writes:
> Yes No-Objection Discuss * Abstain
> Randy Bush [ ] [ ] [ x ] [ ]
> yes, i know i used to be a no-ob. but an ops-dir reviewer wants
> to point out the appended.
> randy
> ---
> Can you have a standards-track document based which in some sense
> extends and support a protocol (PPPoE) that's documented as an
> Informational RFC?
Of course. Does anyone thing otherwise?
I.e., can DHCP carry options for proprietary things? Do routing
protocol also support non-standards track usages? Etc.
> I'll repeat a comment I made on the L2TP list (I think) months (a year?)
> ago about some other attempt to extend PPPoE. How about someone work
> on L2TP on Ethernet MAC? It was the absense of this particular combination
> which prompted the work to produce PPPoE in the first place. I can see
> the irresistable urge to make use of the extensibility of L2TP to make
> just about anything possible, but there may be a more sound solution
> by just "doing" L2TP on Ethernet and getting it out there starting
> adoption. A moderately clever implementation could even support both
> protocol on the same port for transition.
This document is about an extension to l2tp that solves a real
problem. I'm not sure what the above is getting at. We should drop
this work and do something else that is a better fix to pppoe? Been
there, tried that. pppoe is out there, and is broken. It can't be
fixed without a major overhaul that is not backwards compatable. I
detect no interest in doing this (some folks tried to have a BOF on
this general topic, but there really wasn't consensus/interest to do
this).
> PPPoE was one of those 80%/20% sort of things; never intended to solve
> all the worlds problems. This, of course, hasn't stopped people from
> trying.
So, I view the above as interesting commentary, but largely orthogonal
to whether this document should go forward.
Thomas