Re: MTU handling and 2461bis
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MTU handling and 2461bis



Those interested should perhaps have a look at:

 http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-01.txt

before responding to Hesham's question. I am seeing in that
document some language that may place the bar for acceptance
quite high indeed if we were to adopt Hesham's choice # 2.

Thanks - Fred
ftemplin@iprg.nokia.com

Soliman Hesham wrote:

Folks,
I've been following this discussion and trying to understand
where people want to solve it. I'm writing my personal
conclusion here and please let me know if you disagree.

First there is the question of: is this worth solving?
and if it is, can it be entirely solved here or do we need to involved IEEE?
There seems to be different opinions here.
Without getting into the technical issues, which are discussed in detail, and assuming that people think it's
worth solving, we have two choices in terms of moving forward:

1. Add the MTU negotiation between two nodes in 2461 bis
2. Another spec can define those options

The impression I'm getting is that people are in favour of (2) above. I'm personally in favour of (2) as well.
This work seems significant enough to have its own spec. Also, it seems like it will take some time to work out
the details of this optimisation and get concensus
on the details.
So can we move forward based on this conclusion
and not put this in 2461bis ?

Thanks, Hesham

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.