On Thu, 10 May 2018, Aaron Falk wrote:
Please read the draft and send comments to the list. This document is planned to be an Informational RFC. Statements along the lines of 'ready to publish' are also welcome.
I've never read this document before, but read all the main body now. I did not read all of the appendices.
I did read A3.7 plus search for my pet peeve, which is trying to avoid IP level fragmentation in communication plus handling path MTU blackhole detection/mitigation.
It seems lots of what I was looking for is here. The main body (minus appendices) is easy to read and makes sense to me. I guess some details will be cleared up in a future document that actually specifies the APIs and how they would look. A3.7 at least gives possibility for applications to get PMTU information, that's great.
However, I couldn't find exactly how an application can be helped to determine the actual working PMTU by specifying some kind of probe packets that are devoid of actual "content", ie padded to max PMTU size? At least that would be understood by two TAPS systems for the protocols where this isn't already implementable in other ways (I imagine this can be done for SCTP and TCP without the application having to get much involved, but will be harder for UDP). So to implement some kind of "test if PMTU actually works" TAPS functionality?
I know I'm late in the game here and haven't followed TAPS closely, so something like this might already be in there, but it's decided to not go into the minimum requirements?
Anyhow, for a first-time reader, this document seems fine and nothing jumped out to me as being wrong in it (of the parts that I read).
-- Mikael Abrahamsson email: [email protected] _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
