Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs

<> Sat, 20 January 2018 00:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE168126FB3 for <>; Fri, 19 Jan 2018 16:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0oAchmy92gOE for <>; Fri, 19 Jan 2018 16:51:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 66F8D120713 for <>; Fri, 19 Jan 2018 16:51:24 -0800 (PST)
Received: by with SMTP id y77so1257371ybe.13 for <>; Fri, 19 Jan 2018 16:51:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=tcmqmlvDtiJwkcQrvMS6/QdP+SX/8Fe6Z1d7hP8is2g=; b=TOy8/13YDphhDxm7MPgcZXe4MnDzvVPkJpH0yVbt7UpgNq/6iOjhhraUy6bJ2pV2ku +8iXspt364fsZVV0uDUiOZiLIY50LhT0gi7aPJNfO/cnuYshelb0SqoxABLnpXShnbxE /XXoyZ3LA+t9yRDn8SyF5fwIlCFb5VMT0n5NJn+1N/9p/1kWTylMMH3FP5ZLwyp6ZY/4 hZAQ3Lm+0WV5cIj1sxKsWtitFBZ0KhXbmIKvDc4JjGqpseQLv/NFa0PFsoHUF00l0EgK h2vZVqFek5G0kf4f7B9EtpaMJKqm/9ToUpx76F4rzRKEjDlFQNZr0Sa7O2VCyxSw3LPV 1BUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=tcmqmlvDtiJwkcQrvMS6/QdP+SX/8Fe6Z1d7hP8is2g=; b=j+gW7W1sgU743rFFz9jsUxZdaWol02bgWJ/lRlqXwu75AHdrdikwdfaWut/nfvMnoC 6VTZ6Fu1yNia3QR/P1TPuNpd13s5mZDU0Qm6+lBvByx79aNzmE0agdqgE2ojhRSr1j5P VbvWBpn71ggD5nplxVzPUcF6ik49mIIpPM543peIoV5OrBNIE5VJntu4GSM5lI/Hf4wH OuogzYT6Kdii21LIvAjLBxNHDehLTBPWA1or2OehSuN7Ro4ohfVH+Xz2Tl8Brze5F9ha U6BntAx3399M3qpjI4SZx4xdXu485T0PwaeK5ffg/10OB6Jko6CHi0rF95DgNkTcr25L IZHw==
X-Gm-Message-State: AKwxytfGYkoOcQGF664faoja8zb2glkb9Fz+MXGudb0nUre1RBw3T6Uv GAFWVYmBaHb1k8FmZl6eNiY=
X-Google-Smtp-Source: AH8x2254AkQuDO8kDncy1b2IwuYdV+l+yasHmleuOMDUhAAXJWPgeR5jKHOs19dTTIoGWvJaOsRZIw==
X-Received: by with SMTP id i10mr239881ybj.122.1516409483511; Fri, 19 Jan 2018 16:51:23 -0800 (PST)
Received: from Russ ([2600:1700:720:1050:bccc:f1d:f0f3:d534]) by with ESMTPSA id m34sm3263886ywh.106.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jan 2018 16:51:23 -0800 (PST)
From: <>
To: "'Lorenzo Colitti'" <>, "'Brian E Carpenter'" <>
Cc: <>
References: <> <> <066901d385ab$64d663b0$2e832b10$> <> <> <>
In-Reply-To: <>
Date: Fri, 19 Jan 2018 19:51:22 -0500
Message-ID: <058c01d39188$cb3f7630$61be6290$>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJhq6FqXfQxKPsi9uY8X1ef5BV5bQJ9OQ9TASu4nfEBwpaRTQKGdYJTAomRt9CiC9Z1cA==
Content-Language: en-us
Archived-At: <>
Subject: Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 20 Jan 2018 00:51:32 -0000

> Yes, I think that's the problem. The document takes a bit of a one-size-fits all
> approach. You also don't need netconf/yang/syslog on a mobile hotspot. Nor
> does it make sense to say "the I2RS interface to the RIB be supported" on a
> home router that has one default route and two directly-connected subnets.

Sometimes you are building a small wireless community network with "wifi hotspot" style routers -- in which case YANG should definitely be there ("oh, that's a lower end device, we only support a GUI config on it" would not be an acceptable answer). Or maybe you're building a "router in a smart television," in which case maybe you don't want it to do DHCP or RA or anything else, because it's only intended to "route" for devices internal to the television itself (or a car, or some other thing).

> You probably also don't need DHCPv6 or RAs on a backbone router that's
> primarily intended as an LSR or segment router.

I can think of many situations when you do (see below for a specific example).

The point of this sort of document is to say: "Some people might not need this, but it SHOULD be included in implementations, so operators don't have to constantly guess at what might be included where, but rather can count on a set of common features across all implementations." This process will never be perfect (of course!), but the closer we can get to this, the closer we can get to interoperability and lack of large surprises among all devices that run IPv6.

> 1.	Removing the parts of the draft that are essentially a device
> profile ("routers must support X, Y and Z").

Which essentially leaves the document as a description of architecture and lessons learned -- okay, but this doesn't help interoperability, nor do I see the value of what remains as an RFC.

> 2.	Changing the aforementioned parts of the draft so that instead
> of saying "routers must support X" they say "if routers support X, they must
> support RFCs A, B, and C". An example is section 3.1. Instead of saying
> "routers must support DHCPv6, SLAAC, first-hop router selection, etc." it could
> say "if routers are intended to act as first-hop routers for hosts, they must
> support...", and "if routers are intended to be operator-configurable, then they
> must allow disabling SLAAC and enabling DHCPv6". This is what RFC 7084
> does - it defines a basic profile that everything must support, and then
> consists of a large number of statements along the lines of "if the CE router
> supports X, then it must do A, B, and C".

IMHO, this document should be a mixture of both kinds of things. 

To give a specific counter example: I would disagree that routers should only support SLAAC and DHCPv6 if they are slated to be a "first hop router for hosts." There are far too many situations where having SLAAC needs to be supported on a router that does not connect to a "host." For instance, FR Routing uses SLAAC to build IPv6 addresses on which to connect BGP sessions without manual configuration. Now imagine you go to a vendor and say, "this device isn't intended to connect to a host, so you don't need to support SLAAC," then you try to run configurationless BGP on top of it -- now it doesn't work, because some basic functionality -- something that it seems like, to me, should be included in every IPv6 stack -- is simply not there. I don't see how this promotes interoperability, or functioning networks. 

> 3.	Defining a number of device profiles that have mandatory
> requirements. This risks turning the document into a number of shopping lists,
> but perhaps those will be easier to get consensus on.

I don't think this will help -- we'd just argue about what the device profiles should be, creating a new one for each new set of requirements we can think of. Ultimately, I think we'd have a draft that just says "support whatever you like by choosing which profile you think your device fits under." 😊

The basic question comes down to this: Does the WG think building a basic set of requirements "pretty much" _all_ IPv6 routers should run a worthwhile concept, or -- is it that there are always going to be too many corner cases we can think of, too many exceptions to try to account for, to make this useful work? In other words, can we hope for an actual set of base IPv6 features with which to create an interoperable network, or is everything, always, going to be a "one off?"