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

[Alexandre Petrescu <[e-mail]>]

Le 05/01/2018 à 03:21, Lorenzo Colitti a écrit :
> On Fri, Jan 5, 2018 at 11:01 AM, Brian E Carpenter 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>      > Help me understand. Are you saying that mobile hotspots should
>     implement
>      > DHCPv6 because this draft says so, but then never turn it on
>     because it's
>      > bad for their users?
> 
>     Lorenzo, are you saying that the requirements in this draft need to be
>     scoped? That doesn't sound unreasonable, but if so, what would the
>     scoping text look like?
> 
> 
> Yes, I think that's the problem. The document takes a bit of a 
> one-size-fits all approach.

I think I agree with identifying such a problem of trying to be a 
one-size-fits-all document.

But in defence of it, I think there _are_ some requirements that all 
routers must implement regardless of being just a smartphone, a CPE or a 
big router.  E.g. MUST work on arbitrary prefix lengths (RFC7608), MUST 
respond to RS (why is RFC4861 absent from ipv6rtr-reqs and why RFC4861 
does not make this a MUST?), MUST join all-routers group (no RFC?), etc.

Again: a router MUST respond to RS, please.  Those who dont please tell why.

> You also don't need netconf/yang/syslog on a 
> mobile hotspot.

That could be a recommendation, instead of a requirement.  Mobile 
hotspots do need to be configured somehow and these netwconf/yang/syslog 
are coomonly agreed tools that are good recommendations.

> 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.

Agreed.

> 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 agree about not needing DHCPv6 between backbone routers, but I 
think RAs are mandatory even there for things like MTU or similar.

> IETF standards are about interoperability, they are not shopping lists. 
> (For an example of a document that suffered from this problem to a much 
> greater degree, see RFC 7849, which was taken out of the WG and 
> published as individual submission.)
> 
> Not sure how best to address this. A couple of options that come to mind 
> are:
> 
>  1. Removing the parts of the draft that are essentially a device
>     profile ("routers must support X, Y and Z").
>  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".
>  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.

0. Select the requirements that are mandatory in all routers including
    mobile hotspots and CPEs and state them at the beginning.

Alex

> 
> Cheers,
> Lorenzo
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>