> About MTU changes due to path changes, that is a problem > that needs to be dealt with in any case and not just the > map-and-encaps case. The two ways of detecting this are > to begin receiving packet-too-bigs when none were > received previously, or to proactively probe the path, > or both. (In the map-and-encaps case, sprite-mtu probing > can be used for proactive probing by the ITR.)
FWIW, some might suggest that another way to deal with this is to set DF=0 in all packets after the path has been probed and just let it fragment if an MTU restriction due to a path change occurs. But, RFC4963 presents some sobering insights as to why that would be a bad idea. Thanks - Fred [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
