Just to have disclosure for the current understanding of this out on the list, the full proposal is given below. LISP is used as the example RRG map-and-encaps architecture, but the same approach can be applied to any such scheme:
See comments inline. For full disclosure, I don't endorse this proposal.
2) Before the ITR knows whether the ITR->ETR tunnel pathMTU can handle original packets up to 1500 bytes, it sends 1500- original packets into the tunnel as either 1-fragment or 2-fragment packets of no more
So we are going to double the packets sent everywhere until we find out? This doesn't sound like a good idea to me.
4) While sending 2-fragment packets, the ITR sends 1500 byte sprite-mtu probes to the ETR. If it gets probe replies back, it can stop sending 2-fragment packets and begin sending 1-fragment packets. If the ITR subsequently gets a packet-too-big, it can resume sending 2-fragment packets and try probing again later.
This requires the ITR to keep state for each ETR. It doesn't do this now. This is a huge requirement on the ITR which I object to.
6) The ETR must reassemble any 2-fragment packets. It
This is a non-starter in router products unless you *force* software switching. And even if you *force* software switching, it's a great DOS attack against the buffer system of the router. Leave malicious out of the way. If a Google ETR is recieving from 100K places, you think the router can store 100K 1500-byte sized packet for any length of time (1-2 seconds).
reduce the memory required for reassembly buffers by actively discarding any reassemblies that appear to have no chance of completion. This assumes that any
And how does the ETR determine there is no chance of completion? Please don't answer.
Dino -- 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
