What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

Mailman List Mirror (Read Only)
1

Hi,

I am hoping for a bit of advice. We are rolling out IPv6 en mass now to peers and I am finding that our "strict" IPv6 ingress prefix filter is meaning a lot of peers are sending me zero prefixes. Upon investigation I determine they have de-agregrated their /32 for routing reasons / non interconnected islands of address space and in consequence advertise no covering /32 route. The RIR block that the allocation is from is meant to have a minimum assignment of /32.

From:

http://www.space.net/~gert/RIPE/ipv6-filters.html

We get:

ipv6 prefix-list ipv6-ebgp-strict deny 3ffe::/16 le 128
ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48
ipv6 prefix-list ipv6-ebgp-strict deny 2001:db8::/32 le 128
ipv6 prefix-list ipv6-ebgp-strict permit 2001::/32
ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 35 le 35
ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2001:0678::/29 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:0c00::/23 ge 48 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:6000::/36 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:13c7:7000::/36 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2001:43f8::/29 ge 40 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2002::/16
ipv6 prefix-list ipv6-ebgp-strict permit 2003::/16 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2400::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2600::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2610::/23 ge 24 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2620::/23 ge 40 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2800::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2a00::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict permit 2801:0000::/24 le 48
ipv6 prefix-list ipv6-ebgp-strict permit 2c00::/12 ge 19 le 32
ipv6 prefix-list ipv6-ebgp-strict deny 0::/0 le 128

I have peers in 2a00::/12 that are advertising me /48s without the /32 assigned to them.

While this has been a problem in IPv4 land in the past with some people de-aggregating a /19 to regional /24s with no covering route because of no backbone. What should we be doing in IPv6 land as I suspect this may become a bigger problem than it ever was in IPv4.

I can adopt the view, well you should, so I'm going to filter, and they can say well that's not practical, we have a /32 and we advertise a /48 at each individual internet exchange. RIRs policy wont allocate us a lot of separate /48s from an appropriate block. Aggregation argues you shouldn't de-aggregate.

We might as well start off as we mean to go along and try not to pollute the v6 route table with all the rubbish that is in the v4 one.

So what is the "best" answer.

1> Don't advertise islands of space under assignment minimum, without providing a covering aggregate route?

2> Don't use strict filters, they don't work well and de-agragegation with IPv6 is going to be a problem?

3> Don't use filters, generate it from an IRR?

Given there is no "right" answer what is considered to be the best fit one?

Kind Regards

Ben

2

This sounds like your best bet. Assuming you can find an IRR with
comprehensive enough coverage.

The other option is of course "don't filter based solely on RIR minimum
assignments" ..

I know at least some ISPs (like swisscom) do this for v4 too, but that
simply means people who try to multihome with anything less than a /19 in
level3 land aren't going to succeed.

http://v-authoring.ip-plus.net/documents/BIS_TI_Router_Filter_Policy_EN.pdf

ip prefix-list martians seq 8000 permit 8.0.0.0/7 le 19
[etc]

Not so much of a problem in v4 but as you saw for yourself, you risk not
seeing prefixes at all if you try this.

3

Hi,

Yes, but a multi-homing customer would have PI space from an appropriately filtered block allowing /24 PI v4 or /48 PI v6. An ISP would have their own RIR PA allocation /22 to /19 v4 or /29, /32 v6 block that are from blocks that follow along the lines of minimum assignment size for that block. This is not a problem created by the registries or by the filters. The problem comes with ASes that don’t have a backbone interconnecting all of their POPs / islands and are therefore unable to add a covering route and do not provide a route via any transit provide for the whole ip block at the RIR minimum boundary. In some ways whether people should:

1> Have a network of none interconnected islands that take IP space from the same IP block below RIR minimum?

2> Should we filter these networks?

3> Should the /32 be visible in the route table somewhere if the intention that component /48s are going to be visible on the Internet.

I don’t like the IRR answer particularly as it requires a level of third party trust that I am not entirely comfortable with, nor configuring separate filters for each BGP peering session.

Ben

4

IMHO:

