> Will the NVO3 dataplane protocols have mechanisms to detect loss, so > they can actually do RFC4821?
That would definitely be worth calling out; I'll see about writing some text ... in my "copious spare time" ;-). > (I've often seen 4821 cited alongside 1981, because people think it's > a drop-in replacement when it isn't.) Some of the dataplane protocols under consideration do not have that ability, and in addition, there's a strong tendency in nvo3 to shove this problem up the stack, i.e., expect the applications using the overlay to do their own MTU discovery. Thanks, --David > -----Original Message----- > From: Eggert, Lars [mailto:[email protected]] > Sent: Thursday, May 15, 2014 3:38 AM > To: Black, David > Cc: [email protected]; [email protected] > Subject: Re: [tsvwg] Fragmentation and Path MTU text in nvo3 dataplane reqts > draft > > Hi, > > On 2014-5-14, at 22:52, Black, David <[email protected]> wrote: > > o Classical ICMP-based MTU Path Discovery [RFC1191] [RFC1981] or > > Extended MTU Path Discovery techniques such as defined in > > [RFC4821] > > Will the NVO3 dataplane protocols have mechanisms to detect loss, so they can > actually do RFC4821? > > (I've often seen 4821 cited alongside 1981, because people think it's a drop- > in replacement when it isn't.) > > Lars
