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

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

----- Original Message -----
From: "Julian Seifert" <[e-mail]>
Sent: Thursday, October 13, 2016 1:10 AM

Hi,

On 2016 Oct 11 phessler wrote:
> Putting my own ASN, or the ASN of my peer that I wish to control, will
> be the main uses; I agree.  But there is a difference between SHOULD
and
> MUST.  Since I MUST allow users to change the value there, I am happy.

I totally agree and want to give support to the current wording in the
draft.
" Global Administrator:  A four-octet namespace identifier.  This
      SHOULD be an Autonomous System Number assigned by IANA."

"Implementations MUST allow the operator to specify any value for the
   Global Administrator field."

The semantics of the value configured in the community is up to the
operator and must not be
enforced/assumed by the implementation. It makes sense to reserve
certain values/prohibit their
use to prevent compatibility issues, keep special values for
tests/documentation/checking and for well known communities
that might be defined later on, but don't force operators to only be
allowed to configure iana assigned
ASN values or force implementations to only allow configuration of  an
ASN in the GA that is a configured ASN on
the specific router etc.

Communities are great because of the ambiguity(sorry of not the correct
term for what I want to  express)
The vast number of values I can configure with meaning only for me and
parties I interact with)
being too strict will greatly diminish the value they represent as a
tool in operating networks.
And would be contradictory to the operational need from which the draft
arose.

<tp>

Julian

I believe I understand the need that you express but the BGP protocol
does not have the mechanics to express it!

You say
'configure with meaning only for me and parties I interact with'
but BGP has no such mechanism. As Jeff has already explained, an
optional attribute either gets dropped, which is unlikely to work with
route reflectors, or it gets passed on and this I-D chooses the option
that it gets passed on.  So a community that only you and your fellow
parties understand is let loose on the whole Internet where it is open
to misinterpretation by everyone else because, e.g., they are expecting
an ASN and are getting something else that is private to you.

And the remit of the IETF is to make the Internet as a whole work better
so in updating the specification of BGP, the IETF has to consider the
trade off of something that benefits you and the parties you interact
with versus the risk of causing some level of damage to the Internet.

Obviously, I hope, I am concerned about the damage; you gain, but
somewhere else across the globe, someone else's connectivity may fail.

Of course it is possible to define a more sophisticated system that
allows communities to go so far and no further but that is not the BGP
we have.

Tom Petch


kind regards,

  Julian
=