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

[Robert Raszuk]

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