Re: [GROW] [Sidrops] I-D Action: draft-ietf-sidrops-route-server-rpki-light-00.txt

[Marco Marzetti <[e-mail]>]

On Tue, Jan 17, 2017 at 12:10 AM, joel jaeggli <[e-mail]> wrote:
> On 1/15/17 6:35 AM, Marco Marzetti wrote:
>> On Sat, Jan 14, 2017 at 9:10 PM, joel jaeggli <[e-mail]> wrote:
>>> On 1/14/17 3:58 AM, Marco Marzetti wrote:
>>>> Joel,
>>>>
>>>> So you don't want your upstreams to honor RPKI just because they're
>>>> 3rd parties between you and the other end?
>>>
>>> An ixp route-server is not a transit provider, all of the nexthops
>>> exposed are in fact peers. So no I do not consider such a  device an
>>> "upstream" it exists to service the policy needs of the peers on the
>>> fabric  rather than that of the exchange operator.
>>>
>>
>> You can easily do the same in transit providers by disabling next-hop-self.
>
> Nope, The router expressing nexthop self retains the available nexthops.
> Under no circumstance is the router-server in the forwarding path, were
> it, the route-server would be an upstream.
>

That;s correct.
But is the specific device really relevant?

I mean: you send your traffic to another network's forwarding plane.
Do you really care about the role of the devices your packets pass through?

>>
>>> I would  expect that a ixp route server that had a state policy of
>>> validating rpki would not propagate invalid routes.
>>>
>>>> In the context of IXPs: instead of peering with the RS you should
>>>> setup direct sessions with your partners if you really want to do
>>>> prefix/path validation by yourself.
>
> Consider the case where the invalid route masks an valid but longer path
> from being advertised via the route server as the best path. in that
> case the validating route-server is facilitating a prefix hijacking
> which it would not have, had it discarded the route. You might argue
> that this is no worse than not validating, however I think that is a
> somewhat dubious point given that the rib on the route-server would show
> otherwise.
>

I argue that the same could happen with transit and we would consider it legit.
Why?

>>> No, I setup bilateral peering arrangements because they actually load
>>> balance to my multiple ports, because the loci of control is
>>> unambiguous, because it facilitates greatly build per session prefix
>>> filters, and because they converge the control and forwarding path,
>>> which has a tendency to fail much more gracefully in the face of l2
>>> failures in distributed exchange fabric designs then does the route-server.
>>>
>>
>> Aren't we saying the same thing?
>> Bilateral peering brings more control over what you send and receive.
>
> we have a similar concurrence respecting the advantages. We appear to
> differ on whether the route server offering a feature or not confers a
> similar outcome.
>
>> I just take an additional step and say that RPKI should be part of the
>> default decision process of RSs
>
> To confer the advantage you need to not allow invalid routes into your
> best path selection processing.
>

Again, I really do think that the same logic of transit applies here.

Regards


-- 
Marco