Re: Wireless ND was: about violation of standards

Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com> Mon, 29 April 2019 13:13 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6A91200FF for <ipv6@ietfa.amsl.com>; Mon, 29 Apr 2019 06:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 9XA1ueDGhKjf for <ipv6@ietfa.amsl.com>; Mon, 29 Apr 2019 06:13:32 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (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 5211A1202D9 for <ipv6@ietf.org>; Mon, 29 Apr 2019 06:13:31 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1hL660-0000ImC; Mon, 29 Apr 2019 15:13:24 +0200
Message-Id: <m1hL660-0000ImC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Subject: Re: Wireless ND was: about violation of standards
From: Philip Homburg <pch-ipv6-ietf-6@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <bb7f7606-2adf-e669-8bcd-e41f17800782@gmail.com> <CAJE_bqd9frqX5-yeVPj8MYXpZ4737HqK1gmfD9cQV3A-Ea5HrQ@mail.gmail.com> <6bd5db47-408a-727e-5c13-f34a3465f986@si6networks.com> <CAJE_bqfTLqRbLp4fLu2ASZuZ+4G5c2G+RXkO92kXfLgPTqBnng@mail.gmail.com> <EEF00EA7-2AAF-403F-99AD-1D53ED18E8B3@cisco.com> <47631828-121F-402D-8165-969684C1101B@employees.org> <MN2PR11MB35655B36540829AEE5275964D8230@MN2PR11MB3565.namprd11.prod.outlook.com> <1066F69A-824F-4D6D-B221-8EFBAD15E15A@employees.org> <018c407a-b127-8724-d1ee-e19e3b084a60@gmail.com> <CABNhwV1jWHc1SMm=-xX0Oo5V4bo4VQBeQ5-CztJhP3y9006HRw@mail.gmail.com> <alpine.DEB.2.20.1904240659270.3490@uplift.swm.pp.se> <602A5CC5-170D-4E67-8907-A4D26606DB03@cisco.com> <m1hKoNd-0000IQC@stereo.hq.phicoh.net> <MN2PR11MB3565F908C3BD2D06E1564771D8390@MN2PR11MB3565.namprd11.prod.outlook.com>
In-reply-to: Your message of "Mon, 29 Apr 2019 12:18:49 +0000 ." <MN2PR11MB3565F908C3BD2D06E1564771D8390@MN2PR11MB3565.namprd11.prod.outlook.com>
Date: Mon, 29 Apr 2019 15:13:23 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/bdtJ4VG5yd-1616dQkHpwoC9BKw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2019 13:13:35 -0000

> Sure, matching a subnet per P2P link and then route between subnets
> one way of doing things.  Note that it is a deployment decision,
> not our decision as std makers or vendors. There are considerations
> out there like stability of links, capability to configure stuff
> from a management system and cheer scale that make people go for
> certain ways or others for their use cases. WiND allows to map
> subnets on P2P but does not force it, couldn't if we tried.

In general it is good to have clear operational justification to have
more than one way of doing something. Having multiple ways means more work
for implementations, risk of incompatible implementations, training costs,
etc.

I'm not judging against WiND, but it is worth looking at why other approaches
fail.

> About the size of the registrar, the backbone router enables a
> distribution of it. But really that is a discussion of the past.
> Routers can have gigs of memory. 

Some routers have gigs of memory. Some other routers only have a few megs
of memory. Issues with registration systems holding only one address are
real.

> And please do not dismiss the efforts that we had to make to enable
> routing in that space. RPL is not primitive in my book. WiND and
> RPL brought in a number of concepts that are now adopted in datacenter
> routing for RIFT, and though only nascent, I call RIFT a modern
> routing protocol.

So if you have a routing protocol, why not model it as a routing protocol?

Note that I'm interested in why mapping links to subnets fails. I.e., we tried
it and then this is what happened. 

Another issue, should we create big subnets that cannot do multicast?