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

James Carlson wrote:
> 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.

Sorry if I gave the impression that it is not important.
It is important, that's why it was submitted.


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

We're not requiring that this be required by those
outside the domain.

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

The radios we are currently working with require
flow control.  They are not radios that forward
any protocol.


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

Routing is envolved, but outside of the PPPoE session. For
example, if the radio link is poor, the router may choose
another route.


> 

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