Re: [homenet] WG adoption of draft-stenberg-homenet-hncp-00

Pierre Pfister <pierre.pfister@darou.fr> Thu, 27 March 2014 07:50 UTC

Return-Path: <SRS0=iWy7=Y4=darou.fr=pierre.pfister@bounces.m4x.org>
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 C736C1A02A3 for <homenet@ietfa.amsl.com>; Thu, 27 Mar 2014 00:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, 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 XRwLkDdqj74V for <homenet@ietfa.amsl.com>; Thu, 27 Mar 2014 00:50:11 -0700 (PDT)
Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) by ietfa.amsl.com (Postfix) with ESMTP id A21DA1A0383 for <homenet@ietf.org>; Thu, 27 Mar 2014 00:50:10 -0700 (PDT)
Received: from [10.148.10.24] (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 437C11408EEE1; Thu, 27 Mar 2014 08:50:06 +0100 (CET)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Pierre Pfister <pierre.pfister@darou.fr>
In-Reply-To: <5333D118.60404@globis.net>
Date: Thu, 27 Mar 2014 08:50:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0DA30F4-4954-4CED-AEC1-D5751981F815@darou.fr>
References: <4943103B-77FB-4F95-A519-4FDE1246A128@nominet.org.uk> <53333F51.5030106@globis.net> <alpine.DEB.2.02.1403270703170.747@uplift.swm.pp.se> <5333D118.60404@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1874)
X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Mar 27 08:50:06 2014 +0100 (CET))
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/yzHqo79LB27EtWukXsszgvAzImc
Cc: "homenet@ietf.org Group" <homenet@ietf.org>, Mikael Abrahamsson <swmike@swm.pp.se>
Subject: Re: [homenet] WG adoption of draft-stenberg-homenet-hncp-00
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: Thu, 27 Mar 2014 07:52:03 -0000

Le 27 mars 2014 à 08:19, Ray Hunter <v6ops@globis.net> a écrit :

>> Mikael Abrahamsson <mailto:swmike@swm.pp.se>
>> 27 March 2014 07:04
>> On Wed, 26 Mar 2014, Ray Hunter wrote:
>> 
>> 
>> HNCP as it stands right now has a "routing protocol" of it's own that is extremely rudimentary, but it gets the job done. I think this is what is referred to as "zero routing protcol" because people don't really want to call it a routing protocol (my interpretation).
>> 
>> 

That is my understanding of the "zero routing protocol » too.

> Right, but the way I see it:
> 
> If you have an arbitrary topology then you probably need to carry metrics to prefer one link type over another.
> If you want to be able to determine which prefixes to delete from the FIB and RA when a particular upstream provider link goes down, you probably need some sort of tagging.
> If you want fast convergence around failures you probably need a decent path discovery algorithm.
> If you want to differentiate between a temporary change (due to an incident or link failure) and a longer term permanent change (due to replugging or device insertion or removal) then you probably need two different sets of timers and problem diagnostics.
> 
> In other words; we definitely need a routing protocol, and probably a configuration protocol too.
> 
> So isn't the danger than HNCP starts off being very simple, and ends up duplicating a lot of previous work and experience?
> 
> I'm interested to hear the contrarian view.

Except the second point (determine which prefix to delete…), which is done by the prefix assignment algorithm on top of HNCP, all other points will have to be answered to decide which routing protocol to use. The current draft doesn’t intend to answer the routing protocol issue. It was not left blank for the simple reason we  needed to implement it and make it run.

I dont think we want to run a complex routing protocol in HNCP. It’s more like either we want to make something very simple, and we use HNCP for this, or we want all what you said, and we use another existing protocol. The point of the draft is just to let you know that it is *possible* to route packets, in a very simple way, by using just HNCP as it is, with no extra information.

Regards,
Pierre

> 
> -- 
> Regards,
> RayH
> 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet