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

The value in this tag was not added just for convenience.

- While I am not going to defend it, it's possible to use jumbo-frames
larger than 1500 (as opposed to in-between 1492 and 1500).

- Additional negotiations and retries during LCP shouldn't be
trivialized.

- PPPoE has had a troubled history, partially due to assumptions that
were made by different implementations (MxU, retry behavior etc).  The
use of an unqualified flag runs the risk of continuing that trend,
either by placing assumptions on values or overloading the flag for
other purposes.

We are advocates of the specific value.

Tom
 
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Peter Arberg
Sent: Sunday, November 27, 2005 9:16 PM
To: 'Paul Jakma'
Cc: [email protected]
Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt

snip..

> 
>  	client<----PPPoE---->DSLAM<-----<PPPoE>----BAS
> 
> The PPP session (and LCP MxU negotiation) is between the client and 
> BAS, but the DSLAM handles the PPPoE session. What exactly is to 
> happen here wrt the Max-Payload value? It's not specified is it?

I do not understand your comment, the DSLAM handles the PPPoE session,
I think we have a slight misunderstanding here.

The DSLAM will not be involved in any native PPPoE sessions initiated
by a CPE equipment, and the Max-Payload Tag is only added by the 
PPPoE client who initiates the PPPoE discovery stage.

So in you picture the "client" adds the Max-Payload Tag value
and the DSLAM have no idea, and is not suppose to have any idea
of what is going on in a PPPoE session.

> 
> What happens if the right of the BAS looks like:
> 
>  					BAS---<PPP/l2tp/IP>----ISP
> 
> Where the BAS is essentially just punting the PPP session on /again/ 
> to another ISP (this is, sadly, how wholesale DSL via 
> $incumbent_telco is provisioned in my country). The DSLAM may not 
> have visibility of the MTU of this latter link (which might not be 
> same size as the other).

Yes this is a common PPP wholesale scenario, and the internet-draft
do not make any suggestions to how the PPPoE MTU hint should be
forwarded in the L2TP session.  We have had some multivendor
discussions on this with a few carriers, but the draft was not intended
to take care of this, as we initially wanted to make sure we could
increase the PPPoE MxU, and then another L2TP specific work can
take the next step and make sure to expand the work.

And yes we do have a suggestion to how this can be signaled in the
L2TP, but different place, different discussion.


> I.e. To my mind, adding ability for intermediaries to inject a hint 
> opens the following questions:

This is not intended, it is intended to be a client-server Tag only
no intermidiate systems should use/add or remove this tag.


> 1. What should occur if there are multiple intermediaries able to add 
> this hint?

They should not, this is only added by the client who initiates the 
PPPoE discovery phase, and used by/echoed back by the PPPoE server
who is the other peer in the PPPoE discovery phase.


> The answer to that is probably not too tough (only ever allowed to 
> reduce Max-Payload). But leads to:
> 
> 2. What if some of the 'segments' are not PPPoE? (And hence, not able
>     to 'forward' this Max-Payload tag)

again, the tag is not intended to take care of the underlying L2
MTU of the network, this is why we make the note:
---
   The procedure described in this document do not strictly conform 
   to IEEE standards for Ethernet packet size, but rely on a widely 
   deployed behavior of supporting jumbo frames on Ethernet segments.
---


> 
> That one seems more difficult. ;)
> 
> You could answer 2 with "well, operators will know in advance what 
> the path MTU is and configure it statically", which is (if we assume 
> PPPoE is acceptable) fine - but then why bother with putting the 
> value in? Further, what if the 'client' also transposes the PPP 
> connection from one transport to another? It gets messy really 
> quickly imho.
> 
> If you specify a mechanism to dynamically insert path-MTU hints into 
> this PPP wrapper protocol then, IMHO, you also need to deal with the 
> weird and wonderful ways this hint could be used, abused and 
> interact.

The Tag is a client-server information, not intended for any
intermediate
systems, this is not any different than any other PPPoE tag defined.


> > I have no problem making the value optional, so if the Tag is used 
> > with a 0-length data section, it will by default say a 1500 
> > Max-Payload, but at the same time I do not see a need to change it 
> > unless there is more people who see a problem using the value.
> 
> Well, see above for at least two problems with this value.
> 
> > It would be good to hear if anybody else on the list see a problem
> > with the inclusion of the value in the PPPoE Tag.
> 
> We could turn the poll the other way around:
> Does anyone think the tag should include the Max-Payload?

nice try, but read the draft again, as you can see at least 2 vendor
companies and 1 carrier are co-authors, in the ack. section several
other people from both vendor and carrier world is listed.

The draft have been presented on the DSL Forum meeting in Philadelphia
and no people objected to the value.

I have listed 2 major reasons why it was included, and there are
multi-vendor implementations today based on this suggestion in test
at carriers network.

I'm not saying this is a reason it should not be changed, I'm simply 
saying it shows that people have agreed to the suggestion, and we
need some real good reasons to change it, better than future
backward compatibility, and it seems more complicated than needed.

thanks,
Peter

> 
> ;)
> 
> regards,
> -- 
> Paul Jakma	[email protected]	[email protected]	Key ID: 64A2FF6A
> Fortune:
> Cheese -- milk's leap toward immortality.
>  		-- Clifton Fadiman, "Any Number Can Play"
> 



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

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