RE: comment on draft-arberg-pppoe-mtu-gt1492-02.txt

On Fri, 25 Nov 2005, Peter Arberg wrote:

> It should have been "handle" instead of "accept".  We have seen 
> PPPoE clients negotiate MRU 1500, but can not handle packets 
> received with a payload of 1500.

Ah well. :)

> I agree RFC2516 could have been worded different, and we would not 
> have had this draft at all, but that's history and difficult to 
> change ;)

Indeed ;).

> I'm not sure what "backward-compatibility issues" you refer to,

Nor do I, but adding special-cases to protocols is what makes them 
progressively harder to revise. Hence, try avoid adding them unless 
required.

> but remember that the value in no way removes or changes the PPP 
> MRU negotiation, it is simply a out-of-band hint for the PPPoE 
> server to what MRU max value the client will be able to handle, but 
> the PPP negotiation will be used to agree on this.

It's more than a hint, it's a "MUST" for the server. Further, what 
happens if the client is also PPPoE?

 	client<----PPPoE---->DSLAM<-----<PPPoE>----BAS

The PPP session (and LCP MxU negotiation) is between the client and 
BAS, but the DSLAM handles the PPPoE session. What exactly is to 
happen here wrt the Max-Payload value? It's not specified is it?

What happens if the right of the BAS looks like:

 					BAS---<PPP/l2tp/IP>----ISP

Where the BAS is essentially just punting the PPP session on /again/ 
to another ISP (this is, sadly, how wholesale DSL via 
$incumbent_telco is provisioned in my country). The DSLAM may not 
have visibility of the MTU of this latter link (which might not be 
same size as the other).

I.e. To my mind, adding ability for intermediaries to inject a hint 
opens the following questions:

1. What should occur if there are multiple intermediaries able to add 
this hint?

The answer to that is probably not too tough (only ever allowed to 
reduce Max-Payload). But leads to:

2. What if some of the 'segments' are not PPPoE? (And hence, not able
    to 'forward' this Max-Payload tag)

That one seems more difficult. ;)

You could answer 2 with "well, operators will know in advance what 
the path MTU is and configure it statically", which is (if we assume 
PPPoE is acceptable) fine - but then why bother with putting the 
value in? Further, what if the 'client' also transposes the PPP 
connection from one transport to another? It gets messy really 
quickly imho.

If you specify a mechanism to dynamically insert path-MTU hints into 
this PPP wrapper protocol then, IMHO, you also need to deal with the 
weird and wonderful ways this hint could be used, abused and 
interact.

> I have no problem making the value optional, so if the Tag is used 
> with a 0-length data section, it will by default say a 1500 
> Max-Payload, but at the same time I do not see a need to change it 
> unless there is more people who see a problem using the value.

Well, see above for at least two problems with this value.

> It would be good to hear if anybody else on the list see a problem
> with the inclusion of the value in the PPPoE Tag.

We could turn the poll the other way around:

Does anyone think the tag should include the Max-Payload?

;)

regards,
-- 
Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
Fortune:
Cheese -- milk's leap toward immortality.
 		-- Clifton Fadiman, "Any Number Can Play"

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