On 10/10/16 9:04 AM, Roy wrote: > > > The solution proposed allows ISP-B to use both paths at the same time, > needs ISP-C to minimal changes, and has low impact on the global > routing tables.. I have successfully used it in the past and my old > company is still using it today.
Having two parties in control of a prefix announcement is a bit of a disaster. ISP A becomes partitioned from isp B isp B does not withdraw the covering aggregate and black-holes the of ISP A that lands on it's edge. bummer. > > .On 10/9/2016 11:50 PM, Martin T wrote: >> Florian: >> >> as I told in my initial e-mail, ISP-B is multi-homed, i.e connected to >> ISP-A(who leases the /24 to ISP-B from their /19 block) and also to >> ISP-C. ISP-B wants to announce this /24 both to ISP-A and ISP-C. >> That's the reason why either solution 1 or 2 in my initial e-mail is >> needed. >> >> However, I would like to hear from Roy and Mel why do they prefer a >> third option where ISP A announces the /19 and the /24 while ISP B >> does just the /24. >> >> >> thanks, >> Martin >> >> On Wed, Oct 5, 2016 at 11:50 PM, Florian Weimer <f...@deneb.enyo.de> >> wrote: >>> * Martin T.: >>> >>>> Florian: >>>> >>>>> Are the autonomous systems for the /19 and /24 connected directly? >>>> Yes they are. >>> Then deaggregation really isn't necessary at all. >>> >>>>> (1) can be better from B's perspective because it prevents certain >>>>> routing table optimizations (due to the lack of the covering prefix) >>>> What kind of routing table optimizations are possible if covering /19 >>>> prefix is also present in global routing table? >>> The /24 prefix could arguably be dropped and ignored for routing >>> decisions. >
signature.asc
Description: OpenPGP digital signature