NTAC Peering Working Group

[Steven Wallace <>]

Generally only /24s or shorter will be passed beyond a peer.

I believe it’s a reasonable exception that if you announce a /24 to only one provider, you’ll receive traffic for that /24 from only that provider.

DDoS scrubbing service providers depend on this, as do others.

ssw

On Apr 20, 2017, at 8:19 PM, John Hernandez <> wrote:

Here's another example of operational reality getting in the way of sound principles: if I announce a /32 host route to my transit provider, I should expect all traffic for that host to come in that way.  But it doesn't, nor am I naive enough to believe it will.

On Thu, Apr 20, 2017 at 5:46 PM, John Hernandez <> wrote:

Steve, that certainly describes the rules for a router, and routers behave that way invariably, but the extension of that premise to the Internet devolves into an operationally untenable scenario where in effect, if you have more than one eBGP adjacency, you MUST carry a full DFZ.  That does not happen in the real world, and Apple knows this.

On Thu, Apr 20, 2017 at 5:29 PM, Steven Wallace <> wrote:

I disagree. 

The most specific route is the only valid route for a destination. If a multi-homed network isn’t accepting routes from peers, and therefore is missing more specifics, then it will result in blackholes.

 "A route describing a smaller set of

   destinations (a longer prefix) is said to be more specific than a

   route describing a larger set of destinations (a shorter prefix);

   similarly, a route describing a larger set of destinations (a shorter

   prefix) is said to be less specific than a route describing a smaller

   set of destinations (a longer prefix).  Routers must use the most

   specific matching route (the longest matching network prefix) when

   forwarding traffic.”

On Apr 20, 2017, at 6:38 PM, John Hernandez <> wrote:

Brad, thanks for the explanation.   It's surprising to me that an Internet content company like Apple would advertise what amounts to a BGP lie (and one that could hurt their bottom line.)  Someone above the network engineering pay grade at those companies should know that their content is unavailable due to their own irresponsible network engineering practices.  

Truth in routing boils down to, "You announced the network, so make good on that and deliver the traffic."

One thing that I didn't see mentioned is that TR-CPS would be justified in rejecting Apple's problematic announcement(s) and should furthermore press the issue with Apple on our behalf.

On Thu, Apr 20, 2017 at 3:09 PM, Brad Fleming <> wrote:

Attached is the SUPER simple diagram I had to draw for Cox during our attempt to get the ACL removed. While it doesn’t explain the issue in great detail and was created to illustrate a specific use case you might be able to extrapolate meaning in a more generic sense.

Basically some TR-CPS content peers (not members) signal aggregates to TR-CPS but more specifics to the global Internet. Not a problem but they refuse to deliver traffic delivered to the aggregate if the destination host is in a different datacenter. Still not a problem unless a campus or connector is taking a TR-CPS table and ONLY a default from their full transit upstream. They’ll follow the aggregate learned from TR-CPS not knowing there’s a better route in the global Internet route table. 

--
Brad Fleming
Assistant Director for Technology
Kansas Research and Education Network
Office: 785-856-9805
Mobile: 785-865-7231
NOC: 785-856-9820

On Apr 20, 2017, at 2:54 PM, Pete Siemsen <> wrote:

Ok, I forwarded these notes to some colleagues, and got back "Please explain item 6 in more detail. Why does traffic get "blackholed by TR-CPS or its peer," and why are connectors with full routes immune to this issue?.

I had to admit that I'd zoned out during actual call, attempting to do two things at once, and learning once again that I can't :-)

Anyone care to enlighten me, please?

-- Pete

On Wed, Apr 19, 2017 at 9:02 AM, Matt Mullins <> wrote:

Here are the notes from yesterday’s meeting. Please feel free to correct any mistakes I have made.

 

1. Agenda Bash

2. Update on peering and TR-CPS/I2

·         Move Charter from 1GE to 10GE in Ashburn/Chicago/Dallas. Seattle to move to public exchange.

·         Capacity updates for Amazon for TR-CPS in Ashburn/Chicago for Amazon.

 

3. Network Weather Update

§  Nothing to update.

 

4. RPKI Update

·         Not much progress to report.

·         Will be a BoF at Global Summit.

 

5. Network DDoS Scrubbing Service Update

·         Close to signing contracts with Zenedge.

·         Pilots starting early-mid May.

·         Will be a Bof at Global Summit.

 

6. How to deal with the lack of a full routing table on TR-CPS (was: lack of transit on TR-CPS)

·         Issue Occurrence

o    only an issue with connectors/members that receive only a default route from their transit provided and more specifics from I2/TR-CPS

o    some times traffic gets blackholed  by TR-CPS or its peer

o    other times the peer will use their transit to deliver the traffic

·         Possible solutions:

o    members/connectors get full table from their provider.

§  Concern with requiring members/connectors having hardware needed for full table.

o    TR-CPS gets full routes from a transit provider. Don't advertise table to customers or advertise customer routes to provider.

§   Internet2 is in talks with Level(3) on increasing capacity to 10GE ports at Los Angeles/Chicago/Washington.

o    KanREN willing to provide full routes to TR-CPS as long as use is of limited occurrence and issues addressed with the I2 member. Possible issue is KanREN provider having filters in place which might drop the traffic from prefixes other than KanREN's. Brad to check with his Executive on that possibility and verify with KanREN's upstreams that prefixes are not being filtered.

§  Brad to hear back from Charter on ACL removal. All other KanREN transit providers will have no issue.

§  Could be setup quickly and used to get data for how common the issue is.

§  If KanREN is unable to provide, Dave Farmer can ask Big 10 Academic Alliance.

·         Concern with making sure the DDoS scrubbing service is taken into consideration.

o    Steve Wallace to write up a proposal.

7. AOB

 

--

John Hernandez, Network Engineer
1850 Table Mesa Drive, Boulder, CO 80305
Tel. 303-497-1280  Fax. 303-497-1818

--

John Hernandez, Network Engineer
1850 Table Mesa Drive, Boulder, CO 80305
Tel. 303-497-1280  Fax. 303-497-1818

--

John Hernandez, Network Engineer
1850 Table Mesa Drive, Boulder, CO 80305
Tel. 303-497-1280  Fax. 303-497-1818

Attachment: smime.p7s
Description: S/MIME cryptographic signature