Excerpts from Eliot Lear at 11:53:33 +0100 on Mon 17 Dec 2007: > > The ETR receiving the packet sees the "please respond" message and > > sends back info to the originating ITR that could encompass > > current locator preference information (for traffic engineering), > > the up/down status of other ETRs, the maximum packet size the ETR > > is prepared to receive, possibly (if the ETR supports reassembly) > > the maximum packet size the ETR is prepared to reassemble from > > fragments. > > The ETR really only has its interface MTU. It doesn't look a whole > lot different than any other router. Again, I think this is a > general tunneling problem, and not something that is specific to > LISP. I do think the problem is worth considering in LISP's > context, but we should be thinking in more general terms when it > comes to solutions (e.g, L2TP, IPSEC, IP over HTTP, etc., etc.).
This is where I come to. (1) LISP itself cannot and should not keep track of path MTU; (2) whatever mechanisms we use for path MTU should work for all packets, whether crossing a LISP encap/decap point or not. -- 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
