Subject: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt

From: [email-masked]
Date: Thu, 13 Oct 2005 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title		: Accommodating an MTU/MRU greater than 1492 in PPPoE
	Author(s)	: P. Arberg, et al.
	Filename	: draft-arberg-pppoe-mtu-gt1492-01.txt
	Pages		: 7
	Date		: 2005-10-13
	
Point-to-Point Protocol Over Ethernet (PPPoE), as described in RFC
   2516 [1], mandates a maximum negotiated MRU of 1492. This document 
   outlines a solution to relax that restriction and allow a maximum 
   negotiated MRU greater than 1492 to minimize fragmentation in next 
   generation broadband networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-arberg-pppoe-mtu-gt1492-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-arberg-pppoe-mtu-gt1492-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Pppext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pppext

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 13 Oct 2005 18:47:09 -0600 (MDT)

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

---

From: "Peter Arberg" <[email-masked]>
Date: Thu, 13 Oct 2005 19:58:12 -0700

Vernon,

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

> is not the horror produced by the first version.

that's good.

> the "BRAS," which section 1 says means "Broadband Remote 

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

> 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 subscriber session is a PPP session running over a 
> combination of PPPoA and PPPoE. 
> 
>     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.

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

There is only 1 session

> 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

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.

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

> 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

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 13 Oct 2005 21:43:41 -0600 (MDT)

> From: "Peter Arberg" <[email-masked]>

> converter, converting the PPPoA session to a PPPoE session, the

All of that belongs in the draft, not least because it is not
exactly, precisely true that exactly 1 PPP session is involved.

> PPPoE discover statge is done, it will forward the conf.req. 

Is the configure-request potentially modified with the appropriate MRU?
If not, then I don't see any point in the PPPoE discovery. 
If so, then it is wrong to say that only 1 PPP session is involved.
Maybe fewer than 2 sessions, such as 1.2 sessions or 1 perverted/NAT-like
PPP session, but not one, real, clean, pure PPP session.