Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-validating-bgp-speaker-00.txt

From: Daniel Kopp <[email-masked]>
Date: Tue, 6 Mar 2018 15:46:33 +0000

Hi everyone following draft-ietf-sidrops-validating-bgp-speaker and sirdops,

thanks to all people that provided their feedback on the last changes of the draft.
I would also like to join the discussion by giving my view on the draft as being a co-author.

Motivation:
The central motivation of the draft is to have a unified method to signal 
RPKI status of prefixes within the IXP domain. The drive for such an implementation 
came from customers side and the idea to have a RFC from the fact that some IXP started implementing this in some flavour. 

Last Update:
To recap, with the last major update we moved the signalling from non-transitive to being transitive.
This was done because we discussed that IXP being an EBGP domain the non-transitive feature would be a missfit. 
Additionally, the AS that validated the RPKI status would be added to the Global Administrator field.

Technical:
Now it seems that the new approach might also pose some greater challenges to be used by operators, 
when its necessary to implement features to signal the capability of this extension between routers. 
I think it would be good to collect more thoughts about this, additionally we’ll ask some vendors about their view.
On a side note, I personally like the idea of Jeff Wheeler to use a Well-Known Community, 
similar like it was done for RFC7999, which is also used in the context of IXPs.

About dropping RPKI invalids per default:
I think its clear that in theory dropping invalids as default would promote the hygiene of advertisements the most.
But if we make this the only mode of operation in the draft, the adoption for RPKI in IXPs would not be different from now. 
We wouldn’t even need to have a draft for that at all. Similar to that some IXPs are dropping AS announcements that don’t have their IRR entries set correctly.

About add-path:
It was mentioned several times that without Add-path path hiding can occur. I think it makes sense to have Add-Path as an option in the draft, 
and also it would be the ideal case to have the signalling of RPKI validation states with add-path as default, 
but currently not all devices and IXPs have this feature implemented.

Finally:
We want to use RPKI today at IXPs and by keeping the overall situation in mind, 
this draft describes what can be done and tires to achieve a common signalling.

I’ll be at the next IETF meeting and I’m looking forward to have some discussion their but also in advance.
Looking forward to you comments, input and discussion.

Best,
Daniel

> On 14. Feb 2018, at 23:39, Aris Lambrianidis <[email-masked]> wrote:
> 
> Hi Job,
> 
> Job Snijders wrote:
>> Hi,
>> 
>> I think a much safer mode of operation for BGP speakers is to reject
>> invalid announcements, rather than "tag with extended bgp community &
>> propagate".
>> 
> If RPKI adoption and know-how was widespread, I would agree. Sadly, this is not the 
> operational reality as I see it. The draft tries to be inclusive in its options as to
> promote RPKI adoption, but as stated in a previous email of mine, this is just one of its goals. 
> 
> >From a standardization standpoint (the other goal), offering less options on how operators deploy the 
> validating bgp speaker means less probability of widespread adoption, thereby
> defeating its purpose.
> 
> Furthermore, if we were to go directly with the safer mode of operation,
> we would lose operators who are on the fence about RPKI and its usefulness and 
> who want to maintain more granular control on what they receive before pulling the proverbial
> killswitch, taking into account what was mentioned in the first paragraph.
> 
> If it helps, I see the draft as an analogy to the migration steps taken with any new technology, i.e. installing
> firewalls or proxies in one's network. Typically they are first being placed in "bypass/monitoring"
> mode, and then they are configured to filter/drop traffic, after confidence of their operation has been gained. 
> 
> The draft in no way prohibits, and arguably even encourages, operators to offer different options for different customers.
> Customers who feel confident in the validating BGP speaker can simply select to reject invalid announcements.
> 
> Kind regards,
> Aris