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

[adam vitkovsky]

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