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

[<[e-mail]>]

> 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?"

😊

Russ