Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

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

----- Original Message -----
From: "Nick Hilliard" <[e-mail]>
To: "Job Snijders" <[e-mail]>
Cc: "t.petch" <[e-mail]>; <[e-mail]>
Sent: Monday, October 03, 2016 4:46 PM
> Job Snijders wrote:
> >     "For Autonomous System numbers which can be encoded as a 2-octet
> >     value, the two high-order octets of the Global Administrator
field
> >     are set to zero."
> >
> > Do you have a better suggested sentence? The above feels like a
kludge.
>
> I don't understand why this is necessary.
>
> This is a global administrator field, i.e. it's not guaranteed that
it's
> an ASN, so there can be no protocol level assumption that any number
> configured to fit in there should be treated any differently to any
> other number, even if that number incidentally happens to be the same
as
> the ASN configured on the device.


Nick

It is a global administrator field:-)  That is, it defines a namespace
within which the following data can be interpreted.  If the value is not
unique, as ASN are, then the following data cannot be reliably
interpreted and we are letting loose we do not know what on the
Internet.

A case study of how not to do this is MPLS which took a very narrow view
of its namespace which has led to a lot of subsequent work in order to
get round it, for example depending on the bit patterns of IP Version
numbers, and other possible first nibbles.  If MPLS had thought further
ahead, and nailed down its namespaces, then a lot of effort would have
been obviated.

Communities are not quite as important as MPLS but I still have a
concern, that if we allow anything into that first field, then we are
creating an untenable situation some time in the future.

Note RFC1997 says
'   The rest of the community attribute values shall be encoded using an
   autonomous system number in the first two octets. '

Today, I think we would /shall/MUST/

Here, I would go for 'MUST be an ASN' (or else the community should not
be transitive:-)

Tom Petch

> Secondly, the field is 32 bits wide, so if you have a number between 0
> and 65535, there is exactly one way of fitting that number into a a 32
> bit placeholder in network byte order.  This is why big endian
encoding
> works so well on the wire, and little-endian is terribly broken.
>
> The text would be better if this were left out completely.
>
> Nick