[j-nsp] Migration from IGP to e-BGP

[tim tiriche]

Thank you everyone.  I will be going for confederations.

Sincerely,
-Tim

On Sun, Dec 30, 2012 at 1:19 PM, Chris Morrow <morrowc at ops-netman.net> wrote:
>
>
> On 12/30/2012 12:31 PM, tim tiriche wrote:
>> I didn't mean confederations.
>>
>
> yes you did, according to your diagram...
>
>> May be a diagram would be better.
>>
>> Current design: (ASN: 1234)
>>
>> (Customer-A) --(ebgp) --[[ (Area 10) --- (Area 0) --- (Area 20) ]]--
>> (ebgp)-- (Customer-B)
>>
>> IGP is running in Area 0 for P2P and loopbacks.
>> Area10, Area0 and Area20 are part of one Administravie domain
>> representing ASN: 1234.
>> Area10, Area20 has its own customers.
>>
>>
>> New Proposed design:
>>
>> Remove Area10 and Area20 and instead use E-BGP.
>
> this sort of sounds like the wrong hammer to be using... to me at least.
>
>> Area10 would become ASN65010, Area20 would become ASN65020 and run
>> their own IGP.
>
> why? don't you want the edge device(s) in 20/10 to be able to benefit
> from the whole IGP knowledge across your domain? breaking things up into
> different igps seems more complicated than it needs to be, to me.
>
>> ASN65010 would be a customer of ASN1234.
>>
>
> yea.. no.
> I really think you mean that the confed-as is 1234 and
> 65010/65020/65<core> are all parts of the confederation. If done this
> way your customers continue to be peered with 1234 and you just migrate
> things to a more stable/scalable solution over a few weeks work.
>
>> Problem:
>> If Area10 becomes ASN65010, what happens to the customer who peers with ASN1234?
>> I still want the customer to peer with ASN1234 and customer should not
>> be aware of ASN65010.
>
> right, that's what confederations are for (well, one purpose of them).
>
> The OTHER option is to use some of the whackitude that is 'peer-as' in
> the juniper world and hide your ASN change from the customers... this
> has longer term maintenance headache implications, and most uses of it
> are for M&A situations: "We just bought AS12, let's make them part of
> our AS: AS1, and slowly convert all customers we can talk to, meanwhile
> 'peer-as' all customer sessions so they appear to still connect to AS4,
> while the edge devices are re-homed into AS1"
>
> it's messy and will cause operations problems in the long term...
>
> -chris
>
>
>>
>> Sincerely,
>> -Tim
>>
>>
>>
>> On Fri, Dec 28, 2012 at 10:33 PM, Christopher Morrow
>> <morrowc at ops-netman.net> wrote:
>>> (Android mail sucks, sorry)
>>>
>>> I think the OP means confederation not 'private islands'.... And they'll have to do some planning to move to confederations.
>>>
>>> More importantly, why get rid of your igp? Are you not already doing route reflection and/or ibgp full mesh ?
>>>
>>> "Justin M. Streiner" <streiner at cluebyfour.org> wrote:
>>>
>>>> On Fri, 28 Dec 2012, tim tiriche wrote:
>>>>
>>>>> We have multi area OSPF and would like to migrate the multi area to
>>>>> private ASN BGP islands.
>>>>
>>>> How are you defining an 'island'?
>>>>
>>>>> Main ASN:1234
>>>>>
>>>>> Problem:
>>>>>
>>>>> In the current OSPF areas there is an e-BGP Peering and Transit with customer.
>>>>> After migration, how can i ensure that customer peer using the Main
>>>>> ASN:1234 and transport it over the core?
>>>>
>>>> "Peering" and "Transit" mean two different things to a number of people
>>>> who read this mailing list.  I'm guessing you mean one or the other (most
>>>> likely transit)?
>>>>
>>>> If the customers speak eBGP with you today, and your end of the session is
>>>> in AS1234, then the customer's traffic will transit AS1234, depending on
>>>> what you do with the traffic while it's on your network.  If I'm
>>>> understanding your intentions correctly, what do you hope to gain, or what
>>>> problem are you trying to solve by creating 'private ASN BGP islands'?
>>>>
>>>> If the issue is reducing the number of IBGP sessions on your backbone,
>>>> have a look at route reflectors and BGP confederations.
>>>>
>>>>> How have others done it?
>>>>
>>>> In my past life, we spoke eBGP with our downstream customers.  Either the
>>>> customers had their own public ASN, or we used another public ASN that we
>>>> had available at the time.  Private ASNs were used in a few corner cases.
>>>> The latter two approaches impose limitations that might not be acceptable
>>>> for some customers.  YMMV.
>>>>
>>>> jms
>>>>
>>>>> Loops, local-as? Would independent domain help?
>>>>>
>>>>> Looking for suggestions.
>>>>>
>>>>> Sincerely,
>>>>> -Tim
>>>>> _______________________________________________
>>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>>
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp