Mailing List Archive: Cisco: NSP

BGP RT Constrained Route Distribution -joke???

Index | Next | Previous | View Threaded

adam.vitkovsky at swan

Jul 26, 2012, 2:27 AM

Post #1 of 5 (505 views)
Permalink

BGP RT Constrained Route Distribution -joke???

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
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

robert at raszuk

Jul 26, 2012, 9:10 AM

Post #2 of 5 (484 views)
Permalink

Re: BGP RT Constrained Route Distribution -joke??? [In reply to]

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
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

adam.vitkovsky at swan

Jul 27, 2012, 1:32 AM

Post #3 of 5 (488 views)
Permalink

Re: BGP RT Constrained Route Distribution -joke??? [In reply to]

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]
Sent: Thursday, July 26, 2012 6:11 PM
To: adam vitkovsky
Cc: cisco-nsp [at] puck
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
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

adam.vitkovsky at swan

Jul 27, 2012, 2:32 AM

Post #4 of 5 (485 views)
Permalink

Re: BGP RT Constrained Route Distribution -joke??? [In reply to]

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

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

robert at raszuk

Jul 27, 2012, 8:01 AM

Post #5 of 5 (485 views)
Permalink

Re: BGP RT Constrained Route Distribution -joke??? [In reply to]

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] Sent: Thursday, July 26, 2012 6:11 PM To:
> adam vitkovsky Cc: cisco-nsp [at] puck 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
>> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at
>> http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>
>
>
>

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads