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

"Peter Arberg" <[email protected]>
Newsgroups gmane.ietf.pppext
Organization Redback Networks
Message-ID <[email protected]>
Hi Paul,

I have answered your questions inline in the email.
 

> Hi,
> 
> I have a question about this draft:
> 
> Why would it not suffice to simply specify a "I can ignore the 
> RFC2516 1492 limit" tag in PADI and PADRs? Indeed, why do you even 
> need to signal this? :)

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.  

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.


> The problem, AIUI, is not a lack of a MTU-negotiation feature in PPP, 
> but just that limit. So all that needs to be signalled is the removal 
> of that limit, rather than an additional MxU value - if it even needs 
> to be signalled seperately..

Correct, this is simply a message from the PPPoE client that it can 
handle a PPP MRU negotiation upto limit-value.


> Signalling an additional value seems to complicate things to my mind, 
> further it raises questions about exactly what it represents (ie the 
> MxU of which underlying link exactly?) and who should be setting it 
> (the DSLAM, the BAS? What if both want to set it?).

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.

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.

cheers,
Peter



> 
> regards,
> -- 
> Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
> Fortune:
> The last thing one knows in constructing a work is what to put first.
>    		-- Blaise Pascal
> 
> _______________________________________________
> Pppext mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pppext
> 



_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.