Beloved Peers, Update to the TelstraClear Domestic Peering Prefix-List Please remove: 202.0.32.0/20 le 24 202.0.50.0/24 Please add: 202.0.32.0/19 le 24 202.37.137.0/24 Full list attached.
Is there some kind of war against aggregation I'm not aware of? Do all adjacent prefixes below really having different attributes that makes aggregation unreasonable? --cw On Thu, Aug 15, 2002 at 04:15:34PM +1200, Matt Camp wrote: ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.36.34.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.36.35.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.27.210.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.27.211.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.27.250.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.27.251.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.36.226.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.36.227.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.36.244.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.36.245.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.37.70.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.37.71.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.37.74.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.37.75.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.37.78.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.37.79.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.49.34.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.49.35.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.50.164.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.50.165.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.78.156.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.78.156.0/24 ? ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.78.158.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 202.78.159.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.64.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.65.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.66.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.67.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.68.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.69.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.70.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 203.99.71.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.32.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.33.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.34.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.35.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.36.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.37.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.38.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.39.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.60.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.54.61.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.110.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.111.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.186.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.187.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.72.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.72.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.73.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.74.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.75.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.76.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.77.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.78.0/24 ip prefix-list "TELSTRACLEAR-PEERING-NETWORKS" permit 210.55.79.0/24 - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Aug 15, 2002 at 04:09:13AM -0700, Chris Wedgwood wrote:
Is there some kind of war against aggregation I'm not aware of? Do all adjacent prefixes below really having different attributes that makes aggregation unreasonable?
It's not reasonable in general to make assumptions about filtering unless you are directly responsible for the advertisement policy. If there's ever a chance that an advertisement needs to be advertised as multiple long prefixes instead of (or as well as) a covering aggregate for reasons of inter-domain traffic engineering/site multihoming/whatever, then the filters in place need to be ready to accommodate that. Joe - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Aug 15, 2002 at 10:04:49AM -0700, Joe Abley wrote: If there's ever a chance that an advertisement needs to be advertised as multiple long prefixes instead of (or as well as) a covering aggregate for reasons of inter-domain traffic engineering/site multihoming/whatever, then the filters in place need to be ready to accommodate that. It seems unlikely that this is the case for all of these networks, especially /21s smashed into /24s. Perhaps I'm wrong. --cw - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Aug 15, 2002 at 12:54:39PM -0700, Chris Wedgwood wrote:
On Thu, Aug 15, 2002 at 10:04:49AM -0700, Joe Abley wrote:
If there's ever a chance that an advertisement needs to be advertised as multiple long prefixes instead of (or as well as) a covering aggregate for reasons of inter-domain traffic engineering/site multihoming/whatever, then the filters in place need to be ready to accommodate that.
It seems unlikely that this is the case for all of these networks, especially /21s smashed into /24s.
It's extremely common for edge networks to pre-arrange a capability to deaggregate in case they ever need to. Some large operators build deliberately permissive filters to accommodate this, without even being asked; the direct risk to the transit provider from rapid deaggregation can be mitigated by using prefix filters together with maximum prefix limits. Multi-homing by poking PA holes in aggregates and advertising the results in different directions can also require liberal filters at the transit provider boundary. None of these things necessarily correspond to instantaneous observed policy in the network at any particular time, anyway; at best, they represent hints to peers about what the future might hold, possibly, maybe. So the RIB would be a better place than the filter to point a finger at if you wanted to complain about route aggregation, but even then, unless you're standing close to the origin of the routes in question there's every chance that your criticism is misdirected. The argument that deaggregation is bad and wrong because it hurts the core is interesting right up until the point the customer decides to buy service somewhere else because you won't let them multi-home the way they want to. Joe - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Aug 15, 2002 at 01:14:14PM -0700, Joe Abley wrote:
It's extremely common for edge networks to pre-arrange a capability to deaggregate in case they ever need to.
Is this the case here? Does sending a prefix-list to a public mailing-list count for "pre-arrange"? If this is indeed the case would it not be better to send 10.0.0.0/21 le 24 as opposed to 24 individual statements? Does this not more clearly indicate this kind of intent?
The argument that deaggregation is bad and wrong because it hurts the core is interesting right up until the point the customer decides to buy service somewhere else because you won't let them multi-home the way they want to.
Is this the case here? Are all of the deaggregated /21s the result of this or even the result of giving better (potential) flow management? I really don't know, which in part was the reason for the original question. Lack of a smiley face does not necessarily imply criticism or a pointed comment :) --cw - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, 15 Aug 2002, Chris Wedgwood wrote:
Is this the case here? Are all of the deaggregated /21s the result of this or even the result of giving better (potential) flow management?
Actually in this case it looks like someone reverted the on-file prefix list to a previous (incorrect) version... There will be an update once this has been sanity checked (again). --- Matt Camp - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Fri, 16 Aug 2002, Matt Camp wrote:
On Thu, 15 Aug 2002, Chris Wedgwood wrote:
Is this the case here? Are all of the deaggregated /21s the result of this or even the result of giving better (potential) flow management?
Actually in this case it looks like someone reverted the on-file prefix list to a previous (incorrect) version... There will be an update once this has been sanity checked (again).
And of course you know what I'm going to say here! If you had your policy stored in an RPSL compliant database and generated all the filters from it, you might be less likely to do this sort of thing. And if that policy was in a publicly accessible RPSL database which was part of the IRR, Chris would have been able to look at the policy, seen that something was amiss and mailed the relevant contact person directly. andy - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Thu, Aug 15, 2002 at 01:34:35PM -0700, Chris Wedgwood wrote:
On Thu, Aug 15, 2002 at 01:14:14PM -0700, Joe Abley wrote:
It's extremely common for edge networks to pre-arrange a capability to deaggregate in case they ever need to.
Is this the case here?
I can't tell, and neither can you.
Does sending a prefix-list to a public mailing-list count for "pre-arrange"?
Nope. Sending a prefix-list to your transit provider counts as "pre-arrange". What you saw was something similar, but one tier distant from the origin route policy.
If this is indeed the case would it not be better to send
10.0.0.0/21 le 24
as opposed to 24 individual statements? Does this not more clearly indicate this kind of intent?
No.
The argument that deaggregation is bad and wrong because it hurts the core is interesting right up until the point the customer decides to buy service somewhere else because you won't let them multi-home the way they want to.
Is this the case here? Are all of the deaggregated /21s the result of this or even the result of giving better (potential) flow management?
I can't tell, and neither can you.
I really don't know, which in part was the reason for the original question.
Lack of a smiley face does not necessarily imply criticism or a pointed comment :)
Ditto :) Joe - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (4)
-
Andy Linton
-
Chris Wedgwood
-
Joe Abley
-
Matt Camp