Re: [Isis-wg] Fwd: New Version Notification for draft-franke-isis-over-ipv6-00.txt

[Christian Franke <[e-mail]>]

On 07/12/2015 02:40 PM, Karsten Thomann wrote:
>> One feature that this would allow though is indeed using fragmentation
>> which would permit to transport standard LSPs over IPv6 which may
>> otherwise be too large. 
> I don't understand this, as ISIS has an internal mechanism to handle LSPs which are bigger than 
> the MTU of the interface.
> If e.g. CSNP is too large for the link MTU it is splittet and the covered range of LSPs is mentioned 
> in the Start LSP ID to End LSP ID.
> 
> And for LSPs the router has to generate a multipart LSP.
> 
> I wouldn't want to change this internal fragmentation mechanism.

IS-IS fragmentation only works at the point of origination. If you have
IS-IS routers A,B,C like this, with the numbers indicating the links' MTUs:

+-----+ 1500 +-----+ 1280 +-----+
|  A  |------|  B  |------|  C  |
+-----+      +-----+      +-----+

Router A may e.g. generate an LSP fragment 1400 bytes in size. To my
knowledge, there is no mechanism in IS-IS to allow for router B to
transmit this fragment to router C.
The solution for this case is to configure all routers to generate only
LSP fragments <= 1280 bytes in size.

One consideration was to fix the LSP for IPv6 mode to generate only
packets <= 1280 bytes, since any IPv6 link has to be able to transport
1280byte IPv6 packets. Then again, limiting the size to <=1280 bytes is
something that is not strictly needed, so it might best be made only a
recommendation.

Using 1280bytes for hellos was indeed an unreasonable idea on my side
and should be changed.

>> However it might be cleaner to state that people
>> need to live with a smaller LSP size if they use IS-IS over IPv6 and
>> just forbid fragmentation.
> Wouldn't do it as already explained above.

Forbidding fragmentation was meant to refer to IP level fragmentation.
If IP level fragmentation is not allowed, people will have to set a
smaller LSP size as e.g. a maximum LSP Fragment transportable via
Ethernet with 1500 - sizeof(LLC-Header) is greater than 1500 -
sizeof(IPv6-Header).

> To summarize this:
> - keep the ISIS internal mechanism to handle (C/P)SNP and LSP fragmentation
> - allow the maximum possible MTU of the link for packets
> - hellos are padded everytime to maximum possible size
> - forbid fragmented ISIS IPv6 packets and log them (as there is something really weird if you 
> receive them)

I think we a in agreement there. I would go for this:

- IS-IS over IPv6 packets SHALL NOT use IPv6 fragmentation
- Hello packets SHOULD be padded so the resulting IPv6 packets reaches
  the maximum L3 MTU
- recommend that LSPs are only generated so that the IPv6 IS-IS packets
  are <= 1280 bytes in size, but allow for larger packets at the
  operator's discretion

> I'm a bit curious how the two opensource implementations currently handling this cases.

The opensource implementations are currently still at a prototype state
and therefore don't have strong error handling yet. LSP size is set so
that it will fit into 1280bytes, there is however no check done to
verify that received packets are not fragmented.

(By the way, I am not sure if standard socket API provides a way to
figure out whether a received packet was fragmented, but somehow it
should probably be doable.)

-Christian