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

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