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

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

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 preseent):

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

Thanx,

Paul Howard

Peter Arberg wrote:

>Hi Paul,
>
>answers inline.
> 
>
>  
>
>>I see a couple of items in the draft that are not what I 
>>expected given the notes I have from the DSL Forum meetings.
>>Can you comment on them?
>>
>>Sec 4, para 2 - Server responding with tag. As I recall, this 
>>was going to be simply an echo of the tag received from the 
>>client to confirm the 
>>ability to server to handle the tag from the client. The draft 
>>is unclear on this, but it could be read as the server is 
>>generating a tag value based on local knowledge instead of 
>>just echoing the client's tag.
>>    
>>
>
>correct, since the BRAS typical will be able to support any MRU,
>it will in real life proabably always be an echo of the 
>pppoe-clients tag.
>
>But I did not want to limit the draft, and say it must be an echo,
>because in the unlikely event that the pppoe-server do not support
>as high a maximum-MRU as the client suggest, the server now have 
>the option to reject the maximum-MRU (no tag included in PADO, PADS)
>or to include it's own tag value with a maximum-MRU it supports.
>
>
>  
>
>>Sec 5.1, para 5? - "If a MRU option is not sent...". As I recall, we 
>>were not going to re-define the meaning of the absence MRU option, 
>>rather leave it at the standard value of 1500. It seems that this 
>>paragraph attempts to redefine the meaning of the absence as 
>>either 1492 (if no PPP-MAX-PAYLOAD tag) or the value of the 
>>PPP-MAX-PAYLOAD tag if present.
>>    
>>
>
>
>No it was not the intention to redefine any default MRU value, it will
>be according to RFC1661, 1500 bytes, but this paragraph was simply to
>say if no tag received, then RFC 2516 defines a maximum MRU for 
>PPPoE sessions at 1492, and as such the maximum MRU will still be 1492.
>
>hope this make it more clear.
>Peter
>
>
>  
>
>>Thanx,
>>
>>Paul Howard
>>
>>
>>
>>    
>>
>
>
>  
>

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