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

Christian Franke <> Thu, 09 July 2015 20:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3B0C1A0149 for <>; Thu, 9 Jul 2015 13:30:56 -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 W_Br-UtwF-Dn for <>; Thu, 9 Jul 2015 13:30:54 -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 D26F81A0141 for <>; Thu, 9 Jul 2015 13:30:51 -0700 (PDT)
Received: by wiwl6 with SMTP id l6so29020394wiw.0 for <>; Thu, 09 Jul 2015 13:30:50 -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=6Rp7B9t59cLSk8MzJiGN/6/3fUyRnyMMzavx22Gniqw=; b=ZQ4/kSuanHhnjWFtQoCGTubwMFtzYXVqdc4RUou/c+18HIXg4uR1Ibnxh29v9zcsF8 4wX9A7OBw2yreIemvOu83Z7FdOy4+u+0PraAnCinzfW76YxeM5+Kbonnmn9nSiW95Dih 0CeGTSf6gN8CKSJAVlq8ZMymPOnqnAXdLLEzcE7SlicW+4caWwX2tOl4pPRgd/097lvX JWvNHV2oSPjnI9QTXeyWeeKSuBWaDGyOZUethACpCmK7PNm5Avtgal4MXwKnqSJqIzE/ UTgLIDWWrffoh+dVAkj1uF/P5/x94EEEl5bQzoQcgbNqprK6ie4u5JBoSG/f2APixgeI r12A==
X-Gm-Message-State: ALoCoQnGmUb5o/8WTlVkBYS1B6gteDBw4dSmQ+N9H2ypA4UBsVTghIfX3RnYRkxXb1OCndQoTXdq
X-Received: by with SMTP id fz3mr87542351wib.45.1436473850592; Thu, 09 Jul 2015 13:30:50 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ee1sm9906420wic.8.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 13:30:49 -0700 (PDT)
Message-ID: <>
Date: Thu, 09 Jul 2015 22:30:47 +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: <> <2393971.qq7UIhEPqS@linne> <> <5617720.UqPZcug5lP@linne>
In-Reply-To: <5617720.UqPZcug5lP@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: Thu, 09 Jul 2015 20:30:56 -0000

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

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.

However if this is used, one would need another mechanism than padding
to verify that MTUs of all routers on one link match - 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.

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

Would be glad to hear your opionion on how you weight these aspects.