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

Karsten Thomann <karsten_thomann@linfre.de> Thu, 09 July 2015 19:33 UTC

Return-Path: <karsten_thomann@linfre.de>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F391A002A for <isis-wg@ietfa.amsl.com>; Thu, 9 Jul 2015 12:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.961
X-Spam-Level:
X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuMfxtP-SzPt for <isis-wg@ietfa.amsl.com>; Thu, 9 Jul 2015 12:33:38 -0700 (PDT)
Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32371A001C for <isis-wg@ietf.org>; Thu, 9 Jul 2015 12:33:37 -0700 (PDT)
Received: from linne.localnet (95.119.178.219) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 3E9C7B; Thu, 9 Jul 2015 21:33:27 +0200
From: Karsten Thomann <karsten_thomann@linfre.de>
To: Christian Franke <chris@opensourcerouting.org>
Date: Thu, 09 Jul 2015 21:33:25 +0000
Message-ID: <5617720.UqPZcug5lP@linne>
User-Agent: KMail/4.13.0.0 (Windows/6.1; KDE/4.13.3; i686; git-a6cb62d; 2014-12-22)
In-Reply-To: <559AD122.10404@opensourcerouting.org>
References: <20150703182710.5306.43728.idtracker@ietfa.amsl.com> <2393971.qq7UIhEPqS@linne> <559AD122.10404@opensourcerouting.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart1611502.Ho4S8u9ID1"
Content-Transfer-Encoding: 7Bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 5
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/Ys5D8YhM3DuO2dH5Cfgq3vMb-gM>
Cc: isis-wg@ietf.org
Subject: Re: [Isis-wg] Fwd: New Version Notification for draft-franke-isis-over-ipv6-00.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2015 19:33:40 -0000

Hello Christian,

an example of a switch dropping ISIS packets is a GS2200 from Zyxel, it is even mentioned in the 
release notes of the (older) firmware.
ftp://ftp2.zyxel.com/GS2200-24P/firmware/GS2200-24P_400BPN3C0.zip
In the pdf document page 12, fixed bug number 4.

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.

PPP for example makes sure there are unique Interface identifiers within the IPV6CP negotiation 
and Ethernet with DAD, protecting users against their own misconfiguration would be (almost) 
impossible.

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.

Regards
Karsten


Am Montag, 6. Juli 2015, 21:04:02 schrieb Christian Franke:
> Hello Karsten,
> 
> thank you for your input. I have made appropriate changes to the draft,
> they can be seen here:
> https://git.netdef.org/projects/OSR/repos/drafts/commits/8a6e90598a4ce
> 
> On 07/05/2015 10:37 PM, Karsten Thomann wrote:
> > I'm not sure if we really need this encapsulation, as there are not many
> > links layers left, but you should at least mention that it avoids some
> > problems with switches dropping ISIS LSPs if it's encapsulated in IPv6
> 
> The homenet working group is currently in the process of selecting a
> routing protocol to use. In that discussion some people voiced concern
> that IS-IS would not be a good option since it was specified on top of
> layer 2 instead of layer 3. This draft and the demo implementation were
> done to address these concerns. On the one hand by showing that it
> doesn't take much to run IS-IS on top of layer 3 and on the other hand
> to provide a standardized way to do so, should the need arise.
> 
> I was not aware that switches existed which drop IS-IS PDUs, although
> it's not that hard to imagine that there are switches which are broken
> in that way. Could you name examples for switches showing this behavior?
> 
> -Christian