Re: [Idr] community of the day - common header

[Andrew Lange <[e-mail]>]

Hi Jared,

I’m glad you looked at the history!

When I was an operator, and wrote that original draft, which then became wide-comms, the motivation was the same as it is now.  

4-bytes ASNs were coming, and there are a lot of use cases that require not just a bigger community space, but a flexible community space.  It makes policy expressions MUCH easier and more powerful.  I still have an occasional nightmare about the manipulations Ed Crabbe and I had to go through to make the Exodus BGP policy work and parse correctly with fixed-length communities.  Just making the space larger propagates all the ugly that we have today.

After I moved to the dark side and started working for a vendor, other operators didn’t take up the baton, so getting implementations was tough — you know how vendors are coin-operated!  Now, the issue has become urgent.  I love the enthusiasm from the operator community!  

The right thing to do is to use a common header, that offers TLV capabilities.  Don’t let anyone whine that TLVs are “tough to implement”, it’s nonsense.  Every major BGP implementation can and does handle TLVs today.  

The consensus I see emerging is we advance a common header.  And, then put the interesting use cases like policy algebra, route-origin geolocation, etc. in separate docs. 

Andrew

P.S. I’m happy to have a beer BOF and we can go through some of the other use cases.  They are motivated by operational experience, and making policies we implement today faster and easier.   A lot of the use-case verbiage got trimmed in favor of implementation clarity.  Neighbor classes, for example, make policy expression a lot easier. 

> On Sep 9, 2016, at 11:03 AM, Jared Mauch <[e-mail]> wrote:
> 
>> 
>> On Sep 9, 2016, at 1:49 PM, Gert Doering <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> On Fri, Sep 09, 2016 at 07:46:50PM +0200, Robert Raszuk wrote:
>>> If WG agrees on attribute + common header as described in current -03
>>> version of wide community draft with perhaps additional comments to be
>>> incorporated in it - then we are done.
>> 
>> And if the WG does not agree, then -large is blocked?  Or how do I have
>> to read this statement?
>> 
>> Seems you and Jakob have been discussing this for years now, while the
>> operator community is waiting for something they can *just use*, no matter
>> whether it's brilliant or extensible or perfect.
> 
> there was a semi-decent timeline covered at NLNOG today, going back to 2002,
> namely an attempt to do something here:
> 
> https://tools.ietf.org/html/draft-lange-flexible-bgp-communities <https://tools.ietf.org/html/draft-lange-flexible-bgp-communities>
> 
> Here’s the presentation slides:
> 
> https://nlnog.net/static/nlnogday2016/14_NLNOG_large_communities.pdf <https://nlnog.net/static/nlnogday2016/14_NLNOG_large_communities.pdf>
> 
> I’m hoping there is an archive of the video, as there was palpable
> frustration from the operator community at the microphone which may
> help inform the frustration which is here on-list.
> 
> - jared
> _______________________________________________
> Idr mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>