Subject: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival?

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Oct 2016 11:48:37 -0400

In theory, by adoping draft-ietf-idr-bgp-attribute-announcement, IDR agreed that attribute scoping was an important issue.

As proven by the working group discussion on BGP large communities, the WG seems unwilling to consider anything that adds any level of complexity onto certain proposals.

Should we simply consider this draft dead?

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 5 Oct 2016 11:53:15 -0400

Jeff:
<individual contributor hat on> 

My reading of the list that:  
a) Large communities meets an "urgent/crisis level need"
b) Wide communities and bgp-attribute-announcement - meet a longer term
need. 

Did I miss understand the list's comments? 

Sue 
-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Wednesday, October 5, 2016 11:49 AM
To: IETF IDR WG
Subject: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival?

In theory, by adoping draft-ietf-idr-bgp-attribute-announcement, IDR agreed
that attribute scoping was an important issue.

As proven by the working group discussion on BGP large communities, the WG
seems unwilling to consider anything that adds any level of complexity onto
certain proposals.

-- Jeff

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

---

From: Rob Shakir <[email-masked]>
Date: Wed, 12 Oct 2016 01:57:39 +0000

Jeff,

I am interested in the working group pursuing this draft. The pressure
behind large community seems (to me) to be very short-term focused [0].
Operationally, I understand the requirement, but we should also be
improving the infrastructure that we have in BGP. There are numerous use
cases for BGP, many of which are not Internet DFZ focused. As part of this
infrastructure, I believe that in the longer term, we need the ability to
do attribute scoping in a more robust way.

The current definitions of non-transitive and transitive are overly coarse
for today's heterogeneous networks. It is particularly important to me that
we look beyond confederations as the only means of grouping autonomous
systems.

Cheers,
r.

[0]: This isn't to say that isn't required, I don't want to debate that any
further as I am pretty sure the horse that we're beating is little more
than a skeleton at this point. See
https://www.ietf.org/mail-archive/web/idr/current/msg16051.html

On Wed, Oct 5, 2016 at 8:54 AM Susan Hares <[email-masked]> wrote:

Jeff:

need.

Sue

-----Original Message-----

To: IETF IDR WG

certain proposals.

-- Jeff

Idr mailing list

[email-masked]

Idr mailing list

[email-masked]

---

From: t.petch <[email-masked]>
Date: Wed, 12 Oct 2016 09:54:24 +0100

----- Original Message -----
From: "Rob Shakir" <[email-masked]>
Sent: Wednesday, October 12, 2016 2:57 AM

> we look beyond confederations as the only means of grouping autonomous

