Lukas,
CSCvc84848
Will keep you in the loop too, Lukas.
Regards,
Jakob.
-Original Message-
From: Lukas Tribus
Sent: Monday, February 3, 2020 12:43 AM
To: Mark Tinka ; Jakob Heitz (jheitz)
Cc: nanog@nanog.org
Subject: Re: Starting to Drop Invalids for Customers
Hello,
On Tue, 14
Hello,
On Tue, 14 Jan 2020 at 07:21, Mark Tinka wrote:
> On 13/Jan/20 21:53, Jakob Heitz (jheitz) wrote:
> > Mark,
> >
> > Thanks for bringing this up again.
> > I remember this from nearly 3 years ago when Randy brought it up.
> > A bug was filed, but it disappeared in the woodwork.
> > I have
On 13/Jan/20 21:53, Jakob Heitz (jheitz) wrote:
> Mark,
>
> Thanks for bringing this up again.
> I remember this from nearly 3 years ago when Randy brought it up.
> A bug was filed, but it disappeared in the woodwork.
> I have now given it the high priority tag that it should have had
Mark,
Thanks for bringing this up again.
I remember this from nearly 3 years ago when Randy brought it up.
A bug was filed, but it disappeared in the woodwork.
I have now given it the high priority tag that it should have had initially.
Sorry about the mess up.
In the meantime, you may be able
On 10/Jan/20 16:15, Lukas Tribus wrote:
> Thanks for sharing all this. Regarding those 2 platforms specifically,
> what release are you using here that does not blow up?
On the ASR920, we are on 16(11)01a.
On the ME3600X, we are on 15.6(2)SP6.
> IIRC you had
> some RPKI related crash bugs
Hello Mark,
On Fri, 10 Jan 2020 at 13:39, Mark Tinka wrote:
>
> So just an update on this.
>
> We've since completed the roll-out of dropping Invalids on eBGP sessions with
> customers as well.
>
> It also included some Cisco ME3600X routers that will ultimately be replaced
> this year by
So just an update on this.
We've since completed the roll-out of dropping Invalids on eBGP sessions
with customers as well.
It also included some Cisco ME3600X routers that will ultimately be
replaced this year by Cisco ASR920 routers.
All in all, no major drama. 2 main issues I'd like to
On 18/Dec/19 00:35, Randy Bush wrote:
>
> and how does that work out at scale when roa changes need previous bgp
> to be run against them?
If I'm honest, not something I've studied in great detail.
For the moment, we are running RPKI on IOS XE boxes that are doing just
peering. We have not
>> so junos and xr support rov sufficiently for production. cool!
> And IOS XE too...
and how does that work out at scale when roa changes need previous bgp
to be run against them?
randy
On 18/Dec/19 00:18, Randy Bush wrote:
>
> so junos and xr support rov sufficiently for production. cool!
And IOS XE too...
Mark.
>> but mark said customer-facing, which
>> could be reasonable depending on the platform. e.g. ntt uses irr-based
>> acls toward customers.
>
> So we have 4 main systems for customer edge termination:
>
> - MX480's, primarily used in the data centre.
> - ASR1006's, also primarily used
On 16/Dec/19 23:49, Randy Bush wrote:
> as i am pretty sure arturo knows all that. i suspect he was wondering
> if mark is gonna throw irr data in the mix the way chris says google
> will (or does?). and if so, how? seems a useful question.
No, we'll be focusing solely on RPKI.
>
> irr
[ found in old emacs buffer. might have already been sent ]
>> Invalid according to RPKI or IRR? Or both?
>
> In this context the use of the word “invalid” refers to the result of
> validation procedure described in RFC 6811 - which is to match received BGP
> updates to the RPKI and attach
Ah, right. Fair. I was responding, I suppose, to Rubens' original
description, which was exactly this.
On 12/11/19 5:08 PM, Christopher Morrow wrote:
> On Wed, Dec 11, 2019 at 11:35 AM Matt Corallo wrote:
>>
>> Right, but you’re also taking a strong, cryptographically-authenticated
>> system
On Wed, Dec 11, 2019 at 11:52 AM Rubens Kuhl wrote:
>
>
>
> On Wed, Dec 11, 2019 at 12:16 PM Christopher Morrow
> wrote:
>>
>> On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl wrote:
>> >
>> >
>> >>
>> >> > Which brings me to my favorite possible RPKI-IRR integration: a ROA
>> >> > that says that
On Wed, Dec 11, 2019 at 11:35 AM Matt Corallo wrote:
>
> Right, but you’re also taking a strong, cryptographically-authenticated
> system and making it sign non-authenticated data. Please don’t do that. If
> you want to add the data to RPKI, there should be a way to add the data to
> RPKI, not
On Wed, Dec 11, 2019 at 12:16 PM Christopher Morrow
wrote:
> On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl wrote:
> >
> >
> >>
> >> > Which brings me to my favorite possible RPKI-IRR integration: a ROA
> that says that IRR objects on IRR source x with maintainer Y are
> authoritative for a given
Right, but you’re also taking a strong, cryptographically-authenticated system
and making it sign non-authenticated data. Please don’t do that. If you want to
add the data to RPKI, there should be a way to add the data to RPKI, not sign
away control of your number resources to unauthenticated
On Wed, Dec 11, 2019 at 5:52 AM Rubens Kuhl wrote:
>
>
>>
>> > Which brings me to my favorite possible RPKI-IRR integration: a ROA that
>> > says that IRR objects on IRR source x with maintainer Y are authoritative
>> > for a given number resource. Kinda like SPF for BGP.
>> >
>>
>> Is this
Christopher Morrow wrote on 11/12/2019 03:45:
On Tue, Dec 10, 2019 at 7:32 PM Rubens Kuhl wrote:
Which brings me to my favorite possible RPKI-IRR integration: a ROA
that says that IRR objects on IRR source x with maintainer Y are
authoritative for a given number resource. Kinda like SPF for
>
> > Which brings me to my favorite possible RPKI-IRR integration: a ROA that
> says that IRR objects on IRR source x with maintainer Y are authoritative
> for a given number resource. Kinda like SPF for BGP.
> >
>
> Is this required? or a crutch for use until a network can publish all
> of their
On 10/Dec/19 21:47, Arturo Servin wrote:
> Mark
>
> Invalid according to RPKI or IRR? Or both?
According to RPKI.
Mark.
On 10/Dec/19 19:20, Randy Bush wrote:
>
> cool. any stats and lessons appreciated.
Will do, Randy.
Mark.
On Tue, Dec 10, 2019 at 7:32 PM Rubens Kuhl wrote:
>
>
>>
>> RPKI ROAs (compared to IRR objects) carry different meaning: the existence
>> of a ROA (both by definition and common implementation) supersedes other
>> data sources (IRR, LOAs, or comments in whois records, etc), and as such can
>>
>
> RPKI ROAs (compared to IRR objects) carry different meaning: the existence
> of a ROA (both by definition and common implementation) supersedes other
> data sources (IRR, LOAs, or comments in whois records, etc), and as such
> can be used on any type of EBGP session for validation of the
Dear Arturo, group,
On Tue, Dec 10, 2019 at 20:51 Arturo Servin wrote:
>
> Invalid according to RPKI or IRR? Or both?
>
In this context the use of the word “invalid” refers to the result of
validation procedure described in RFC 6811 - which is to match received BGP
updates to the RPKI and
Mark
Invalid according to RPKI or IRR? Or both?
Regards
as
On Tue, 10 Dec 2019, 18:22 Randy Bush, wrote:
> mark,
>
> > Just to let this group know that we've started the process of
> > activating the dropping of Invalids for all our eBGP customers.
>
> cool. any stats and lessons
mark,
> Just to let this group know that we've started the process of
> activating the dropping of Invalids for all our eBGP customers.
cool. any stats and lessons appreciated.
randy
28 matches
Mail list logo
