NTAC Peering Working Group

["Spurling, Shannon" <>]

Here is my thoughts: (Kind of thinking out loud)

I think this is a compound problem. There is the covering route issue, and then there is the IP address topology issue.

 

I see the covering route with specifics as a solution to the elephant in the room. Route table size. It also sounds like a better solution to those of us that want to avoid a LOT of extra work. If you can advertise a covering route, and a more specific route, you add two prefixes to the internet table. If you have to only advertise prefixes of what you want on a link, you have to break it down, and can be messy and big. Using Covering routes and more specifics is not a bad thing to do for influencing path selection. It’s all in how it mixes.

 

Then there is the IP topology issues. In some cases, people start to think of IP’s as identifiers, not addresses. (Cisco LISP tried to address that.) So, they want to take bits of their address space and move it to other locations around the internet. That should be fine by its self, but when they do the previous covering route behavior becomes an issue. There is also the policy issue, where people say “This service is available on this side of the network but not that one.” And it is located in a subnet that is advertised more specifically out where you want it to go. Then the other direction is blocked by policy or topology. That creates the partitioning.

 

Prefix advertisements are recommendations, not rules or laws. Kind of like David Farmer was saying about taking full routes for a multi-homed network. It’s a good idea (should), but no one says you have to (must). So, these network admins that set metrics or routes, which are more of a firm recommendation (should), and then set hard policies or partitions based on those routes (must), are being a bit naive. You really should have a path or some way to reach the more specific route when it’s being advertised by the covering route. Not sure you could say it’s unacceptable behavior. It’s not ideal.

 

 

Shannon Spurling

 

 

From: [mailto:] On Behalf Of Steven Wallace
Sent: Friday, April 21, 2017 7:54 AM
To:
Subject: Fwd: Covering prefix blackholing traffic to one of its covered prefixes....

 

FYI, I sent the following to the NANOG list…..

 

I’ll forward any responses.

Begin forwarded message:

 

From: Steven Wallace <>

Subject: Covering prefix blackholing traffic to one of its covered prefixes....

Date: April 21, 2017 at 8:37:46 AM EDT

To:

 

We have dual-homed sites that only accept routes from their peers, and default to their transit provider. A site may receive a covering prefix from a peer, but since they are not accepting the full table from their transit provider they don’t see the covered (i.e., more specific). In some cases the peer announcing the covering prefix blackholes traffic to the covered prefix.

Is this accepted behavior, or should a peer announcing a covering prefix always delver packets to its covered routes?


Does this happen often?

Thanks!

Steven Wallace
Indiana University