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

[Chris Morrow]

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