Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

[Jeffrey Haas <[e-mail]>]

Tom,

On Wed, Oct 19, 2016 at 11:47:05AM +0100, t.petch wrote:
> RFC1997 says
> 'The community attribute values ranging from 0x0000000 through
>    0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.
> 
>    The rest of the community attribute values shall be encoded using an
>    autonomous system number in the first two octets.  '
> 
> Note the use of 'shall'.  Had that been written after RFC2119 then it
> would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this
> I-D is weakening the meaning compared to RFC1997.

It's also worth recognizing, good or not (there's definitely room for value
judgment in here), that practice has evolved.

As part of working through RFCs to basically say "don't use AS 0" and "don't
use AS 65535", the general consensus here and in grow was "yeah, that seems
like a good idea".  It probably still is.

But when code started going into place to enforce that (cli restrictions),
the weird edge cases started coming out.  People using AS 0 as a "wildcard"
in their community policy.  People using AS 65535 for BGP peering, etc.

Is it a bad idea?  Probably.  Historically AS 0 type things triggered all
sorts of entertaining buggy issues for reasons I've previously written
about.  AS 65535 is ugly simply because it clutters semantic space for
things like the well known communities.  And thankfully the issues
surrounding 0 as uninitialized variable and UINT16_MAX as being common
issues in BGP bugs seem to largely be behind us.

> If this I-D were to say that RFC1997 specified a 'MUST' (in effect) but
> that 20 years of experience showed that it need not be that strong, that
> ambiguities of interpretation have never been a problem for routing,
> pehaps by adding a note in the Security Considerations, then I would
> accept that.  As it stands, I think that this I-D is risky (and would be
> even if everyone who reads it knows what the IETF means by 'SHOULD' - I
> think that this is not the case and that those outside the IETF will
> read 'SHOULD' as a stronger enforcement than it is).

And yet, I think this is a case where the SHOULDs get enough "yeah, but..."
exceptions that it weakens even the arguments for that.

The one case I still find somewhat compelling deals with the strong
likelihood that some providers will port their RFC 1997 features into large
format via either script or implementation feature.  In such cases, porting
the well known communities into and out of large format present potential
issues.

-- Jeff