Subject: [GROW] New Version Notification for draft-ymbk-grow-bgp-collector-communities-01.txt

From: [email-masked]
Date: Mon, 07 Sep 2015 03:23:35 -0700

A new version of I-D, draft-ymbk-grow-bgp-collector-communities-01.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.

Name:		draft-ymbk-grow-bgp-collector-communities
Revision:	01
Title:		Marking Announcements to BGP Collectors
Document date:	2015-09-07
Group:		Individual Submission
Pages:		5
URL:            https://www.ietf.org/internet-drafts/draft-ymbk-grow-bgp-collector-communities-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ymbk-grow-bgp-collector-communities/
Htmlized:       https://tools.ietf.org/html/draft-ymbk-grow-bgp-collector-communities-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-grow-bgp-collector-communities-01

Abstract:
   When BGP route collectors such as RIPE RIS and Route Views are used
   by operators and researchers, currently one can not tell if a path
   announced to a collector is from the ISP's customer cone, an internal
   route, or one learned from peering or transit.  This greatly reduces
   the utility of the collected data.  This document specifies the use
   of BGP communities to differentiate the kinds of views being
   presented to the collectors.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Job Snijders <[email-masked]>
Date: Mon, 7 Sep 2015 12:50:15 +0200

>From the diff:

> The ASN in the marking SHOULD be that of the collector peer.

For my understanding, if AS 8283 feeds RIPE RIS, AS 8283 would be the
'collector peer' in the above context?

> The communities were selected from community values which were unused
> at the time of this document and SHOULD be as follows: 
>
>        +----------------+-----------+    
>        | Category       | Community |    
>        +----------------+-----------+    
>        | Customer Cone  | ASN:64994 |    
>        | External Route | ASN:64995 |    
>        | Internal Route | ASN:64996 |    
>        +----------------+-----------+    

I think it would be more honest if you phrase it as "The communities
were choosen by rolling a big dice". ;-)

Why does the ASN need to be part of the BGP community? As data collector
you already know the feeding ASN by looking at the first entry in the
AS_PATH.

Wouldn't an even simpler method be to just tag all "external" routes
with "NOPEER" [RFC3765], not expect any community on customer cone
routes, and assume that prefixes with an AS_PATH length of 1 is are
internal routes?

Even if it is deemed desirable to put the ASN in the community itself,
how will we deal with 32-bit ASNs? Have people sometimes use RFC5668,
and sometimes RFC1997-style communities?

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Mon, 07 Sep 2015 12:53:22 +0200

> 'collector peer' in the above context?

yes

> were choosen by rolling a big dice". ;-)

except that would be a lie.  the statement in the document is precise.

> you already know the feeding ASN by looking at the first entry in the

normal practice.

> routes, and assume that prefixes with an AS_PATH length of 1 is are

no.  as_path length of 1 covers my static space, from which i allocate
static customers.  as path_length of 1 also covers any p2p and other
internal-only prefixes i might eak to the collector.

> and sometimes RFC1997-style communities?

should work

randy

---

From: Job Snijders <[email-masked]>
Date: Mon, 7 Sep 2015 13:23:04 +0200

> except that would be a lie.  the statement in the document is precise.

I do not feel comfortable overloading locally administrated bits with
something that represents global significance. The 64xxx communites come
dangerously close to codepoints we use internally. I'd prefer that the
local portion of BGP Communities remains truely local.

> > you already know the feeding ASN by looking at the first entry in the

ah, well ok then. 

> internal-only prefixes i might eak to the collector.

I assume projects such as RIS and routeviews have many many BGP feeds,
you can infer meaning from the totality of those feeds, if one ASN
seemingly originates a /30, but another ASN seemingly originates a
larger block, and you observe a BGP adjacency between the two ASNs, you
can write it down as router2router linknet.

I believe you should waive the requirement to include the collector peer
ASN as part of the BGP community.

The objective is to simplify what RFC 4384 attempted to document, I
would encourage the group to reduce the technicalities to a single
boolean option: a prefix can be a customer route, or it is not.
Everything else should be deduced from what is already available in the
collected protocol data today.

For operators this should be easier to implement, for researchers it
might also be healthier as they cannot rely on spoon-fed ground-truth.

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Sep 2015 14:16:39 +0200

> something that represents global significance. The 64xxx communites
> come dangerously close to codepoints we use internally. I'd prefer
> that the local portion of BGP Communities remains truely local.

only problem is that completely blows the purpose of the exercise, a
global tagging to help ops and researchers be more sure of what they are
seeing in the collectors.

> you can infer meaning from the totality of those feeds

agree, you can infer meaning.  problem is you get it right only some of
the time; and even then, you can not be sure.

> if one ASN seemingly originates a /30, but another ASN seemingly
> originates a larger block, and you observe a BGP adjacency between the
> two ASNs, you can write it down as router2router linknet.

maybe.  but you *really* do not know.  note that /30s are now in the
table as allocated by rirs.  and, despite our advice to the contrary,
/64s are used both as internal p2p links and as customer allocations.

