Re: [Idr] dear diary: well-known community vs new path attribute

[Robert Raszuk <[e-mail]>]

Hello Job,

If we start to make choice between community vs attribute for each "boolean
function" based on the assumption that some folks will "_*never_ upgrade
their software*" then IDR job becomes really simple.

IDR should just manage registry of communities in 80% of its proposals and
we are done.

So while in Sriram's proposal for intra-as (if at all needed) community
will be a better choice IMO such call should be made each time on a case by
case basis depending on the extension being discussed rather then any
generic overrule.

Cheers,
Robert.

On Mar 31, 2017 21:01, "Job Snijders" <[e-mail]> wrote:

Dear colleagues,

In today's IDR session (thank you for the orderly meeting, chairs &
secretary!) the topic of 'well-known BGP community vs BGP Path
attribute' came up, in context of having a marker to signify or signal a
route's audience [Sriram] https://datatracker.ietf.org/
meeting/98/agenda/idr/

I've come to the conclusion that we have no choice other then to use a
well-known communities for boolean functions like the ones currently on
the table.

There are a number of significant advantages to using communities, that
in my opinion outweigh the perceived benefit of introducing a new path
attribute. This is asserted from a deployment process and adoption rate
perspective. Throughout this email I'll refer to the _function_ of the
path attribute/community as "feature X". Most reasons relate to
"accelerated" deployment rates. With "accelerated" I'm referring to a
2-3 year timescale rather then 8+ years. I'll share my analysis below.

We have to assume that there are many networks which might (from this
moment on) _never_ upgrade their software to the required newer software
to support feature X natively. There are a number of reasons why a
network might never receive the necessary software upgrades: the network
choose to continue using devices well after the End-of-Sale/Support/Life
date for economic reasons. Some networks use hardware longer then the
vendor intended, sometimes because the operator disagreed with the
vendor's view on longevity. Like some of you, I've travelled to regions
of the world where a good router, is a router without bullet holes in
it, in such cases you'll have to make things work with whatever was
loaded on there. In other cases, the vendor simply has gone bankrupt,
and the network has to make do with what is available on their sparing
shelves until the hardware is fully amortised.

With the above in mind, I'd argue that for many BGP features it is
entirely acceptable to state "upgrade your software and receive awesome
feature Y!". But in the instance of routing security, one might need to
salvage as much as one can in existing deployments, for altruistic
reasons.

I think it is fair to assume that in all cases, the BGP speakers will
support RFC 1997 BGP Communities. We can also assume that the device
supports neighbor-specific routing policy options to (at the very least)
match, and subsequently deny or permit based on the RFC 1997 community.

Another interesting (perhaps underappreciated) angle is that there are
both open source and commercial ancillary configuration management
systems on the market, which will happily manage devices which were not
upgraded to support Feature X natively. When vendor B doesn't want to
implement native support for Feature X, perhaps the ancillary third
market will support Feature X on vendor B.

A number considerations apply for well-known BGP communities in context
of route leak prevention:

- on day 0, there will be no routes tagged with the well-known
  community, likewise on day 365, there will be a small number of routes
  tagged with the well-known community.

- throughout the lifetime of feature X, the tagged routs are likely
  to be outnumbered by the untagged routes, in all contexts.

- ideally feature X can be deployed incrementally within an AS, so it
  should _add_ an extra layer of protection, rather then replace or
  hotswap an existing protection function.

- RFC 1997 communities are transitive, so Feature X must at the very
  least not be significantly hindered by the transivity, and in an ideal
  case actually benefit from the transivity property. Enforcing
  non-transivity through a RFC 2119-style "When received on EBGP, MUST
  delete" is also acceptable. Operators can manually emulate the
  non-transivity, and wait for software upgrades to do it for them.

- the presence of a well-known community on one route, cannot, and
  should not be superimposed to other routes received through the same
  BGP session. In a more general sense, a well-known community on one
  route cannot act as a semaphore for the entire session. I am not aware
  of any implementations which allow to match/act on one route and
  perform congruent manipulation of properties on a different route.

- When the well-known community for Feature X is present (aka 'true'),
  we can assume feature X for the route was enabled intentionally,
  however, in the case where it is absent, we're dealing with either an
  'unknown' or 'false'. The deny/accept logic we expect to be present
  either through manual manipulation or through

We also might be able to assume that networks looking to implement
Feature X, will do so out of their own volition, sufficiently motivated
to do so correctly. (Even though they are implementing the feature
manually!) Likewise, there will be a significant number of networks
which will not hear about Feature X for the foreseeable future, and only
receive the feature through software upgrades. In other words: network
operators whom are ignorant of Feature X until they read Release notes,
could be considered harmless. Furthermore, networks which are well
intended, might be in a position to recitfy erroneous use of the
well-known community for feature X when received across EBGP sessions.

>From my own deployment perspective, when using a BGP Community,
(disclaimer: merely stating options!) I can start deploying _right_now_,
_network-wide_ (meanwhile waiting for software upgrades to slowly start
catching up and replace my manual implementation). More importantly, I
can deploy in a heterogeneous environment where the timelines for policy
deployment and software deployment are not aligned, or with parts of the
network not even expected to receive the required software upgrade for
native support.

We haven't seen a standards track well-known community in a while, but
I'd be supportive of a well-known community RFC which demands rigorous
discipline related to the transivity, semantics, and would provide
configuration examples for those who cannot (yet) use Feature X
natively, with an agreed upon upgrade path to native support for
feature X.

As long as the benefits of using Feature X are 'egocentric' (aka
"deploying this concept helps me, and I don't need others to cooperate
with me"), and misuse of Feature X through the well-known community is
either merely self-inflicted pain, or harmless, we'll be fine.

Since Feature X is positioned in context of routing security, something
we'd probably like to see broad adoption on, I'd argue that the lowest
common denominator should be used: well-known BGP communities.

Kind regards,

Job

_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr