RE: comment on draft-arberg-pppoe-mtu-gt1492-02.txt

 

> -----Original Message-----
> From: Paul Jakma [mailto:[email protected]] 
> Sent: 24. november 2005 15:14
> To: Peter Arberg
> Cc: [email protected]
> Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt
> 
> On Thu, 24 Nov 2005, Peter Arberg wrote:
> 
> > This was discussed initially, as it was also our first thinking, 
> > but for optimization purpose it was suggested to include the max. 
> > payload number as well.
> 
> I did try look over the previous discussions, I read the thread where 
> it was suggested to introduce new tags, I didn't see any discussion 
> of including a payload size though - never mind the rationale for 
> doing so.

sorry, should have said, discussed initially between co-authors and 
people in the ack. section..


> > The idea of the new option was to have the PPPoE client communicate 
> > in the PADI and PADR the maximum MTU/MRU it can deal with. Then the 
> > PPPoE server will have a good hint to immediately select a proper 
> > value for the MRU to propose in its LCP config_req. This would make 
> > the regular case more streamlined.
> 
> Right, I did read the RFC. ;)
> 
> It doesn't give any rationale for why it's a good idea to include a 
> "Max-Payload" value in the tag though.
> 
> > It was not the intention to complicate things, simply to make the 
> > negotiation more streamlined. And when the TAG had to be included, 
> > it did not seem like an issue to include the max MxU number.
> 
> It's an additional piece of state for:
> 
> a) implementations to have to track and hence get wrong
> 
> b) future refinements to have to bear in mind wrt
>     backward-compatibility.
> 
> Making it be just a "remove the RFC2561 limit" flag simply reduces 
> things back to normal PPP, at least wrt MRU/MTU negotiation.
> 
> > The number is only to be set by the PPPoE client side, never from 
> > the server (BRAS) side, the PPPoE server will echo the clients 
> > value back as a okay lets do PPP MRU negotiation to settle on a 
> > value.
> 
> Why can't the client just start doing MRU/MTU negotiation as part of 
> PPP setup, as it will have to do anyway? Why add an additional value 
> into the mix?

The problem is that not all PPP hosts do perform a MRU negotiation,
it is optional. And further more we also have seen PPPoE clients who
perform a MRU negotiation of 1500 but can not accept the value.

The PPPoE MRU Tag is intented for 2 purposes, the one is for "normal"
PPPoE clients who wish to negotiate a higher MRU, and as such this
is a way for the BRAS to know this is a new client and it is safe
to negotiate above 1492, all the way up to the Max-Payload value,
yes this could have been handled with out the value, with a simple
flag Tag, if we could be sure all clients will perform MRU negotiation.

The second case is the setup where a DSLAM will act as a PPPoA to oE
interworking device, and initiate the PPPoE discovery phase.
In this case the DSLAM knows we are dealing with a PPP(oA) host and as
such can send the Max-Payload value of 1500. Could this have been
handled with a simple flag Tag, yes I guess it could.

The problem is inbetween, I know it is proabably not a real life
situation, but you never know, if a "normal" PPPoE client can
handle higher than 1492, but can not handle 1500 ?? agree sounds
far out, this case could not be handled without the value in
the Tag, as long as you not know for sure that the client will
perform a MRU negotiation, and many don't.

So as far as I remember, this was the reason along with the fact
to streamline the MRU negotiation, where the BRAS knows what
value to suggest in the initial MRU negotiation so it do not
have to go back and forth, it was an intention to help speed 
up the negotiation.

And then we never saw it as a problem to include the value, and
neither did any of the PPPoE client vendors we discussed it with,
agreeing to include a new PPPoE Tag was the biggest problem, the
value seemed a small topic compared to that.

cheers,
Peter



> 
> This Max-Payload value seems quite redundant.
> 
> regards,
> -- 
> Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
> Fortune:
> "The medium is the message."
> -- Marshall McLuhan
> 



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