[GROW] Suresh Krishnan's No Objection on draft-ietf-grow-large-communities-usage-07: (with COMMENT)

[Suresh Krishnan]

Suresh Krishnan has entered the following ballot position for
draft-ietf-grow-large-communities-usage-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/



--
COMMENT:
--

Overall the document was well written and easy to read. I did have one
question though. It is not clear how the values for the Local data part 1
are matched up to the functions and communicated between the peer ASes?
Is this going to stay purely a local matter between ASes or is there
going to be a movement towards some sets of known functions (e.g. the BGP
blackhole community RFC7999)?


___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] [Idr] IETF LC for IDR-ish document (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

[Jakob Heitz (jheitz)]

My program to create filters does not care about customer/peer/transit.
It does not care about tier-1 or tier-2.
It looks at your BGP table and finds your largest neighbors,
sized by the number of routes it sends you.
Then for each of those neighbors, it examines as-paths in all other routes
to find all other ASNs between you and adjacent to that neigbor.
Then it builds an as-path filter that allows only those ASNs as upstreams
from that neighbor.

For example, AS-2914 and AS-209 are both tier-1 ISPs.
AS-2914 receives some routes from AS-17676 that passed through AS-209. 
(routeviews)
The simple rule "no peer routes from customers" would drop those routes.

All the filters are collected together into a single route-policy or route-map.
Then you apply the policy to all your ebgp sessions.

Here is an example of how to apply the policy:
route-policy your_neighbor_in
  if apply allow_as then
pass
  else
set community (65000:666)
set local-preference 0
  endif
end-policy

You may list all the routes that were disallowed like this:
show bgp community 65000:666


Thanks,
Jakob.


> -Original Message-
> From: Richard A Steenbergen [mailto:r...@e-gerbil.net]
> Sent: Saturday, May 06, 2017 1:17 PM
> To: Jakob Heitz (jheitz) 
> Cc: Robert Raszuk ; grow@ietf.org
> Subject: Re: [GROW] [Idr] IETF LC for IDR-ish document 
>  (Default EBGP Route
> Propagation Behavior Without Policies) to Proposed Standard
> 
> On Fri, May 05, 2017 at 10:51:41PM +, Jakob Heitz (jheitz) wrote:
> > Thanks Robert.
> >
> > I did it without using ios-regex or other time consuming string conversion 
> > stuff.
> > Still, this method cannot scale to cover every one of several thousand AS 
> > neighbors that some ISPs have.
> > IOS cannot handle that many as-path access-lists.
> > I can see that the simple rule of "do not allow peer routes from a customer"
> > doesn't cut it, because some tier-1's have a lot of customers with over 
> > 1 routes each.
> > My filters will certainly cover all the major peers as well as major 
> > customers of ISPs.
> > I included a limit on the number of policies to write:
> > so that it will just get the major ones.
> > Also, if a routing table includes leaks, then the resulting policies will
> > continue to allow the leaks.
> > Also, some of the filters may need to add some upstreams that are not in 
> > the table of the day.
> > Basically, it is a start that may require a bit of tweaking.
> > I have a better idea of what to commit to the IOS.
> > It will be far more efficient, but I want to gauge interest first.
> 
> I built something very similar using Juniper commit scripts many years
> ago, and used it at GTT, a very large Tier 1 network.
> 
> It was fairly straight forward, all you had to do was feed it an ASN
> list of your "tier 1" peers (ASNs which should never be heard behind
> anyone other than ^asn.*), and "tier 2" peers (ASNs which can be heard
> as ^asn.* as well as ^(tier1|list|here) asn.*). It would then
> automatically create custom as-path filters for each BGP peer, based on
> the individual session and where it found the neighbor asn on the list.
> For customer sessions, it was also easy to incorporate simple as-path
> filters for the most common leaks, e.g. you should never here anything
> on the tier 1 list from any of your customers under any circumstances.
> I'd be happy to release the code if anyone is interested.
> 
> For a well-connected well-peered network, this was absurdly effective at
> preventing huge numbers of the most common routing leaks. In my
> experience, the VAST majority of leaks are caused by simple human typos,
> and/or mistakes caused by things like the (IMHO incredibly poor) default
> behavior to announce everything on a new BGP session with no configured
> policy.
> 
> That said, I have great difficulty imagining how you would successfully
> create any kind of 100% automated as-path filter system based on
> observed behavior in the routing table, based on my many years of
> experience running some of the largest Tier 1 networks on the planet.
> It's simply not practical in the real world. I WOULD highly encourage
> you to pursue building better as-path filtering tools similar to the
> scenario I described above though. It would be great if you could easily
> feed your router some as-path-lists, and configure your policy to build
> the filters described above without needing a script to create a per-as
> as-path filter expression. I wouldn't recommend trying to turn it on
> automatically, but you'd probably help a large number of ISPs by giving
> them the ability to build these filters without requiring complex
> scripting, of offline config automation tooling.
> 
> But the one thing I think every vendor COULD do to vastly improve the
> accidental route leak situation is precisely what this draft suggests,
> default to reject for EBGP neighbors with no configured policy. That's
> one of the very first