The 'AND' Logic in RPL ?

[Mark Pace Balzan]

Hi,

i came across a situation which gets me to ask about a detail of RPL logic which is deceiving me.

Im mostly running asr9k with 5.1.3 or 5.2.4 in the lab although I doubt my query is platform specific

So, If I apply RPL inbound on a BGP session upstream from where I receive a number of prefixes including default, how does XR/RPL handle the following ?

if destination in (1.0.0.0/24) and destination in (2.0.0.0/24) then
  pass

does the above even make sense logically, as in does the RPL examine one prefix at a time in the BGP feed ?  If so 1.0.0.0/24 can never be 2.0.0.0/24, unless the RPL says I will accept 1.0.0.0/24 since I also have 2.0.0.0/24 being advertised to me via BGP from this same peer ?

Quick test in the lab actually accepts 1.0.0.0/24 and installs it in FIB, so Im a little bit confused about the logic, since even if the parser allowed commit for something seeming illogical, XR is also generally a normally closed, deny all approach, as opposed to IOS, so I would have expected not to see prefix in FIB, but Im clearly missing something

cheers

Mark

[AARON WEINTRAUB]

RPL should be parsed a route element at a time, of the 25k routes you might get from a peer, they should never interact with one another in the RPL.  I think that if you have just the RPL above you have posted and the route 1.0.0.0/24 gets entered into the RIB, I think that is an error/bug.  I don't see anything wrong particularly with your RPL, because there's nothing wrong with calling out different prefix-sets in different locations.  I.e., RPL towards peer A, use prefix-set 1 and 2, RPL towards peer B, use prefix-set 2 and 3.  Obviously using two prefix-sets that have no intersecting elements in an AND match is a little bit absurd and unlikely to appear in real life, but that's irrelevant to how it should behave.

[Mark Pace Balzan]

thanks for your feedback Aaron

I was trying to build some logic around "accept prefix (1) if prefix (2) is present"

I agree that this would make no sense if the RPL is processed prefix at at time from the BGP peer, which was my suspicion, but was worth a shot, especially since prefix was accepted in the lab !

thanks

Mark

[AARON WEINTRAUB]

You might look into some other elements though - like 'rib-has-route' would enable the RPL to look through the entire rib as an AND condition to look for a route, but I don't know of a way to constrain that element to routes from a certain peer only.