Hi Adam,
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
The main reason is the issue that ORF is p2p while new AFI/SAFI can
be advertised normally as far as it is needed without worrying of control
plane loops.
Keep in mind that RTC originally was targeting inter-as peering
automation between any number of arbitrary AS-es participating in common
service.
Later we discovered that it is also quite useful intra-domain .. in
particular to allow incremental update for other AFI/SAFIs it is serving.
Best regards,
R.
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/