I agree; if we had a more flexible definition, something between
transitive and non-transitive, then that could be an option for 'large'.
I also agree that 'large', while having strong consensus, is short-term
and that we could be looking for something more in a year or two.
(Which is a theme that recurs in the work of the IETF:-(

Tom Petch

> Should we simply consider this draft dead?

------------------------------------------------------------------------
--------

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 Oct 2016 11:11:38 +0000

Hi Jeff, Rob,

I agree with Rob that WG adoption of large communities in no way implies that attribute scoping is not a requirement and should not also be pursued.

In fact, there may even be hope for wide communities to evolve into the long term solution.

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Rob Shakir <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, October 11, 2016 at 9:57 PM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>, Jeff Haas <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-ietf-idr-bgp-attribute-announcement dead on arrival?

Jeff,

I am interested in the working group pursuing this draft. The pressure behind large community seems (to me) to be very short-term focused [0]. Operationally, I understand the requirement, but we should also be improving the infrastructure that we have in BGP. There are numerous use cases for BGP, many of which are not Internet DFZ focused. As part of this infrastructure, I believe that in the longer term, we need the ability to do attribute scoping in a more robust way.

The current definitions of non-transitive and transitive are overly coarse for today's heterogeneous networks. It is particularly important to me that we look beyond confederations as the only means of grouping autonomous systems.

Cheers,
r.

[0]: This isn't to say that isn't required, I don't want to debate that any further as I am pretty sure the horse that we're beating is little more than a skeleton at this point. See https://www.ietf.org/mail-archive/web/idr/current/msg16051.html

On Wed, Oct 5, 2016 at 8:54 AM Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Jeff:

need.

Sue

-----Original Message-----

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jeffrey Haas

To: IETF IDR WG

certain proposals.

-- Jeff

Idr mailing list

[email-masked]<mailto:[email-masked]>

Idr mailing list

[email-masked]<mailto:[email-masked]>

---

From: Job Snijders <[email-masked]>
Date: Wed, 12 Oct 2016 13:14:17 +0200

Dear working group,

On Wed, Oct 12, 2016 at 09:54:24AM +0100, t.petch wrote:
> > I am interested in the working group pursuing this draft. The
> > pressure behind large community seems (to me) to be very short-term
> > focused [0].  Operationally, I understand the requirement, but we
> > should also be improving the infrastructure that we have in BGP.
> > There are numerous use cases for BGP, many of which are not Internet
> > DFZ focused. As part of this infrastructure, I believe that in the
> > longer term, we need the ability to do attribute scoping in a more
> > robust way.
> >
> > The current definitions of non-transitive and transitive are overly
> > coarse for today's heterogeneous networks. It is particularly
> > important to me that we look beyond confederations as the only means
> > of grouping autonomous systems.
> 

Tom, I disagree with your remark about 'large'. Large BGP Communities,
by design and definition, are transitive. Put differently: A 96 bit
opaque entity which is not transitive, is not a Large BGP Community. I
am sure there are some usecases for such a non-transitive tool, but call
it has to be called something different.

Rob makes an excellent observation in "we should be improving the
infrastructure", an example is that during the standardisation of the
BGP BLACKHOLE community, not everyone appreciated the transitivity of
the well known community, but non-transitive didn't cut it either for
the use case. No tools were readily available to do any better, so a
choice between the two coarse approaches had to be made. I am interested
in having non-confed-based grouping of ASNs.

Regarding draft-ietf-idr-bgp-attribute-announcement itself, I wonder if
there actually is a need to be able to define an optional transitive
extended path attribute. We already have a method to do optional
transitive attributes today, maybe there is no need to provide a new way
to perform that function.

> I also agree that 'large', while having strong consensus, is
> short-term and that we could be looking for something more in a year
> or two. (Which is a theme that recurs in the work of the IETF:-(

I am not sure if the 'short term' or 'long term' distinctions do justice
to any of the efforts. In fact, I find it somewhat insidious to call any
effort in IDR "short term". (Apologies if my interpretation is an
artifact of a language barrier)

For all of these efforts, we're often looking at multi-year projects:
huge periods of time between "draft"-phase and "widely deployed
code"-phase. Then comes the popularising phase and education phase in
which people have to be trained in how to use the new technology, etc.
Entire ecosystems need to be upgraded, this is like turning a
supertanker around.

Large is not "short-term", it exists to address a narrow use case.
draft-ietf-idr-bgp-attribute-announcement can exist to address other use
cases.

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Oct 2016 09:51:55 -0400

Acee (and Sue earlier)

> In fact, there may even be hope for wide communities to evolve into the long term solution.

I would honestly prefer this conversation pretends the wide community draft
doesn't exist.  People keep getting hung up on it.

This is more the general long term question.

My intention a day after Sue's response had been to scrub the list of
pending path attribute features in IDR, BESS, etc., but I've not found the
time to do that yet.

WRT large communities, the main reason I cite that conversation is not an
attempt to "beat the dead horse", but to point out what was brought up as
technical objections to such header mechanisms.  If the WG simply wants to
declare what was raised as technical objections as non-technical objections
(i.e. "we simply didn't want to") - so be it.  But that's not how the
narrative ran.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Oct 2016 10:08:59 -0400

Job,

> to perform that function.

The base BGP extension mechanism gives us two ways to add new path
attributes:
- Optional-non-transitive: If you don't understand it, you drop it; it
  doesn't get propagated.
- Optional-transitive: It gets propagated, even if you don't understand it.
  The partial bit gets set if you do.  That bit is unfortunately protocol
  noise.

Effectively for most features that need some domain-wide deployment,
optional-transitive is the only real game in town.  For example, your route
reflectors need not understand the attribute if it's only important to your
edges.  This is a generally good property.

What's been problematic is when attributes leave the scope of interest,
probably shouldn't but there's no way to halt them.  The usual example worth
bringing up is attr-128 (RFC 6368).  It's a useful feature in some
deployments, but it's unfortunately also a cautionary tale about the hazards of
deploying code for features that haven't fully gone through the standards
process.

We tend to see the need for attribute scoping more from providers that
provide other BGP enabled services, and also are starting to see some of
this conversation happening in the BGP as a data center control plane
protocol.  Where this conversation tends to hit core service providers the
most is in the perennial issues of "optional transitive nonsense" that takes
down some bit of the Internet.  The BGP error handling RFC significantly
mitigates such issues, but I don't think it totally eliminates it.

It's understood the current proposal is overly coarse, but it was the easy
least-common denominator to start the conversation:
- Scope at confederation boundaries.
- Scope at AS boundaries.

Two additional cases that are somewhat clear from recurring conversations
elsewhere are:
- Scope at AS domain boundary.  Effectively, a confederation of cooperating
  ASes, just not using the confederation feature.  See prior conversations
  about the impact of eBGP AS checks for RFC 4684 (rt-constrain).
- Scope at arbitrary "group" boundaries.  The
  draft-ietf-idr-flowspec-interfaceset work is effectively a form of this,
  but not an exact use-case match.

Arguably, many MPLS VPN control communities such as route-target, etc. also
should have similar scoping considerations since their cleanup when sending
routes from the PE context to the CE context is not automatic in some
implementations.

This conversation is certainly less clear when you restrict yourself to
features wherein an implementation understands the feature.  At that point,
it's a matter of filtering.  But once you change the conversation to "the
implementation doesn't know and thus can at best pass things on", I think
we're at the relevant discussion topics.

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 12 Oct 2016 14:17:47 +0000

Hi Jeff, 

On 10/12/16, 9:51 AM, "Jeffrey Haas" <[email-masked]> wrote:

>> I agree with Rob that WG adoption of large communities in no way
>>implies that attribute scoping is not a requirement and should not also
>>be pursued.
>> 

Ok - so the dead-on-arrival comment was in the context of the generic
community header (which would be a logical place for scoping) not being
included in the large communities draft. I hope I understand now.

Thanks,
Acee