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

[Karsten Thomann <[e-mail]>]

Am Samstag, 18. Juli 2015, 11:45:12 schrieb Christian Franke:
> 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.
You're right.
I was still thinking between Routers A and B, as the problem with the MTU is not unique to IPv6 
transport.
> 
> 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.
Agree that recommendation seems to be the best, as it is a working default for all IPv6 links.
> 
> 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).
That is in my opinion the only way to handle it.

We have still the problem that non IPv6 based areas can have LSP sizes which can exceed the 
suported limit with IPv6 based transport with a standard Ethernet MTU of 1500.

I have no idea how we want to avoid proper network planning and setting of lsp sizes on all 
devices.
Operators which use ISIS over e.g. Ethernet and want to add IPv6 based transport for ISIS on 
some links must simply be aware about the lsp size limits.

Regards
Karsten
> 
> > 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