[c-nsp] BGP RT Constrained Route Distribution -joke???

[adam vitkovsky]

I guess what it boils down to is the following:

Consider RRs chain like this:
a-b-c-d
where: 
d advertises RT 1
c advertises RT 2
b advertises RT 3

in case of RTC RR-a would have following info:
d advertised RT 1
c advertised RT 2
b advertised RT 3

in case of ORF RR-a would have following info:
b advertised RT 1,2,3

whether it's necessary to have the whole topological information when a
sends routing updates to b I'm not sure


adam

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of adam vitkovsky
Sent: Friday, July 27, 2012 10:32 AM
To: robert at raszuk.net
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BGP RT Constrained Route Distribution -joke???

Robert,
Well my question is basically what where the reasons for implementing it as
a new AFI/SAFI instead of extending support of the existing ORF capability
type 128(Prefix-list) with types 1, 2 and 3 (NLRI, community and
extended-community respectfully)

Does the AFI/SAFI approach work better with update replication
(update-groups) please?

I guess the initiative was to make the information concerning suitability of
prefix advertisement spread systems wide rather than constrain it to the
session between two BGP speakers However I struggle to understand where, in
which cases, it is better compared to the hop-by-hop approach with ORF Maybe
in cases where there's a RR hierarchy between the RR-Clusters in the
particular Intra/Inter-AS-RR-Plane? (but in my opinion this is not an
optimal design anyway)


adam
-----Original Message-----
From: Robert Raszuk [mailto:robert at raszuk.net]
Sent: Thursday, July 26, 2012 6:11 PM
To: adam vitkovsky
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BGP RT Constrained Route Distribution -joke???

Adam,

RTC is a new AFI/SAFI. That's why it is enabled like any other AFI/SAFI in
IOS.

Best,
R.

> I've just learned that instead of simple per neighbor cmd. that could 
> have been configured under the "template peer-policy" or "af-group":
>
> neighbor ip-address capability orf route-target  [send | receive | 
> both]
>
>
> We got this ridiculous afi:
>
> address-family rtfilter unicast
> neighbor ip-address activate
> neighbor ip-address send-community extended
>
> are there any advantages in this type of implementation that I'm missing?
>
>
> adam
>
>
> _______________________________________________
> 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/
>
>


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