[ first, i do not use route serves (because of the data/control non-
congruence), so my opinion here is worth even less than it normally
is. ]
> 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
>
Matthias Waehlisch wrote:
> the current discussion makes clear that documentation of
> origin-validation-signaling in IXP context is needed
rpki is conceptually no different to any other type of signaling
mechanism: it's simply another input into the BGP decision engine
process, just like
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
backup up a tad... somehow *(probably late-work-night clicking) I added
joel/marco to the 'reject mail' list :( (note that both are now subscribed
to the list.. if you do not want that you should go unsubscribe)
I'm sorry there were 4 messages, copied here, which didn't make it to
sidrops@
On Sat, 14 Jan 2017, Nick Hilliard wrote:
> Matthias Waehlisch wrote:
> > I think there are two cases: (1) RS client peers only with route
> > server, (2) RS client peers additionally with other BGP speakers that
> > don't peer with the RS.
> >
> > In case (1) (and assuming that the RS
Marco Marzetti wrote:
> Why RPKI can't be part of that?
tl;dr: route servers and rpki are an uncomfortable fit.
rpki can be part of that, but it's problematic because the route server
is running the routing decision engine on the part of the client. RPKI
is a relatively fine-grained tool in the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations of the IETF.
Title : Multi-Threaded Routing Toolkit (MRT) Routing
Information Export Format with BGP Additional Paths Extensions
Christopher,
As Nick has already pointed out as soon as you peer with the RS you've
already delegated some part of the decision process to the IXP.
Why RPKI can't be part of that?
After all there are IXPs that filter advertisements not covered by IRR
route objects.
Regards
On Fri, Jan 13,
Joel,
So you don't want your upstreams to honor RPKI just because they're
3rd parties between you and the other end?
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.
Regards
Hi Nick,
interesting. You are arguing who is doing the best path selection for
a specific prefix.
I think there are two cases: (1) RS client peers only with route
server, (2) RS client peers additionally with other BGP speakers that
don't peer with the RS.
In case (1) (and assuming
10 matches
Mail list logo
