Re: [Idr] Request to adopt draft-heitz-idr-large-community - Working Group Adoption call (9/6 to 9/20)

[Jared Mauch <[e-mail]>]

On Wed, Sep 14, 2016 at 04:27:02PM +0000, john heasley wrote:
> Wed, Sep 14, 2016 at 12:15:26PM -0400, Jared Mauch:
> > On Sat, Sep 10, 2016 at 12:40:01AM +0200, Sander Steffann wrote:
> > > Hi,
> > > 
> > > >    +------+-------+----------------------------------------------------+
> > > >    | Bit  | Value | Meaning                                            |
> > > >    +------+-------+----------------------------------------------------+
> > > >    |  0   |   0   | Transitive across AS boundary                      |
> > > >    |      |   1   | Not Transitive across AS boundary                  |
> > > >    |  1   |   0   | Transitive across confederation boundaries         |
> > > >    |      |   1   | Not transitive across confederation boundaries     |
> > > >    |  2   |   0   | Local community value.                             |
> > > >    |      |   1   | IANA Registered community type or value.           |
> > > >    | 3..7 |   -   | RESERVED - MUST be zero when sent and ignored upon |
> > > >    |      |       | receipt.                                           |
> > > >    +------+-------+----------------------------------------------------+
> > > 
> > > I may be missing something here, but how is this going to work with routers that don't know about wide communities? Aren't communities marked as not transitive across boundaries going to leak across anyway and cause unexpected problems there?
> > 
> > 	None of these transitive things are necessary.  Operators already set the
> > transitive nature of the policies by enabling sending communities on a per-session
> > or group basis already.  If they are going beyond boundaries, it's because
> > the operator explicitly is permitting them.
> 
> While it would appear that someone is trying to be overly clever with the
> flags, I disagree.  It would be useful to mark a currently defined community
> as non-transitive and, since the whole premise of the draft is to allow for
> other applications and formats of a "community", transitivity is portentially
> a universally useful attribute.  eg: I may want to send route origin
> communities to customers, but not want them to forward that.

	Attempting to impose policy on a 3rd party in this way
is an interesting suspension of reality.  Once you send it, you have
no control over what they use it for, and pretending otherwise is
wishing for something that will not happen.

	If you don't want someone to use information, do not forward to them.

	The same rule goes for selfies, e-mail and paperwork around
your home.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [e-mail]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.