Re: draft-arberg-pppoe-mtu-gt1492-00

 Hi Vernon,

 The modem was never pppoe to begin with. The pppoe
 session will be initiated by the dslam when it receives
 the lcp confreq from the modem and will forward it
 to the bras (over pppoe) once the pppoe session gets
 established.

 When the dslam receives the lcp confack from the bras,
 it will strip the pppoe header and send it to the modem.
 The dslam is responsible for the vpi/vci to pppoe session-id
 mapping. As far as the modem is concerned, there is no pppoe
 segment in the network, unless the bras naks the 1500 mru
 down to 1492, as it would do today.

 Diamantis
 

Vernon Schryver wrote:

>>From: Diamantis Kourkouzelis <[email protected]>
>>    
>>
>
>  
>
>> What are your thoughts on figure 3 of the draft? The modem is pppoa,
>> the dslam initiates the pppoe connection (transparent to the modem)
>> and the bras accepts the 1500 mru requested by the modem (assuming
>> the port mtu on the bras can support at least 1508).
>>
>> How does that affect the user or impose any requirement for a modem
>> firmware upgrade? Any data being sent by the dslam towards the modem will
>> still be at 1500 max (pppoa).
>>    
>>
>
>What magic switches the customer premises equipment (CPE or end
>user DSL modem) from PPPoE to PPPoA?  How do you reach out and
>toggle switches in those bazillions of CPE that were just today
>mentioned as justifying this proposal without a problematic remote
>reconfiguration and reboot of zillions of CPE and probably a new
>firmware download to change the hold-reset-button-with-paper-clip
>default for the PPPoE/PPPoA switch?
>
>I wonder also how much market there would be for a protocol that would
>give providers more classes of customer, new DSLAM+CPE that likes PPPoA
>vs. old DSLAM+CPE that prefers PPPoE, merely so that some customers
>would have MTUs of 1500.
>
>However, as far as I'm concerned, switching the CPE-DSLAM link to PPPoA
>would amount to switching to from PPPoE to standard IP over PPP as far
>as the IETF is concerned.  The provider's internal, private links seem
>outside the perview of the IETF.  It strikes me as perverse to
>re-encapsulate perfectly good IP/.../ATM packets in and out of
>IP/.../PPPoE/.../ATM in the broadband remote access server (BRAS), but
>none of my business.  If a vendor has a wonderful SuperDuperUltra-
>WideBandSpreadSpectrum or other magic to move IP packets between a
>DSLAM and a service provider's routers, then great and why should the
>IETF interfere, give permission, or be involved at all?
>
>
>Vernon Schryver    [email protected]
>
>_______________________________________________
>Pppext mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/pppext
>  
>

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