(bcc: iesg-secretary)
SIDR folk,
A draft agenda for the April 30, 2012 meeting is below:
0900-1200 deployment discussion (walkthrough/document/discuss deployment
scenarios)
1300-1600 o router/prefix/roa/crl - rpki repository data freshness
1600-1700 prefix validate discussion
This will
On Apr 9, 2012, at 2:50 PM, Robert Raszuk wrote:
Hi,
And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
I do not understand. How a BGP Update will transit via an AS where each
router is a real BGP speaker and where as some proposed BGP mandatory AS_PATH
attribute is
Hi Warren,
Many thx for your comment. It clarifies my question very well.
So you are effectively confirming that as long as there is one ASBR, one
RR or one confederation edge which does not yet speak BGPSEC anywhere in
the UPDATE path the peer sending to him over ebgp or ibgp will convert
On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk rob...@raszuk.net wrote:
Anyhow my doubt has been answered and I stay by my opinion that not sending
AS_PATH and AS4_PATH is a terrible idea.
So... we can send the data along, but in the case of BGPSEC speakers
the data isn't used (it's replicated
So... we can send the data along, but in the case of BGPSEC speakers
the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
So far I have always heard that BGPSEC is just providing the hint to the
operator and does not change how BGP works.
Here you are saying that now AS_PATH
On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote:
On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk rob...@raszuk.net wrote:
Anyhow my doubt has been answered and I stay by my opinion that not sending
AS_PATH and AS4_PATH is a terrible idea.
So... we can send the data along, but in the
On 4/10/12 1:37 PM, Warren Kumari war...@kumari.net wrote:
On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote:
On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk rob...@raszuk.net
wrote:
Anyhow my doubt has been answered and I stay by my opinion that not
sending
AS_PATH and AS4_PATH is a
On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk rob...@raszuk.net wrote:
So... we can send the data along, but in the case of BGPSEC speakers
the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
So far I have always heard that BGPSEC is just providing the hint to the
operator and
Hi Warren,
Not seeing the problem/error does not mean it is not there.
I would in fact encourage in the initial years of deployment to use both
to easily detect bugs and inconsistency issues.
In my view we should do all BGP processing based on legacy attributes
and BGPSEC should be a hint
All BGP monitoring tools need to be upgraded to now understand BGPSEC
attribute too. And surprise .. here BMP will not convert it like it will to
legacy speakers.
sure, they'd have to do that anyway, or they just are
'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
other
On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow wrote:
On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk rob...@raszuk.net
wrote:
Anyhow my doubt has been answered and I stay by my opinion that not
sending AS_PATH and AS4_PATH is a terrible idea.
So... we can send the data along,
We just released a new version of our relying party software, RIPE NCC RPKI
Validator 2.0.4:
http://www.ripe.net/lir-services/resource-management/certification/tools-and-resources
We improved the way errors and warnings are displayed, they now have a separate
page with (hopefully) clear
On Tue, Apr 10, 2012 at 1:49 PM, Robert Raszuk rob...@raszuk.net wrote:
In my view we should do all BGP processing based on legacy attributes and
BGPSEC should be a hint to the local operator on how to treat the update.
i think that's the point of the current spec though... inbound updates
(on
On Tue, Apr 10, 2012 at 1:57 PM, Robert Raszuk rob...@raszuk.net wrote:
All BGP monitoring tools need to be upgraded to now understand BGPSEC
attribute too. And surprise .. here BMP will not convert it like it will
to
legacy speakers.
sure, they'd have to do that anyway, or they just are
On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz jakob.he...@ericsson.com wrote:
On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow wrote:
On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk rob...@raszuk.net
wrote:
Anyhow my doubt has been answered and I stay by my opinion that not
sending
On Tuesday, April 10, 2012 2:05 PM, Christopher Morrow wrote:
On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz
jakob.he...@ericsson.com wrote:
On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow wrote:
On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk rob...@raszuk.net
wrote:
Anyhow my
On Tue, Apr 10, 2012 at 8:48 PM, Danny McPherson da...@tcb.net wrote:
Chris,
Can you expand on these, I'm not sure I know what to read or propose in order
to prepare..
yes, my goal was to have updated the wiki today at the office, work
intruded... tomorrow I'll do that with some more content
On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:
yes, my goal was to have updated the wiki today at the office, work
intruded... tomorrow I'll do that with some more content for each
item, and hopefully better coordinates as well for the location.
Thanks.
Also, are we collecting
18 matches
Mail list logo
