Re: I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt

Peter,

Thanx.   I think this addresses my concerns.

Paul

Peter Arberg wrote:

>Hi Paul,
>
>I have included some answers inline in your email, hope this
>will clarify the intention of the mentioned sections in the 
>draft.
>
>  
>
>>------------
>>Peter,
>>	
>>Thanx for your responses.   I think there is still some lack 
>>of clarity in this issues that needs to be addressed in the draft.
>>	
>>1) For the tag response (Sec 4, para 2).   We can't allow the 
>>server a choice in what it sends.   The draft needs to 
>>explicitly state that it either (a) sends back what it received 
>>(i.e. just a basic ack of support for the tag) or (b) sends 
>>back it's own max MRU (i.e. an ack of support for the tag and 
>>an indication of it's max MRU).   If we were to leave the draft 
>>as written, then the client upon receiving the tag would have no 
>>way to interpret the tag value in the situation where the server's 
>>max happens to be the same as the client's max - it can not tell 
>>whether it's just an ack (i.e. choice (a)) or an ack and an indicaiton 
>>of the server's max (i.e. choice (b)).   Thus it would seem that we 
>>must pick one of these two definitions for the tag value. 
>>	 
>>Further, it would seem that in a situation where the column is dynamic, 
>>then the PPP interface likely doesn't exist at the time the tag must 
>>be transmitted by the server.   As such, requiring the server to respond 
>>with choice (b) seems problematic as an accurate determination of the 
>>true max MRU may be impossible at this point.    Given this and the 
>>fact that there isn't any real value to reporting the server's max MRU 
>>at this time (it's going to be reported during PPP negotiation), then 
>>it would seem the draft should specify choice (a).
>>    
>>
>
>
>I agree on your point, and I will update the draft to specific say that
>the BRAS, PPPoE server will echo back the clients pppoe-tag if the
>server support a MRU negotiation greater than 1492.
>
>As I see it now, it will be easier and still support all options if 
>we do as you suggest, so in short:
> 1. pppoe client include "maximum-payload" tag
> 2. pppoe server will echo the "maximum-payload" tag if it supports
>    larger than 1492 bytes MRU.
> 3. pppoe server will not include tag in PADO and PADS response if
>    pppoe server do not support the greater than 1492 MRU.
> 4. the value send/received in pppoe tag will be used as the possible
>    maximum-payload when setting MTU and negotiating MRU.
>
>
>
>  
>
>>2) On the missing MRU option (Sec 5.1, para 5).   I think this 
>>paragraph clearly attempts to redefine the meaning of the "default" 
>>MRU (i.e. the value of the MRU when the option is not present):
>>
>>"If a MRU option is not sent by one end of the PPP negotiation, a  
>>maximum MRU size of 1492 bytes MUST be assumed and used, unless the 
>>PPP-Max-Payload tag was present in the PPPoE Discovery Stage, in 
>>which case this value MUST be used as the maximum MRU value.".
>>
>>It seems to be extremely inadvisable to change the meaning of a 
>>missing PPP LCP option.   If the MRU option is not sent, then PPP 
>>must use its current behavior regardless of whether or not the 
>>PPPoE tag was present.   Thus when the PPP MRU option is missing, 
>>the MRU is assumed to be 1500 octets (per the PPP RFC) regardless 
>>of the underlying layers.   It would be a very bad idea to assume 
>>a higher MRU just because this tag was present in the PPPoE packets 
>>since the client has not given permission to use a value greater 
>>than 1500.
>>    
>>
>
>I actually did not intended to change the default MRU, but I can
>reword it in the next version, if this wording is causing confusion.
>
>The intention is the following:
>1. when a "maximum-payload" tag is received, 
> a. then the value in this tag will indicate the maximum allowed 
>    MRU to accept and suggest in a MRU negotiation, 
> b. if MRU is not negotiated then RFC1661 will set the default 
>    MRU at 1500
> c. so this will say that the maximum-payload tag can have a greater
>    value than 1500, but in this case RFC1661 sets default MRU = 1500, 
>    and only if MRU is negotiated higher (up to maximum-payload) will
>    it be used.
>
>2. when a "maximum-payload" tag is not received by either end,
>   then RFC2516 sets the rule.
>
>If we can agree that this should be the intended behavior, then 
>I will try and reword the section, and maybe you can proof read it ?
>
>thanks,
>Peter
> 
>
>
>  
>

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