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

> http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-01.txt

I'm not sure what I think of the new version of this proposal, because
I'm somewhat confused by the text.  The text may be much better and I
may have a much better understanding, because my intuitive reaction
is not the horror produced by the first version.


Page 3 says:

    In the network design shown in figure 2, fragmentation becomes a 
    major problem since the subscriber session is a combination of
    IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes.
    However, when the Residential Gateway and the Edge Aggregation 
    Router are the PPPoE session endpoints, and therefore negotiate
    a MTU/MRU of 1492 bytes resulting in a large number of fragmented
    packets in the network.

I cannot find "Edge Aggregation Router" in Figure 2.  Perhaps it is
the "BRAS," which section 1 says means "Broadband Remote Access Server."

There are similar problems on the bottom of page 3 which talks about
"DSL Routers " without saying whether they are "CPE", "RG", "BRAS,"
or something else.  Then there is whatever a "PPPoE server" might be.


The last paragraph contains what I suspect is an incorrect statement:

    The subscriber session is a PPP session running over a combination 
    of PPPoA and PPPoE. 

I suspect it should say something like

    The subscriber session is a ***pair of*** PPP sessions running over
    a combination of PPPoA and PPPoE. 

The difference is significant because of the number of PPP state machines
involved and so what might be practical.  If a single PPP session is
involved, then there is no fragmentation problem in the second network
diagrammed in Figure 3, because it is the same as the network in Figure
1.  If there are two PPP sessions in the second network in Figure 3,
why is there fragmentation problem?  The PPP state machine in the BRAS
can ask for and get presumably both MTU and MRU of 1492 from PPP state
machine in the PC.

If there are two PPP sessions as the diagram suggests, then the PPP
state machine in the DSLAM can anticipate the need for 1492 and ask for
and get 1492 MRU and MTU.  However, maybe that is the point of the third
paragraphs on page 4.  If so, that text needs to be improved.  Does
that third paragraph conflict with the first and second?--I think so.
Perhaps the first two paragraphs could be moved to after the current
third paragraph.

Perhaps Figure 3 should be divided into 2 figures.  One would be the
first network, where something might need to be done to prevent IP
fragmentation.  The other would be the second network where nothing
but common sense is needed.

The fourth paragraph on page 4 and section 4 need to define terms
including "PPPoE client" and "PPPoE server."  It is not clear to me 
whether the text is confused about the fact the PPP world there are
no such things as "servers" or "clients" or it is following RFC 2516.
Section 3 of RFC 2516 defines "a Host (the client)" and "an Access
Concentrator (the server)."  If those notions are intended in this
document, then perhaps it should use those terms instead of inventing
new terms.  It should at elast related them to the boxes defined in
this document such as "PC", "DSLAM", and "BRAS."


Vernon Schryver    [email protected]

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