RE: Re: Last Call: 'Accommodating an MTU/MRU greater than1492in PPPoE' to Informational RFC

I agree a boolean flag could as well have been used, but the initial
suggestion was for a value to set a hint for the max value the client
would be asking for, I also see no problem in this value.

I do think based on recent discussions that a little more precise 
pseudo code is needed, to make the pseudo code in line with the
tag description, that it's value is only a maximum hint if it's greater
than 1492, if for some strange reasons a client send a tag value
less than 1492 (don't ask me why it would ;) then the BRAS should
ignore the value and allow the MRU negotiation of upto 1492.

Also for the echo test, the recommendation ended up like it is, 
because the carrier feedback was they know their network, and as 
such do not expect major problems if/when they would enable the
new capability. It is the intend of the text that this is an adhoc 
test which can be performed by an administrator upon connectivity problems.

It will without a doubt make the solution more robust if the echo test
was performed upon setup, and we could change the recommendation to not
specific say this capability SHOULD be disabled, so changing it from
---
   This capability SHOULD be disabled by default, and SHOULD only be
   available for debug, test purpose.
---

to something like this:

---
   This capability MAY be disabled by default, but SHOULD be
   available for debug, test purpose.
---

if you think that will make it a little better.

cheers,
Peter




> -----Original Message-----
> From: James Carlson [mailto:[email protected]] 
> Sent: 21. februar 2006 08:16
> To: Veera Tubati (vtubati)
> Cc: [email protected]; [email protected]; Pekka Savola; [email protected]
> Subject: RE: [Pppext] Re: Last Call: 'Accommodating an 
> MTU/MRU greater than1492in PPPoE' to Informational RFC
> 
> Veera Tubati (vtubati) writes:
> > > I don't quite understand, but it sounds to me like a 
> design issue for
> > > the BRAS and not a protocol issue.  If it wants, that 
> machine could
> > > sequence the link bring-up so that it spreads out the load, or it
> > > could just use a more capable hardware platform.
> > 
> > It is clear that is not an issue with the protocol, but 
> seems there are
> > practical reasons which pushed for the birth of this draft.
> 
> That seems unrelated to the potential performance issue I thought we
> were discussing.
> 
> In any event, the draft authors wanted explicit signaling because of
> the behavior of the existing PPPoE implementations.  There's little
> way to be _sure_ you're talking to a new one without checking.  (I
> think a boolean would be sufficient for that, but I see no problem
> with having an integer value instead.)
> 
> -- 
> 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
> 



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