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/
