Iljitsch, > 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.
I assume you are talking here about the ETR's EMTU_R. RFC1122 couches EMTU_R in terms of the largest packet the node can *reassemble*, so it will presumably be at least as large as the largest packet the node can receive in one piece. Adding a means for the ITR to discover the ETR's EMTU_R is something I have proposed in numerous earlier efforts, and also something I have considered for sprite-mtu. But AFAICT, we really don't want the ETR to be reassembling fragmented outer packets any larger than 1500 bytes; instead, the ITR should send packets larger than 1500 bytes in one piece and/or send back a PTB if they are too big. So, IMHO all that needs to be known about the ETR is the binary as to whether it can reassemble up to 1500 bytes or not. If we say that all ETR's must be able to reassemble up to 2KB (enough to cover the 1500 byte packet plus any additional encapsulation overhead) then maybe there isn't all that much to be gained by an explicit EMTU_R discovery exchange? 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
