[c-nsp] ASR opinions..

[Vitkovsky, Adam]

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/
>> 
>> 
> 
> 
>