[c-nsp] ASR opinions..

[Vitkovsky, Adam]

Hi Robert,

I see, sorry bout that 
Now I got your point :)
And you're right it's always better to keep thinks as simple as possible when/where we can

adam

-----Original Message-----
From: Robert Raszuk [mailto:robert at raszuk.net] 
Sent: Wednesday, August 31, 2011 7:03 PM
To: Vitkovsky, Adam
Cc: mtinka at globaltransit.net; Mack McBride; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASR opinions..

Hi Adam,

> However I'm not sure about the unnecessity to advertise the PE
> loopbacks as the NHs for VPNv4 routes between the ASNs

Of course this is necessary. And better this to be carried in BGP 3107
rather then redistributing to the IGP at ASBRs. That why I have clearly
distinguished PE loopbacks from RR loopbacks treatment.

Best regards,
R.

> Hello Robert,
> 
> I believe I understand what you mean and I see that without the
> bgp-ipv4+label sessions RRs don't need to encapsulate the ip packet
> with a label on the first hop towards the core and thus there's no
> need to enable mpls on the interfaces towards the core So the
> sessions between the inter-as-rrs in different ASNs can be built over
> the pure ip And in case the P-core routers have the routes for remote
> AS RRs than a default route from Inter-AS-RRs toward the P-core
> routers is sufficient
> 
> 
> However I'm not sure about the unnecessity to advertise the PE
> loopbacks as the NHs for VPNv4 routes between the ASNs
> 
> Let's say you are not changing the VPNv4 route's next hops anywhere
> throughout the control-plane path (option C) -so that the RRs stays
> off the data-path
> 
> PEs will announce them selves as the next-hops for the VPNv4 routes 
> -these will be advertised to Intra-AS-RRs from there they are
> advertised to local AS PEs and Inter-AS-RRs - next-hop unchanged
>> From the local AS Inter-AS-RRs the VPNv4 routes are than advertised
>> via eBGP sessions to other Inter-AS-RRs in different ASNs -
>> next-hop unchanged
> Than within the remote ASNs Inter-AS-RRs would advertise the VPNv4
> routes to PEs within that particular AS - next-hop unchanged
> 
> Now the PEs have the VPNv4 prefixes with a next hop of the PE from a
> remote AS -that's for the control plane
> 
> Now the data packet needs to be forwarded from the local AS PE to the
> remote AS PE But since the NH for the VPNv4 route can't be found in
> the local RIB I believe the route would most likely not even make it
> from the VPNv4-BGP-table to the ipv4-VRF-table on the PE so the
> data-plane forwarding fails
> 
> 
> adam
> 
> -----Original Message----- From: Robert Raszuk
> [mailto:robert at raszuk.net] Sent: Wednesday, August 31, 2011 5:15 PM 
> To: Vitkovsky, Adam Cc: mtinka at globaltransit.net; Mack McBride;
> cisco-nsp at puck.nether.net Subject: Re: [c-nsp] ASR opinions..
> 
> Hello Adam,
> 
> Please see inline ...
> 
>> Hi Robert,
>> 
>> Yes please I was referring to pure control plane RRs and bgp-free 
>> core
>> 
>> For Intra-AS-RRs to create sessions with PEs other Intra-AS-RRs
>> and Inter-AS-RRs within the AS -the RRs would advertise their
>> loopbacks via isis or ospf -and set the overload bit or
>> maximum-metric respectively -so that they are not on the
>> datapath(NH-unchaged by default) -as you mentioned static-routes
>> and NH-tracking in favour of IGP works For VPNv4 -RIB is not
>> populated as there are no vrfs configured on RRs For IPv4 -we can
>> use the table-map filter
> 
> Ok this is clear.
> 
>> What I was talking about where sessions between Inter-AS-RRs in 
>> different ASNs Long storry short -to establish ebgp session with
>> one another over the bgp-free core within each AS -there has to
>> exist an end-to-end LSP between the Inter-AS-RRs It's like you
>> always need a sort of data-plane to carry the control-plane
>> sessions
> 
> I disagree you need an LSP to establish an eBGP sessions. eBGP
> multihop session will get establish just fine between loopbacks of
> RRs in different ASes over pure IP routing. So from RR point of view
> single default to a core box which given RR is attached is
> sufficient. Carrying as many /32s in your IGP as your Inter-AS Option
> C RR peers is never an issue.
> 
> Also RR loopback address has to be known in the local AS IGP but I
> guess this is obvious as all clients will need to peer with it
> anyway. So that means that IGP will have also those few extra
> loopbacks for remote RRs.
> 
>> In Inter-AS-MPLS-VPNs option C For Inter-AS-RRs to create sessions 
>> with Inter-AS-RRs in other ASNs as well as to keep the
>> Inter-AS-RRs off the datapath (NH-unchanged) -the local AS has to
>> have a knowledge of the PE loopbacks(as NHs) and Inter-AS-RR
>> loopbacks(as eBGP session src/dst) from the remote ASNs
>> 
>> You can exchange this loopbacks/NHs via BGP-ipv4 + lables between 
>> ASNs at the ASBRs And at the ASBRs -you can either redistribute
>> this information to the local AS IGP -and let the IGP/LDP to
>> distribute this information to all routers within the local AS
>> including P-cores
> 
> Exactly - that would be my recommendation. But only to RR loopbacks.
> PEs loopbacks (which are vpnv4 next hops) would still not be
> redistributed into the IGP and carried with labeled BGP.
> 
>> Or you can use BGP-ipv4 + label + NH-self sessions -to distribute
>> the remote AS loopbacks from ASBRs only to where it's necessary
>> over the bgp-free core That is from/to PEs -so they can route the
>> data-trafic towards the PEs in remote ASNs And from/to Inter-AS-RRs
>> so they can establish VPNv4 sessions to Inter-AS-RRs in differnet
>> ASNs
> 
> I understand now what you are describing. That's doable but a bit 
> fragile as now for your ebgp sessions to external RRs you depend on
> two components .. 3107 in BGP as well as LDP/IGP. I really see no
> need to run LDP on the control plane RRs for only saving injection of
> few /32s into your IGP. Only few as you do not need to inject PEs
> from other ASes .. you only need to inject RRs from other ASes with
> is at most a few hosts routes.
> 
>> In either case you need the LSP to exist between the Inter-AS-RRs
>> So tht they can establish the eBGP sessions with one another
> 
> Not in the former pure IP case.
> 
> 
>> Inter-AS-RRs----------------------VPNv4-------------------------Inter-AS-RRs
>>
>>
>
>> 
Inter-AS-RRs--ipv4+label--ASBR--ipv4+label--ASBR--ipv4+label--Inter-AS-RRs
>> I-AS-RRs-igp+ldp-P-igp+ldp-ASBR            ASBR-igp+ldp-P- 
>> igp+ldp-I-AS-RRs
>> 
>> -of course you can utilise your Intra-AS-RRs to distribute the 
>> loopbacks + lables from ASBRs to all the PEs and Inter-AS-RRs
>> within the local AS
> 
> So to summarize what you are doing will work however IMHO I would
> not establish ebgp sessions between Inter-AS option C RRs the way you
> are proposing. I would keep the eBGP RR multihop sessions running
> over pure IP, I would not even enable LDP on control plane RRs and
> would carry few extra loopback addresses in my IGP.
> 
> Cheers, R.
> 
> 
> 
>> adam -----Original Message----- From: Robert Raszuk 
>> [mailto:robert at raszuk.net] Sent: Wednesday, August 31, 2011 2:15 PM
>>  To: Vitkovsky, Adam Cc: mtinka at globaltransit.net; Mack McBride; 
>> cisco-nsp at puck.nether.net Subject: Re: [c-nsp] ASR opinions..
>> 
>> Hi Adam,
>> 
>> The discussion is about control plane RRs.
>> 
>> Therefor in control plane RRs you do not need to have any LSP on 
>> those nor populate 3107 to RIB/LFIB. A default will work equally
>> well for Next Hop Tracking to consider your BGP next hops as valid
>> in any address family (if that is your concern).
>> 
>> Of course if you would set next hop self on such RRs and start/end 
>> LSP there making it to be a dataplane box of course you better
>> feed the LFIB but not otherwise.
>> 
>> Cheers, R.
>> 
>> 
>>> Right the default route would work nicely with bgp free core and
>>> no IGP on the Intra-AS-RRs But it won't work for Inter-AS-RRs
>>> Because you don't wan the local AS IGP to be "polluted" with the
>>> remote ASNs PEs and Inter-AS-RRs loopbacks so you rather want to
>>> carry those in bgp-afi-ipv4 + labels In this case you need the 
>>> bgp-ipv4-afi to feed the FIB and LFIB on the Inter-AS-RRs As you 
>>> need the end to end LSPs in order to setup sessions between 
>>> Inter-AS-RRs in different ASNs
>>> 
>>> 
>>> adam
>>> 
>>> -----Original Message----- From:
>>> cisco-nsp-bounces at puck.nether.net 
>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mark
>>> Tinka Sent: Tuesday, August 30, 2011 6:33 AM To: Mack McBride
>>> Cc: cisco-nsp at puck.nether.net Subject: Re: [c-nsp] ASR
>>> opinions..
>>> 
>>> On Tuesday, August 30, 2011 03:08:17 AM Mack McBride wrote:
>>> 
>>>> I would recommend a default to the core from the device to 
>>>> achieve ping/traceroute.
>>> 
>>> Not necessary - the majority of troubleshooting cases will be
>>> for customers in the network. We run a BGP-free core, but the
>>> route reflectors have direct access to the edge, so IP forwarding
>>> would suffice.
>>> 
>>> Mark.
>>> 
>>> _______________________________________________ cisco-nsp
>>> mailing list  cisco-nsp at puck.nether.net 
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at 
>>> http://puck.nether.net/pipermail/cisco-nsp/
>>> 
>>> 
>> 
>> 
>> 
> 
> 
>