lots'o papers have been written on these problems and researchers have
spent a lot of time and energy showing that you can only approximate.
bgp is such a great information hiding protocol.  take your gorgeous
star chart and sample a few dozen asns three or five hops out and get
ground truth on their out-degree and compare.  sigh.

> I believe you should waive the requirement to include the collector
> peer ASN as part of the BGP community.

what asn should be in the community?  or does this go with your also
wanting to remove the community value?  can we keep the colon?  :)

> boolean option a prefix can be a customer route, or it is not.

describe a rigorous formal algorithm for 

> Everything else should be deduced from what is already available in
> the collected protocol data today.

not an approximation, but a complete algorithm.  a few decades of minds
smarter than i have been unable to do so.  so i eagerly await
enlightenment.

> For operators this should be easier to implement

once i have to tag one flavor the other two are trivial.  and it
provides a nice check on my announcement filters

> for researchers it might also be healthier as they cannot rely on
> spoon-fed ground-truth.

oddly enough, the ncc tries to make things easier for people, not be a
test or hurdle.  i know this does not hold for all regions, sadly
enough.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 Sep 2015 17:05:48 +0200

> global tagging to help ops and researchers be more sure of what they
> are seeing in the collectors.

i think i misunderstood you.  you are suggesting using 42-44 or
whatever, not 65000 space.  sure.  i do not care what the numbers
are.

randy

---

From: Job Snijders <[email-masked]>
Date: Tue, 8 Sep 2015 17:15:38 +0200

> whatever, not 65000 space.  sure.  i do not care what the numbers

I suggest to take the codepoint(s) from 0xFFFF0000 - 0xFFFFFFFF
http://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml
as we then at least have made the most effort to avoid clashes with
locally significant values.

At the very least I see operational value in having a well-known
community to tag "customer" prefixes with, this is something I'd use
internally, in public documentation and BCOPs/guides how to set up a BGP
transit network. A "CUSTOMER" community could benefit a group braoder
then the research community.

Kind regards,

Job

---

From: Emile Aben <[email-masked]>
Date: Mon, 07 Sep 2015 12:56:59 +0200

>> you already know the feeding ASN by looking at the first entry in the

Also: the feeding ASN can be part of an organisation with multiple ASNs,
that are part of their customer cone, but not customers ('sibling ASNs')

Emile

---

From: John Kemp <[email-masked]>
Date: Wed, 9 Sep 2015 15:24:50 -0700

> then the research community.

Only two comments I would add:

Are those three categories comprehensive?  Does this cover the case when
you have hybrid peering+transit arrangements, for example?

And more to the collector point, if we look at BMP mirroring,
the collection is indirect.  I don't think the peers themselves get
an opportunity to express export community tags for a typical
BMP monitoring setup..... :(  In which case I would put more emphasis
on more correct or more extensive RPSL and IX tagging, not collector
specific tagging...

John Kemp

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Sep 2015 10:28:00 -0400

> locally significant values.

I'm weakly supportive of this overall proposal.  

One issue with going to well known communities is that the role of a given
route may vary depending on provider.  To that end, a well known community
can't really help.  Extended communities could work, but mechanisms for
arbitrary extended communities aren't well implemented.

What seems to be needed more than a standard as to what communities everyone
should use is a method of exchanging the mappings for a given provider.
Wide communities are intended to have some of this semantic, but the
mechanism to exchange the mappings is undefined at this time.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 18 Sep 2015 15:51:34 +0100

> should use is a method of exchanging the mappings for a given provider.

that would be difficult, as there is no way of exchanging exact semantics.
 I.e. one provider's opinion on how a specific community tag should be
implemented might differ from their peer's.

If the aim of this + other similar drafts is to create a set of
standardised community tags, then presumably this will also standardise on
the semantics for all of them.  If that's going to happen, then settling on
specific values will reduce overall complexity.

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 18 Sep 2015 21:06:20 +0600

> What seems to be needed more than a standard as to what communities
> everyone should use is a method of exchanging the mappings for a given
> provider.

things change over time.  consider a proggy trying to do an analysis
over one rv/ris rib per month over ten years.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 19 Sep 2015 09:15:36 +0600

nick,

> that would be difficult, as there is no way of exchanging exact
> semantics.  I.e. one provider's opinion on how a specific community
> tag should be implemented might differ from their peer's.
> 
> standardised community tags, then presumably this will also
> standardise on the semantics for all of them.  If that's going to
> happen, then settling on specific values will reduce overall
> complexity.

any help making the, admittedly terse, semantics in the draft more
rigorous and clear?

   Customer Cone:  One's own prefixes and the closure of those to whom
      transit is provided including routes announced by BGP customers,
      static prefixes used for non-BGP customers, datacenter routes,
      etc.
   External Routes:  Routes learned from peers and transit providers
      which the ISP would normally announce to customers but not to
      peers.  Often, ISPs do not announce such routes to collectors.
      But, as there is no general practice, this category is important
      to mark.
   Internal Routes:  ISPs occasionally announce to the collector
      Internal point to point and other routes they would not normally
      announce to customers, peers, or transit providers.

randy