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

[Jared Mauch <[e-mail]>]

On Thu, Sep 08, 2016 at 05:40:31PM -0400, Jeffrey Haas wrote:
> [A portion of this conversation was held not only in the halls at the recent
> Berlin IETF, but at the IDR mic.]
> 
> I'm generally agnostic about the idea of the encoding of a 4:4 style
> community.  The fact that the 4:4 encoding in the wide-comms draft was able
> to shift from TLV (atom) based to flattened as seen in -03 should make it
> obvious that the wide comms draft authors also sees that particular point
> agnosticly.
> 
> The one point that I did push on heavily in earlier discussions is that
> future community (route coloring) mechanisms should stop burning path
> attributes for each new type.  I strongly believe that a new common header
> for future community mechanisms is needed:
> 
> - We shouldn't be burning path attributes for it.  While the code space for
>   it isn't being exhausted fast, it means the only way to discard
>   unparseable attributes (implementation doesn't support) is a general path
>   attribute filtering mechanism.  Such filtering mechanisms are hazardous to
>   the incremental deployment of new BGP features.

	Is there a particular shortcoming in rfc7606 that creates this
[moral] hazard, or are you speaking of the difficulty of writing
the code as referenced below?

> - By using a common header, undesireable classes of communities can be
>   filtered simply by type.  This can be done without any knowledge of the
>   format.

	We already have the collateral damage of filtering of attributes
in the operational space.  The cut+paste SDN model employed by most
providers results in things like the filtering of attribute 128 which will
effectively be permanent for networks.  The same is true for the maximum
as-path limits in place.  BGP fails fast and fails hard, but as the networks
became harder for operators to upgrade the ability to deploy fixed code
is extremely limited.  A 15 year old router could be upgraded much
faster than most modern devices.
	
> To offer an example of why such behaviors are desirable, early deployments
> of extended communities caused unfortunate effects far away from the
> attaching router because intermediate routers didn't understand the
> attributes.  This is a fundamental deployment issue of optional-transitive
> unknown attributes.

	There is inherent risk when introducing anything new.  Bugs happen
and they get fixed, this is part of the process.  As networks became more
business critical and are depended upon, it's much harder to make changes.

> I'm not particularly fond of the theater that has gone into this discussion
> - and good will has been burned by that theater.  But regardless of the
> proposal to implement 4:4, 4:4:4, N:4 ipv6:4 or whatever we invent next
> month, let's nip this bit of deployment madness.
> 
> A proposal for a common header is contained in section 3.1 of the wide
> communities draft.

	If the document has converged, what review is still necessary?
The comments in the past 24-48 hours on-list have made it apparent
to me much of the existing wide work was "field of dreams", if we can
inventory it, they will come [and use it].  This has not seen a benefit
for those networks facing the need, and resulted in extra efforts for
people who did not get a 2-byte ASN to use common tools.

<operational reality follows>

Any code received today will take me ~12 months to deploy.  If wide
communities is ready to WGLC and ship with 3.1, I'd like to see movement
immediately so we can test and plan accordingly.  ~6+ years is quite a
long gestation period for the IETF.

	- Jared


P.S. Jeff, lets get together in person next week if you have time.


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