Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

[Wuyts Carl <[e-mail]>]

Hi Brian,

I Agree on the SHOULD statement, no issue of "not complying" with the RFC due to this.  However, as far as I know, SHOULD means "support it unless a good reason exists to not do this".  As you state below, the good reason is there "you don't know", but it's not a pleasant thing having to convince customers of this over and over.  As I've said: this part of that req has no added value at all, hence should not be present.

Regs
Carl

-----Original Message-----
From: Brian E Carpenter [mailto:[e-mail]] 
Sent: maandag 25 november 2013 20:32
To: Wuyts Carl
Cc: Victor Kuarsingh; [e-mail]
Subject: Re: [v6ops] RFC 7084 on Basic Requirements for IPv6 Customer Edge Routers

On 26/11/2013 04:03, Wuyts Carl wrote:
> Hi Victor,
> 
> Agree.  I do always recommend our customers to assign /56.  This doesn't mean it is always being deployed like this of course, we have single /64s as well.  But this is better for the sake of future proof and leaves some room for expansion without having to fiddle in the back-end to aggregation etc.
> The point I want to make is that the req of checking "too small" serves no goal, as nearly all CPE devices have a similar set of interfaces, of which some are used separately, mostly not, some have public wifi, mostly not, etc.  It just makes customers asking questions on it, as they base themselves upon this RFC to send their reqs to CPE vendors.  Moreover, too small (too big too ??) is too much subject of interpretation.

If I'm implementing a device and the spec includes a SHOULD, I will read the definition of SHOULD:

"SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

In the case in point, if I am unable to determine whether the delegated prefix is too "small" to address all interfaces, that is clearly a valid reason to ignore the requirement.
Therefore, I don't see this as a formal defect in WPD-3.

I think it's true that in many cases, the CPE will be unable to determine whether the prefix is too "small". Also, if there happens to be a subsidiary router hanging off one of the interfaces, it might want a whole bunch of prefixes, and the CPE router can't possibly know that in advance.

Also, "small" in this case turns out to mean "long".

WPD-3 could have been better phrased, but since product development managers have never met a SHOULD that they couldn't ignore, I doubt that it really matters.

    Brian