Subject: Re: [i2rs] RPF and draft-ietf-i2rs-rib-info-model-08

From: Nitin Bahadur <[email-masked]>
Date: Tue, 02 Feb 2016 16:26:53 -0800

Hi Russ,

   Can you expand on the 2 sorts of RPF checks already out there. And then
we can figure out which ones we need to include for now. If need be, then
we can make RPF check into an object as you are suggesting.

Thanks
Nitin

On 1/30/16, 5:28 PM, "i2rs on behalf of Russ White" <[email-masked]
on behalf of [email-masked]> wrote:

>Y'all --
>
>draft-ietf-i2rs-rib-info-model-08 says --
>
>==
>Each RIB can be optionally associated with a ENABLE_IP_RPF_CHECK attribute
>that enables Reverse path forwarding (RPF) checks on all IP...
>==
>
>But there are at least two sorts of RPF checks already, and will probably
>be
>more in the future. This might need to be expanded a bit to cover all the
>cases, or have a subcode, or some such.
>
>:-)
>
>Russ
>
>_______________________________________________
>i2rs mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Russ White" <[email-masked]>
Date: Tue, 2 Feb 2016 19:33:15 -0500

> we can make RPF check into an object as you are suggesting.

Sure -- There is loose (just check to see if you have it in your table at
all) and strict (check to make certain this destination's best path is
through this interface). There is one more that could be tied to BGP
security, and there are potentially others that could be tied to overlay
networks, and potential solutions for load balancing in the future. It just
seems to me this is a broader space than a single flag can cover, and it's
possible more solutions could be used in this space beyond the two we have
already, so it probably makes sense to make this extensible.

:-)

Russ

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Feb 2016 00:39:01 +0000

Hi Russ, 

On 2/2/16, 7:33 PM, "i2rs on behalf of Russ White" <[email-masked]
on behalf of [email-masked]> wrote:

>through this interface).

What do you mean “in your table at all”? The RIB normally only includes
the best path for each RIB client. RPF is normally only on the best path.

> There is one more that could be tied to BGP

There are NO implementations that query BGP for a path in any acceptable
Adj-RIB-In for the RPF check. I’m not sure what you are envisioning.

Thanks,
Acee

---

From: "Russ White" <[email-masked]>
Date: Tue, 2 Feb 2016 21:09:45 -0500

> What do you mean “in your table at all”? The RIB normally only includes the
> best path for each RIB client. RPF is normally only on the best path.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_urpf/configuration/15-s/sec-data-urpf-15-s-book/sec-unicast-rpf-loose.html

This is implemented in virtually every OS I know of in some way -- and it's different from --

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/srpf_gsr.html

> > There is one more that could be tied to BGP security, and there are
> >potentially others that could be tied to overlay networks, and
> >potential solutions for load balancing in the future. It just seems to
> >me this is a broader space than a single flag can cover, and it's
> >possible more solutions could be used in this space beyond the two we
> >have already, so it probably makes sense to make this extensible.
> 

Not right now -- I'm just saying there are other possibilities here beyond the two I already know about, so it might be wise to allow for more in the future with something other than a single bit flag.

:-)

Russ