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

Vernon,

thanks for the feedback, I have included comments/answers inline
in the email.

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

that's good.


> 
> 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."

Agree, I used wrong names, and will correct it. You are correct where
I say Edge Aggregation Router, it is the same as the BRAS

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

Agree, again wrong use of names, I will make sure to update it to say
CPE equipment. The DSL router term is used instead of CPE or RG in the
document.

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

No it is suppose to show 1 PPP session here.

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

Fig. 3 is suppose to illustrate the situation where customer equipment,
either a CPE or a PC is a PPPoA host, but the BRAS is a PPPoE
access concentrator.

Many PPPoA hosts deployed today will not allow a MRU negotiation
less than 1500, and since in this diagram the DSLAM is a "media"
converter, converting the PPPoA session to a PPPoE session, the
way it is doing this, is when it sees a PPPoA session setup (conf. req.)
the DSLAM will initiate a PPPoE discovery state towards the BRAS, and
as such the BRAS now is in RFC2516 land, and will restrict the MRU/MTU
to 1492 bytes.

As soon as the PPPoE discovery state initiated by the DSLAM is done,
the DSLAM will forward the lcp confreq and then pass through all PPP
control packets in both directions between the customer equipment 
(CPE or PC) and the BRAS. As such 1 PPP session end-2-end is running, 
but if MRU has not been negotiated they will have different views of 
the world since it is a PPPoA host and a PPPoE access concentrator.  

If MRU is negotiated the session will proabably end up being dropped 
since they can't agree on the MRU negotiation.


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

There is only 1 session

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

Not sure I follow you.  The PPP state machine in the DSLAM is not
really existing, all the DSLAM is doing is initiate a PPPoE discovery 
state when a PPP host  sends a LCP conf.req. and as soon as the
PPPoE discover statge is done, it will forward the conf.req. after
this the DSLAM's PPP involvement is done, and it will forward all 
ppp control packets.

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

Agree the picture could be divided into 2, one where fragmentation
for sure could be an issue, and one where PPP session setup might
not be able to happen.  I simply combined it into one picture since
the idea is to show that problems can exist in a setup where
a DSLA is working as a PPPoA/oE translation.



> 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."

Good comment, I will make sure to change the client to host since I
wrongly use client for both a PPPoA as well as a PPPoE host. The
PPPoE server I can either put into terminology, or simply change to 
access concentrator (bras), since client-server is defined in RFC2516, 
and as such I did not see a need to define it again.

--- RFC 2516 snip ----
While PPP defines a peer-to-peer relationship, Discovery is inherently 
a client-server relationship.  In the Discovery process, a Host (the client)
discovers an Access Concentrator (the server)
-----------------------

thanks for your comments.
Peter


> 
> 
> 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