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: [email protected] [mailto:[email protected]] On Behalf Of adam vitkovsky Sent: Friday, July 27, 2012 10:32 AM To: [email protected] Cc: [email protected] 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:[email protected]] Sent: Thursday, July 26, 2012 6:11 PM To: adam vitkovsky Cc: [email protected] 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 [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
