Every interface that participates in an ISIS routing domain must be capable of transmitting packets at least as large as 1492 bytes. When sent over a GRE tunnel this means that the actual physical interface MTU has to support a minimum of 1516 bytes ( 1492 ISO + 24 GRE overhead ). Compare this to the default Ethernet MTU of 1500 and we come up 16 bytes short. Luckily this is a logical interface rather than a physical one and it is possible to simulate a larger MTU by relying on IP fragmentation to fit the GRE packet onto the lower MTU physical links.
With IP packets the fragmentation process is easy to understand. There is an IP MTU that can be manipulated on the GRE interface. This IP is used when formulating GRE packets. If the packets are too large then they will be fragmented before being encapsulated into GRE. If fragmentation is forbidden due to DF (Don't Fragment) bit being set then a ICMP MTU Exceeded message will be sent back to the source.
With ISIS packets the process isn't as clear. Unlike with IP, with ISIS packets all packets that will be sent over the tunnel are locally generated by the router itself. Further, the ISO MTU which can be set on the interface will be ignored. Setting it higher or lower has no effect on the tunnel, the GRE tunnel will always behave as if it had a MTU of 1492 set regardless of the current ISO MTU. Finally, the primary problem in fragmenting these packets is that the ISIS packet header does not permit for fragmentation. This creates a challenge when a 1492 byte ISIS packet needs to be sent over a GRE tunnel ( which adds 24 bytes of overhead ) over a 1500 byte physical interface.
The solution that JUNOS utilizes relies on fragmentation of the final GRE encapsulated IP packet. The ISIS packet is created by the Routing-Engine as expected and the full 1492 byte packet is encapsulated by a GRE header. The difference being that the DF ( Don't Fragment ) bit is not set on these packets. This is different from the normal behavior of GRE tunnels as every transit packet that is encapsulated within the tunnel will have it's DF bit set. The distinction is important as the lack of a set DF bit means that when the packet is sent by the RE to the PFE the PFE is now able to fragment this GRE packet into two separate packets which are capable of being sent over the physical interface. In this way it is possible to simulate the full 1492 minimum MTU that ISIS requires.
An interesting situation occurs when you have multiple GRE tunnels all egressing the same physical interface but a subset of these tunnels has a lower MTU. For example if you have a physical MTU of 4024 on your egress interface and most of your tunnels has an end to end MTU of 4000 yet one of your tunnels has an end to end MTU of 1476 ( due to networking devices in it's path that are incapable of supporting a higher MTU ). In this scenario, the packet will not be fragmented by the originating router as it is unaware of the lower MTU ( the only MTU that it can reference to determine if fragmentation is necessary is the outgoing physical MTU ). Due to this, it is necessary that the networking device directly attached to the lower MTU circuit be capable of fragmentation as it will be required to fragment the GRE encapsulated ISIS packet.