Subject: RE: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt

From: "Paul W. Howard" <[email-masked]>
Date: Mon, 17 Oct 2005 14:50:49 -0400

Peter,

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.

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.

Thanx,

Paul Howard

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

---

From: "Peter Arberg" <[email-masked]>
Date: Tue, 18 Oct 2005 16:18:15 +0200

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.

> 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

---

From: "Paul W. Howard" <[email-masked]>
Date: Fri, 21 Oct 2005 16:55:53 -0400

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

---

From: "Peter Arberg" <[email-masked]>
Date: Wed, 26 Oct 2005 16:07:45 +0200

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

---

From: "Paul W. Howard" <[email-masked]>
Date: Wed, 26 Oct 2005 11:49:27 -0400

Peter,

Thanx.   I think this addresses my concerns.

Paul