4) Use mild filters (e.g. allow a /32 to be disaggregated to /36's)
and send a polite email to the POC to the effect of, "Please beware
that because you have not offered a covering route matching your
allocation, your IPv6 network is not reachable from ours. IPv6 is not
IPv4: end users requiring /48s for multihoming should get them
directly from the RIR. For complete Internet connectivity, we strongly
encourage you to offer a covering route."

Regards,
Bill Herrin

5

like that.
Frank

6

Hi,

Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. They then advertise a /24 v4 and /48 v6 at each Internet exchange that they are connected to. That is "fine" for driving router. The "problem" with this design is that they cant announce their /32 as they are not running a iBGP mesh. I have seen a number of content providers doing this by design, and in the context of their business I can understand why and see it makes some sense. The only problem comes with the prefixes ending up under the minimum prefix size for the block they are in.

Now when this is a large content provider and we all want the peering, then we relax the filters, fine, but why one rule for them and another for everyone else in the same /12 block. Would it not make sense for the RIRs to assign a /12 as issuable in /32, /29 to content providers who will specifically deagregate to /48 with no internal network.

That solves the filtering problem, doesn't force these networks to put an iBGP network in place and lets everyone who does run a network "properly" to announce the proper aggregate blocks / covering routes with more specifics if we have to have them for routing purposes.

A separate /12 for the "island" type networks would immediately make this problem disappear.

Am I being overly simplistic?

Ben

7

Hi,

Yes, nice. But... It does not address the case when this is not the ISPs customers but the ISP (read content provider) that operates globally but without a network interconnecting their routers. They then advertise a /24 v4 and /48 v6 at each Internet exchange that they are connected to. That is "fine" for driving router. The "problem" with this design is that they cant announce their /32 as they are not running a iBGP mesh. I have seen a number of content providers doing this by design, and in the context of their business I can understand why and see it makes some sense. The only problem comes with the prefixes ending up under the minimum prefix size for the block they are in.

Yep. Ack.
For the filtering policies it'd be nice to use space from a special prefix
- like for PI assignments.
But that will drive "global" routing table size :frowning:
But that's what content providers who create islands are bound to do - or
is there a way around without real connectivity or tunnels?

And the "polluters" apparently don't have enough incentives or pain to void
islands...

Frank

8

In a message written on Wed, Nov 14, 2012 at 01:10:57PM +0000, Ben S. Butler wrote:

I am hoping for a bit of advice. We are rolling out IPv6 en mass now to peers and I am finding that our "strict" IPv6 ingress prefix filter is meaning a lot of peers are sending me zero prefixes. Upon investigation I determine they have de-agregrated their /32 for routing reasons / non interconnected islands of address space and in consequence advertise no covering /32 route. The RIR block that the allocation is from is meant to have a minimum assignment of /32.

You are conflating two different issues, which are essentially
toally unrelated. There is the smallest size block an RIR will
allocate out of some chuck of address space, and then there is how
people announce it on the Internet. In the real world they have
almost nothing to do with each other, something folks understand today
in IPv4 but seem to think IPv6 magically fixes, it doesn't.

[Historically there were folks who maintained filters on IPv4 space, but
they gradually disappeared as the filters became so long they were
unmaintinable, and people discovered when your job is to connect people
throwing away routes is a bad thing.]

For instance, there are folks who could use the "multiple discrete
networks" policy to get a /48 for each of their 5 sites. But instead
they get on /32, use a /48 at each site, and announce them
independantly. Same prefixes in the table, but filtering on the
RIR /32 boundry means you won't hear them.

I'll point out it's not just longer, but shorter prefixes as well:

ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48

F-Root announces 2001:4f8:500:2e::/47. You're going to miss it.
There are other servers in this block that are in /47's or /46's.

If connectivity is what you value, here's the right filter:

ipv6 prefix-list ipv6-ebgp-permissive 2001::/12 ge 13 le 48

Yes, the DOD has a /13, and yes, people expect to be able to announce
down to a /48.

9

Hi Ben,

That case is covered by things like ARIN's multiple discrete networks
policy which permit an ISP /32 or end-user /48 for _each_ distinct
network. There are plenty of addresses in IPv6. You should be break up
a /32 for traffic engineering purposes, not for the sake of handling
multiple disconnected sites. And when exercising TE, you can offer a
covering route and expect the network as a whole to still function
regardless of other folks' suballocation filtering.

Regards,
Bill Herrin

10

I guess I'm confused. I have a /32 that I have broken up into /47's for my discrete POP locations. I don't have a network between them, by design. And, I won't announce the /32 covering route because there is no single POP that can take requests for the entire /32 - think regionalized anycast.

So, how is it "worse" to announce the deaggregated /47's versus getting a /32 for every POP? In either case, I'm going to put the same number of routes into the DFZ.

Mike

11

Hi Michael,

If you announce an ISP /32 from each POP (or an end-user /48, /47,
etc) then I know that a neutral third party has vetted your proposed
network configuration and confirmed that the routes are disaggregated
because the network architecture requires it. If you announce a /47
from your ISP space, for all I know you're trying to tweak utilization
on your ISP uplinks.

In the former case, the protocols are capable of what they're capable
of. Discrete multihomed network, discrete announcement. Like it or
lump it.

In the latter case, I don't particularly need to burn resources on my
router half a world away to facilitate your traffic tweaking. Let the
ISPs you're paying for the privilege carry your more-specifics.

Regards,
Bill Herrin

12

I guess I'm confused. I have a /32 that I have broken up
into /47's for my discrete POP locations. I don't have a
network between them, by design. And, I won't
announce the /32 covering route because there is
no single POP that can take requests for the entire
/32 - think regionalized anycast.

So, how is it "worse" to announce the deaggregated
/47's versus getting a /32 for every POP? In either
case, I'm going to put the same number of routes into the DFZ.

Hi Michael,

If you announce an ISP /32 from each POP (or an end-user /48, /47,
etc) then I know that a neutral third party has vetted your proposed
network configuration and confirmed that the routes are disaggregated
because the network architecture requires it. If you announce a /47
from your ISP space, for all I know you're trying to tweak utilization
on your ISP uplinks.

Again, I thought the discussion was about PI, not PA. I don't announce any PA.

In the former case, the protocols are capable of what they're capable
of. Discrete multihomed network, discrete announcement. Like it or
lump it.

In the latter case, I don't particularly need to burn resources on my
router half a world away to facilitate your traffic tweaking. Let the
ISPs you're paying for the privilege carry your more-specifics.

You have great confidence in the immutability of design and the description thereof.

Mike

13

Hi,

" Again, I thought the discussion was about PI, not PA. I don't announce any PA."

My point, which I feel may be getting lost, and for which ARIN may already have policies in place for, is that an IP assignment is made out of a block with a defined minimum assignment size.

Now some people simply advertise the assignment that is made to them, some people chose to advertise more specifics with a covering route, I have no problem with any of this. What I am saying, is if people chose to deagregate to create islands, for which I can completely understand the commercial and networking reason and why it is then by extension impossible for them to advertise the covering route. Then in these specific cases of "islands" then these assignments should be made by the RIR from a block with a minimum prefix size of a /48. Then the application is submitted to the RIR it will justify as much space as it justifies, but at this point it should also be established - without any judgment positive or negative - if the intention is to advertise this unagregated or with a route for the aggregate. The RIR would then be empowered to assign the requested amount of address space from a block which can be labelled with a lower minimum prefix size.

I am not judging any of these design practices. What I am pointing out is that the designs are being implemented in assignment blocks that do not reflect the recipients implementations intentions and this is neither helpful for them or other AS operators when it comes to filtering. If RIR policies establish this intention at the point of assignment then the "island" case will be catered for and we absolutely do not want to see an aggregate in the route table for assignments from that block. IF it is TE then it can be made from a conventional block with a cover router and more specifics.

What I am seeing in the real world is island networks in address space with minimum /32 assigments. It is my choice if I filter your TE, it is a stupid choice if you don't advertise the cover route because you are doing TE. But what we need to facilitate are islands networks which for very sensible technical and commercial reasons are unable to advertise an aggregate. Policies may be in place to provide for this, however, what I am seeing in the route table is telling me that the policies are failing to identify people that want to implement their network in this fashion as they are coming from blocks with /32 min and they are advertising /48s. If these announcements came from and address block to which they were assigned with a minimum of a /48 because of their design intentions then everyone is happy and can announce and filer accordingly and end points are reachable.

There is a reason that different blocks have different minimum sizes, I am advocating ensuring that we get assignments aligned with the blocks that are suit the intended implementation.

It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable.

My 2c

Ben

14

Hi Michael,

PI and PA terminology is getting to be as obsolete as Class A, B and
C. Your IPv6 addresses fall in to one of three categories:

"Allocation" from RIR under ISP rules (/32 or more)
"Assignment" from RIR under end-user rules (/48 or more)
"Reassignment" from ISP (any size)

You will find that you can successfully propagate announcements of
allocations in units of /32 or shorter, assignments in units of /48 or
shorter and reassignments in units of /32 or shorter.

Longer prefix announcements won't be rejected by everybody, but
they'll be rejected by enough folks to spoil your day.

So, regardless of which of the three types of addresses you work with,
you should make sure to get enough so that each of your discrete
multihomed networks can announce a prefix as big as or bigger than the
minimum.

And as a purely pragmatic matter, you should never ever try to number
a discrete multihomed IPv6 network using a reassignment. Go get an
allocation or assignment (as appropriate) from the RIR instead.

Regards,
Bill Herrin

15

Hi,

I thought I would share an extract from an email I sent off list to a peer. My mail was a rather ramberly stream of consciousness exploring the issue, which worked its way to a potential solution... Hence why I am sharing an extract from it. I am not sure how practicably implementable it would be with the use of communities and some extra filtering logic implemented by the router software to enable prefix matching on less specific. I include for open discussion, I am sure there are things wrong with this idea, but maybe we can move towards a solution that works for everyone, rather than continuing in a straight line and having a bloated v6 route soup of indistinguishable /48s all over the place. Maybe the below has some legs, I leave it for those clever than me to see if this can be incorporated into an emergent BCP that might address what we should be doing and give everyone clear guidelines and keep everything on track.

<snip>

As I said its not the content networks I have issue with, it the rest of the access networks and hosting networks that are going to abuse a relaxation policy of "you should only announce /32 and use communities and no export for TE to adjacent ASes, but because there are a lot of island networks that require /48 support yours will also get accepted but please don't do this for TE reasons."

What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix. Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48". That would dump off all the TE nonsense, while keeping the island networks /48s. This new functionality could be used in a route map so it could be augmented with community matching or AS filter lists. That would solve the problem, all be it at the cost of the processing overhead to examine each /48 in the table and recurse its route, versus simple application of a filter list based on net block and minimum allocation size. I guess another thing that might work is if we all start passing communities and then we can tag some /48s as I am a TE prefix with a cover route and use a different community to tag I am an island prefix with no cover route, and then we can filter or permit those in a route map as the recipient sees fit and next the route map could filter everything left on RIR minimums for the block. That might work a lot better, if everyone passed communities.... At least people would be incentivised to tag the island routes which would be guaranteed to be permitted, we might have to worry about some people tagging a TE route as an island route. So I guess the logic becomes....

/48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB.

/48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers.

/48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid.

Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as "PA (Aggregated)" / "ISP" blocks that have a /32 minimum.

If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work... I think that would address the problem.

</snip>

Thoughts...?

Ben

16

Hi,

...

<snip>

...

What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix. Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48".

Would you want this logic to still apply if you have ::/0 in your table
anywhere? It really is the ultimate "covering" route for everything
else, and for some set of sites that advertise non-aggregated /48s,
their thought process may wander into the territory of "it doesn't
matter so much if you don't see the more specifics, you'll just
follow your default route to your upstream provider, and it'll reach
me that way."

It seems that this particular problem space only occurs for networks
that want to implement strict filters to limit their routing table size,
but also want to run completely default-free. It sounds a little bit
like such people may be trying to shift the cost burden around in
an odd fashion.

"I don't want to listen to your more specifics; I worry about my
routing table resources, and whether or not I can keep up with
the rest of the internet. But I also want to look like I'm one of
the big default-free providers, which means I'm creating reachability
problems to your network through my own choices. Won't you
help me solve my self-created problem by altering how you
build and configure your network?"

I have no issues with people filtering out more specific prefixes
to limit the size of their view of the routing table; I do it for
routers I administer that don't have adequate resources to
take a full view. But I also ensure that those devices have
a covering default route towards something that *does* know
how to get closer to the destination.

[more snippage...]

So I guess the logic becomes....

/48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB.

/48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers.

If you're having reachability problems to /48s that you're filtering
out, you must be trying to play in the DFZ; otherwise, your default
route would cover you, and this would be a non-issue. And if you're
playing in the DFZ, by your own rule here, you should be carrying
those routes rather than filtering them out.

/48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid.

Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as "PA (Aggregated)" / "ISP" blocks that have a /32 minimum.

If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work... I think that would address the problem.

I think your use of the term "cheating" here is misapplied.

You've stated that the more specifics *must* be accepted
by the DFZ providers, so that downstreams can make their
own decisions as to whether to accept and use them or not.
You're implying that your network is default free, and thus
by not accepting the more specific prefixes, you would see
reachabiliity issues:

It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable.

Contrary to that line, you've stated you _do_ expect that
DFZ providers should accept those TE routes with or
without a coverall, in order to provide reachability. I don't
think it's reasonable for you to expect to have it both ways.
It really sounds like you want every other DFZ provider to
have to carry the longer prefixes *except you*--and I don't think
you'll see much support from the rest of the community
for a proposal like that.

And if you *do* carry ::/0 in your network from an upstream,
this is all a moot point; filter away to whatever level your
heart desires, you won't be creating a reachability problem;
at worst, you'll create some inefficient routing, but the
packets will still flow.

</snip>

Thoughts...?

Ben

tl;dr -- "this is what those HE sessions are for."

Matt
probably way off in the weeds in left field at this point...I should
never try to reply to messages during the day; so many distractions,
I never remember what it was I was trying to say back when I started
the sentence. ^_^;

17

Hi,

Ok. I am trying to encourage an inclusive exploration of an issue that seems to be emergent. I am trying to get the community to articulate BCP not dictate it.

"Would you want this logic to still apply if you have ::/0 in your table anywhere?"

Yes obviously limits would apply to the filter on min and max in a recursive filter.

"It sounds a little bit like such people may be trying to shift the cost burden around in an odd fashion."

I am seeking community input before we manage to screw things up. I do not want a route table with 10M+ prefixes. One of the points of v6 is aggregation, would it not be silly to adopt a liaise a faire view to route pollution and associated security considerations.

"But I also want to look like I'm one of the big default-free providers"

I struggle to not use direct language here. Firstly I never asserted I was DFZ or want to be, quiet the opposite, seeking clarification of BCP.

"default route towards something that *does* know how to get closer to the destination."

Filtering exists for internet security not route table size, your default return path trashes that.

"you must be trying to play in the DFZ"

Lol, understand the issue at hand

"I think your use of the term "cheating" here is misapplied."

Read my suggestion, if you deliberately falsely tag a route with the wrong community under my proposed model, what would you call it?

"You're implying that your network is default free"

Nope, I am trying to find a solution that works for everyone that empowers the recipient AS with the choice of what they filter in an informed fashion for mutual benefit.

"DFZ provider to have to carry the longer prefixes *except you*"

Firstly that was a comment to the sub informed way some people work, however, my point is we have a legacy that can not be solved by new policy. We have to accommodate that legacy and the answer is not to say lets just go with a /48 no questions asked. Networks involve design and engineering, we can accommodate all peoples needs within a structure.

"And if you *do* carry ::/0 in your network from an upstream, this is all a moot point; filter away to whatever level your heart desires,"

You just agreed with me.

18

Hi,

I have been thinking some more. Could we not solve the problem of legacy assignments of /32s that have been split to /48 with no covering route out of a RIR block with a /32 minimum with relative ease. AS operators that choose to filter these RIR blocks on /48 minimum have no problems, ISPs that choose to filter on /32 minimum do as they loose visibility of these "island networks" aka no covering route.

If we were to extend peeringDB to add a field to indicate with there is a covering route or not, this could then be used to assign a peer to a peer-group with the associated filter as appropriate either permitting 48s or denying them. This enables the people that have deigned their networks in this fashion to indicate as such, and those who choose to use the information can accept their prefixes without having to accept any old 48.

Peering DB could then also publish a RegExp string from their database of all the ASes that have indicated no covering route. This could then be used, if desired, by an AS operator to filter his BGP sessions which are not directly with the end AS, transit or peering, enabling the deployment of a route-map that would match the RegExp and prefix length of 48 and permit these, then match the Regexp with a prefix length <>48 and deny all of that (because there shouldn't be any), and then match what is left on a filter list that selected on RIR minimums.

The island networks would be incentivised to register, those that choose to filter can, those that don't want to can accept all 48s. Filters can be used on RIR minimums and new assignments made out of the new non-contiguous address blocks with a 48 minimum size, and the legacy problem is handled. Everyone is happy. No technology needs to change and all that is needed is for someone such as peeringDB to keep a record of the ASes that indicate they don't have a covering route and this can be readily used when setting up direct peerings or used to construct a generic filter for all ASes in this category to be applied to other BGP sessions.

Thoughts.... RIPE seems to be saying its upto the community to decide policy, ours is a /32 minimum and we strongly recommend you don't de-agregate but we are not going to tell you you can't. The legacy of island networks is the only thing that forces this issue to be dealt with one way or the other as it is not possible for them as they currently have things setup to announce the covering route.

I think a BCP would be good that considered alternatives to the polarized debate of do or don't do minimum filters vs TE routes vs why should I carry your TE. I think something like the above could be simply implemented as an opt in system that could be used if operators choose to that would keep all three groups of AS operators happy.

Ben