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

[t.petch <[e-mail]>]

I remain unhappy with this I-D.

I find it ironic that the messages for this Last Call should be
interspersed with those relating to what goes wrong when someone
somewhere else in the world uses a field in an unexpected way.  This
reinforces my belief that this I-D should be more forceful in calling
out the dangers (eg MUST instead of SHOULD).

I think that this I-D is factually incorrect, or at least open to
misinterpretation,  when it says
'[RFC1997] BGP Communities attributes are four-octet values split into
   two two-octet words.  The most significant word is usually
   interpreted as an Autonomous System Number (ASN) '

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.

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

So, interspersed with those e-mails about other fields that have
unexpected values, I oppose this going forward just yet.

The question of reserved values is another can of worms.  If they are
not reserved, then clearly they are an example of 'SHOULD' not meaning
'MUST' so they need reserving, but then, as Jeff is pointing out, you
open up the question of translation (something I flagged earlier as an
open issue).

Tom Petch

----- Original Message -----
From: "Jeffrey Haas" <[e-mail]>
Sent: Tuesday, October 18, 2016 9:38 PM

> On Oct 18, 2016, at 3:15 PM, Job Snijders <[e-mail]> wrote:
>
>> Part of the idea behind reserving 65535:*:* was to reserve a space
that
>> could later be used for well-knowns, if that was desired - but to not
>> spend time now arguing about details of what well-knowns are
necessary.
>>
>> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.
>
> Jeff argues that a justification should be added. Maybe someone can
> pitch in one or two sentences that explain why these are reserved?

That's certainly part of it.  While I think many people can see the
reason why you might want to do such a reservation, to do so you should
have a practical reason in the document.

For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want
to note that if it's used for that symmetry that either the existing
well known community registry is used at IANA or that a new one would
need to be created.  Alternatively, you just say the work is expected
and defer to a future document.

Note by doing this, you're setting up some expectations about
translation of communities from one space to another.  FWIW, I don't
recommend this and simply suggest that you recommend *not* using these
for common use in case someone decides that they want to do so.  I know
your organization and others such as Deutsche Telecom have some thoughts
about what translation infrastructure might look like, and such
mechanisms would have impact.

With regard to the 0: and max-uint32: cases, after dealing with the
headaches associated with helping with documents such as the as0 and RFC
7300 and putting in some restrictions in the configuration... followed
by having to take them away, I'm very reluctant to put in anything
beyond "we think it's a bad idea to use these, so pretty please don't"

-- Jeff (ask me about my RFC 7300 hate mail over beer...)