RE: Re: Last Call: 'Accommodating an MTU/MRU greater than1492 in PPPoE' to Informational RFC
James Carlson <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Veera Tubati (vtubati) writes: > I wonder if draft should state its position about IPCP start while > MRU test is enabled. > > I would think IPCP start should be delayed (if this verification option > is enabled) till verification is finished and BRAS decides on MTU to be > used. Else, if there is a TCP session coming in soon after IPCP is up > and if verification process reduces the MTU later down to 1492 that TCP > session would be using a wrong MTU and would have connectivity problems. I don't see how that'd be helpful. If the MTU negotiated at LCP time later turns out to be a problem, you're going to need to restart LCP anyway, and that will tear down IPCP. So how does waiting help? At best it avoids a small bounce (IP goes up briefly, then down and back up again) in an unusual error case. And it's something that could be handled in a decent implementation by keeping track of the MAC address of the peer and remember the MTU limit. -- James Carlson, KISS Network <[email protected]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext