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

[tim tiriche]

I didn't mean confederations.

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.
Area10 would become ASN65010, Area20 would become ASN65020 and run
their own IGP.
ASN65010 would be a customer of ASN1234.

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.


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