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

prz <prz@zeta2.ch> Mon, 06 July 2015 21:10 UTC

Return-Path: <prz@zeta2.ch>
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 246C81A005B for <isis-wg@ietfa.amsl.com>; Mon, 6 Jul 2015 14:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.918
X-Spam-Level:
X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982] 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 z-j7qSlHPeiR for <isis-wg@ietfa.amsl.com>; Mon, 6 Jul 2015 14:10:08 -0700 (PDT)
Received: from zeta2.ch (zux172-086.adsl.green.ch [80.254.172.86]) by ietfa.amsl.com (Postfix) with ESMTP id EC60F1A003B for <isis-wg@ietf.org>; Mon, 6 Jul 2015 14:09:59 -0700 (PDT)
Received: from www.zeta2.ch (localhost [127.0.0.1]) (Authenticated sender: prz) by zeta2.ch (Postfix) with ESMTPA id 67EB618E28; Mon, 6 Jul 2015 23:09:55 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Mon, 06 Jul 2015 14:09:55 -0700
From: prz <prz@zeta2.ch>
To: Christian Franke <chris@opensourcerouting.org>
In-Reply-To: <559AD122.10404@opensourcerouting.org>
References: <20150703182710.5306.43728.idtracker@ietfa.amsl.com> <5596D981.4010906@opensourcerouting.org> <2393971.qq7UIhEPqS@linne> <559AD122.10404@opensourcerouting.org>
Message-ID: <b99d63fe1335dca975dc9b67b56d5824@zeta2.ch>
X-Sender: prz@zeta2.ch
User-Agent: Roundcube Webmail/0.4.2
X-MailScanner-ID: 67EB618E28.A0251
X-MailScanner: Found to be clean
X-MailScanner-SpamScore: s
X-MailScanner-From: prz@zeta2.ch
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/eBRT_KQT3G8LaKNIPv68eONveQo>
X-Mailman-Approved-At: Thu, 09 Jul 2015 02:56:27 -0700
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: Mon, 06 Jul 2015 21:10:10 -0000

 On Mon, 06 Jul 2015 21:04:02 +0200, Christian Franke 
 <chris@opensourcerouting.org> wrote:
> 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?
>

 Hey Christian, looked @ it with one eye & since the SNAP size problem 
 for ipv6 looks rather ugly to me, a question would be whether you 
 considered use of RFC3927 to resolve the 'no ipv4 on interface' problem 
 and just use the original draft for isis over v4 (in case when no ipv4 
 is assigned on interface, otherwise the '99 draft would work fine 
 out-the-box). RFC3927 should take care of the 'same subnet' check as 
 well that as far I remember is in all major implementations (since it's 
 all on same /16).

 Just random musing given that all the solutions suggested for the ipv6 
 in SNAP in the draft look a tad of a round peg in a square hole to me 
 ;-)

 Yes, I know HomeNet is all about IPv6.

 -- tony