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

Christian Franke <> Sat, 18 July 2015 09:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D319C1B2A06 for <>; Sat, 18 Jul 2015 02:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TzrJtuRhNgqZ for <>; Sat, 18 Jul 2015 02:45:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24B3A1B29F7 for <>; Sat, 18 Jul 2015 02:45:16 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so54707302wib.1 for <>; Sat, 18 Jul 2015 02:45:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oXim/Sbs5Qduf4P0c8Jpi7gdHo0GHP5xBomPcolcDlM=; b=WpxRaJ5ytqOSvpgDJrhx4dLRcCDDt5k8SusibaddSXw3TsNsmHgEILxQAJNDFepc8i jHVL1r+6nyonLh/K6oXuWBSKDnXlCFwOuyqBVdDGbzfhFXHs4nME4G5EyxTJobH9BlmZ cy4BATtTcxOyi18pthDXMSEMqCVM601Ps22TIqug8HL+hkdkmhOr2pAIYS+jjG7MtKvx mjW+pS2nwevKd2/DHgyU3i8Tyc4KD5KlXPwxhduSI8ZNUfBtSlBO9GNEWhEsQBJ5PXXH Cc2BcqnAgFXD2lvnUg/3YWzJMDx2L3KOWVLw9TnEcEMHnD6Jbn3a8X1kb+5DMlF5ABax wQRw==
X-Gm-Message-State: ALoCoQkbqAHVS8Aic64M6yCFXDbxUAaWJ67gOaHxQAq726UachEWOpEYAh2l5de1GgsD1sWtxPzG
X-Received: by with SMTP id q10mr36698532wjq.27.1437212714932; Sat, 18 Jul 2015 02:45:14 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:136:221:6aff:fe0c:cbe6? ([2001:67c:370:136:221:6aff:fe0c:cbe6]) by with ESMTPSA id ho10sm21933257wjb.39.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 02:45:14 -0700 (PDT)
Message-ID: <>
Date: Sat, 18 Jul 2015 11:45:12 +0200
From: Christian Franke <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Karsten Thomann <>
References: <> <5617720.UqPZcug5lP@linne> <> <2899679.U2qPRIQ1tF@linne>
In-Reply-To: <2899679.U2qPRIQ1tF@linne>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
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: Sat, 18 Jul 2015 09:45:18 -0000

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

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 -

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