Re: Review of draft-bberry-pppoe-credit (Informational)

Bo Berry writes:
> > That makes the requirements even less clear to me.  If this device is
> > essentially doing routing with a mesh of point-to-point links, why
> > doesn't it actually behave as a router?  Why is it instead a PPP
> > bridge that exposes internal implementation details (the operation of
> > the radio link) to other Ethernet devices?  And why is it dependent on
> > the use of PPPoE outside of this domain?
> > 
> > If it were used with something other than IP+PPP+PPPoE (i.e., bridging
> > arbitrary LANs together, perhaps running some 'foreign' protocol such
> > as MPLS), what happens?  Does every Ethernet-based protocol need an
> > upgrade to handle credit-based flow control so that this radio link
> > will work correctly?
> 
> These extensions are optional and are not required by existing
> PPPoE implementations.  Systems that require flow control
> through (certain) radios could employ this solution.  We do
> not want the router to overrun the radio buffers, nor do we
> want the radio to overrun the router, hence the need for
> flow control (via credits).

I don't think that addresses the questions that have been raised.

First of all, "not required" doesn't match reality.  Either this is an
important niche for someone, and thus needs a solution like that
proposed in the draft, and thus will also force *many* vendors to
support it in their offerings (or suffer the consequences of inducing
very poor performance), _OR_ it's unimportant and doesn't need
solution.

Merely saying it's an "option" doesn't help if what's being specified
is something that (effectively) everyone is forced to implement.  What
I don't see is a rationale for why this feature would actually be
useful for others outside of this domain (some sort of redeeming path
forward) or something that constrains it to just a subset of equipment
vendors who all support this one market and never talk to anyone else.

Secondly, the question I asked above wasn't whether there was a need
for flow control, but rather what happens to protocols that are *not*
based on PPPoE.  In other words, this sounds like a very general
problem with Ethernet bridging in this particular device, but the
solution is an extension to PPPoE and not to any other Ethernet-based
protocol.  Does this mean that PPPoE becomes the only feasible
solution here, and is that really the right path forward for something
that otherwise appears to the rest of the network to be a bridge?

What stops some other Ethernet-based protocol from overrunning the
"router?"

Finally, why does this device just bridge PPP rather than route
packets?  What's wrong with routing?

-- 
James Carlson, KISS Network                    <[email protected]>
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 protected]
https://www1.ietf.org/mailman/listinfo/pppext