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

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