nested prefixes in Internet

Mon Oct 10 16:16:56 UTC 2016

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 <fw at 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.
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20161010/dfc14612/attachment.sig>