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

Sent from my iPhone

> On Oct 15, 2016, at 5:45 AM, Job Snijders <job@ntt.net> wrote:
> 
> Hi,
> 
>> On Sat, Oct 15, 2016 at 12:49:28PM +0100, t.petch wrote:
>> I think that Brian well expressed the issue in a post 15 minutes
>> before yours.
> 
> No. That posting is proposing new radical ideas about propagation
> behaviourisms that are not part of this specification.

Actually, I was not proposing anything in particular. I'm not sure who it was that suggested "automatic clean-up", but I'm pretty sure it was one of the co-authors.

What I was saying, was if any change (over the current propagation mechanics) was to be implemented, it would be best to discuss the specific methods, here and now.

I am opposed to any changes to behavior as part of the protocol.

I do think all implementations need to provide operators the knobs to change, add, or remove large communities.

I will let Tom speak for himself but I expect he will concur.

>  A specific
> design requirement for -large-, stated by member of the working group is
> the simple transitive nature of the attribute. Given the very different
> nature of what you and Brian propose, I suspect it might warrant its own
> draft.
> 
>> My concern starts with the protocol rather than the implementation,
>> seeing getting the protocol right as the first step, even if it does
>> not seem possible at present for a router to enforce the protocol
>> rigidly. I see BGP as a whole as somewhat weak on security, on
>> authentication and data integrity, and these things only getting fixed
>> after a disaster or two.  So I am content to specify a protocol which
>> implementations may or may not catch up with at a later date.
> 
> I am not content with a protocol for which there are zero
> implementations. Without implementations, there is no standardisation in
> IDR.
> 

Okay, this appears to be the perennial, gigantic disconnect.

This is the IETF, not IVTF (vendor).

The engineers specify, based on rough consensus. Vendors collaborating without the general agreement of the WG is not consensus, regardless of implementations.

The many years leading to "large" are a symptom, as was "extended" which preceded it.

I think we all agree on the meat of "large", except possibly the "must" vs "should" for ASNs. For that, I think WG consensus should be polled..

Brian

> Based on my experience with RFC 1997 - I feel that you may be
> misrepresenting the risk surface. 
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr