Re: [homenet] Bits'n'bites demonstration of ISIS for homenet

David Lamparter <equinox@diac24.net> Wed, 23 July 2014 17:43 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DC71A02D4 for <homenet@ietfa.amsl.com>; Wed, 23 Jul 2014 10:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 EAu5_vg4BLC9 for <homenet@ietfa.amsl.com>; Wed, 23 Jul 2014 10:43:43 -0700 (PDT)
Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) (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 1B7901B2B17 for <homenet@ietf.org>; Wed, 23 Jul 2014 10:43:43 -0700 (PDT)
Received: from [2001:8d8:870:10ef:1::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <equinox@diac24.net>) id 1XA0Zl-0002Ju-FQ; Wed, 23 Jul 2014 19:43:37 +0200
Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.82) (envelope-from <equinox@diac24.net>) id 1XA0ZT-003S4M-Ng; Wed, 23 Jul 2014 19:43:26 +0200
Date: Wed, 23 Jul 2014 19:43:19 +0200
From: David Lamparter <equinox@diac24.net>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Message-ID: <20140723174319.GN801478@jupiter.n2.diac24.net>
References: <alpine.DEB.2.02.1407231348210.7929@uplift.swm.pp.se> <87zjg0cgh4.wl-jch@pps.univ-paris-diderot.fr> <alpine.DEB.2.02.1407231617460.7929@uplift.swm.pp.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1407231617460.7929@uplift.swm.pp.se>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/OzTtHifJg145n4dng7aiCQtJ2RE
Cc: homenet@ietf.org, babel-users@lists.alioth.debian.org, Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: [homenet] Bits'n'bites demonstration of ISIS for homenet
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jul 2014 17:43:47 -0000

On Wed, Jul 23, 2014 at 04:23:07PM +0200, Mikael Abrahamsson wrote:
> On Wed, 23 Jul 2014, Juliusz Chroboczek wrote:
> >> there will be a demonstration of ISIS running as the homenet routing
> >> protocol under the HNCP umbrella, basically replacing Babel in the same
> >> framework that was demonstrated at previous IETF.
> >
> > That's excellent news.  Have you written down your protocol extensions?
> > Did you have any unexpected trouble with source-sensitive routing in link
> > state?
> 
> I wasn't directly involved in coding this, so I don't know. However, there 
> is a goal to document experiences with the implementation, and to 
> standardize the extensions needed. This work has been initiated during the 
> IETF and I hope there will be things published in the next few months.

Regarding protocol extensions, this is an implementation of
http://tools.ietf.org/html/draft-baker-ipv6-isis-dst-src-routing-01
If someone else creates another implementation of that, it should
-basically- be compatible.  We did not have unexpected trouble in IS-IS's
link state/database management.

There are known and expected issues regarding interop between srcdest
and non-srcdest IS-IS implementations, i.e. a source restricted route
should never point to a non-srcdest router.  This will be addressed in a
future revision of the draft. (Examining interop wasn't part/goal of our
work so far, but having the implementation certainly creates the
opportunity to do just that.)


-David