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

Karsten Thomann <> Sun, 12 July 2015 10:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9217F1ACDD0 for <>; Sun, 12 Jul 2015 03:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.139
X-Spam-Level: *
X-Spam-Status: No, score=1.139 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dSZ1RRipbds6 for <>; Sun, 12 Jul 2015 03:40:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E6EF1A904D for <>; Sun, 12 Jul 2015 03:40:25 -0700 (PDT)
Received: from linne.localnet ( by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 2F343B; Sun, 12 Jul 2015 12:40:10 +0200
From: Karsten Thomann <>
To: Christian Franke <>
Date: Sun, 12 Jul 2015 12:40:04 +0000
Message-ID: <2899679.U2qPRIQ1tF@linne>
User-Agent: KMail/ (Windows/6.1; KDE/4.13.3; i686; git-a6cb62d; 2014-12-22)
In-Reply-To: <>
References: <> <5617720.UqPZcug5lP@linne> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart10887184.Ypy0XgRAbZ"
Content-Transfer-Encoding: 7Bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 7
Archived-At: <>
Subject: Re: [Isis-wg] Fwd: New Version Notification for draft-franke-isis-over-ipv6-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Jul 2015 10:40:27 -0000

Am Donnerstag, 9. Juli 2015, 22:30:47 schrieb Christian Franke:
> On 07/09/2015 11:33 PM, Karsten Thomann wrote:
> > an example of a switch dropping ISIS packets is a GS2200 from Zyxel, it is
> > even mentioned in the
> Thank you for the info.
> > Some additional comments:
> > 3.1 SNPA
> > I would use the link local IP as a tie breaker, as on the subnet are only
> > routers able to establish adjacencies if they are capable of ISIS over
> > IPv6 and there is no backwards compatibillity needed in this case.
> That sounds sensible, I think I will use this approach.
> > 3.2 MTU
> > Why you're restricting the packet size to 1280bytes?
> > The ISIS Packets SHOULD be padded up to the maximum mtu size to detect mtu
> > mismatches on the links. It is right not to use fragmentation, but this
> > shouldn't require to limit the size to 1280 bytes.
> > Maybe add to the fragmentation related sentence that all fragmented ISIS
> > packets MUST be ignored/dropped.
> The MTU part indeed is still a bit of an issue as it is currently in the
> draft.
> The intention of the limit to 1280 is to allow it to work exactly the
> same over various links, as all IPv6 capable links have to support an
> IPv6 MTU of 1280.
ISIS would run exactly the same regardless of the MTU.
> However if this is used, one would need another mechanism than padding
> to verify that MTUs of all routers on one link match - 
Why would we need another mechanism?

> not sure if that
> design (which is already used by OSPF) would be appreciated by this
> working group as I think that the robustness that the padding adds -
> e.g. allowing to detect brigeds with too small mtu in between of the
> routers - is a valued feature of IS-IS.
The hello padding is a "shall" requirement in the ISIS specification...

> 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.

> 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.
> Would be glad to hear your opionion on how you weight these aspects.

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'm a bit curious how the two opensource implementations currently handling this cases.