In the SIDR meeting, the interim meeting proposed for Sep was discussed.
The IETF plans are now to hold the meeting on Sat 29 Sep (the Sat after
RIPE).
All decisions must be confirmed on the list, so I ask for confirmation of
the meeting decision in favor of this meeting.
Speaking as a regular ol' member
This also matches a thought that I just sat down to write up.
Record the usual AS_PATH type in the signature attribute, meaning that the
internally added AS_PATH elements get marked as AS_CONFED_SEQ and get stripped
as such at the confed border, just as for
As I noted at the mic, I’d much prefer that we find a place to incorporate the
information in this draft into an existing draft(s). I don’t understand the
need for having this info separated in yet another draft and therefore do not
support adoption. I think the information is useful, just
I would be interested in seeing the issue below resolved in definitive
language (maybe someplace stronger than the CP template).
While I think the spirit of this draft was to show techniques that could
be useful during incremental/partial deployment, there are some folks
highly concerned about
The meeting minutes were collected on the etherpad tool and are available at:
http://tools.ietf.org/wg/sidr/minutes
For convenience, below is a copy of the text.
--Sandy
SIDR
August 1, 2012
Note takers: John Scudder
(Times provided for correlation with audio recording.)
(No attempt made to
Yes, having an interim in conjunction with RIPE is a good idea. 29 Sept
is fine.
On 8/2/2012 4:23 PM, Murphy, Sandra wrote:
In the SIDR meeting, the interim meeting proposed for Sep was discussed.
The original proposed date was 23 Sep, intended to take advantage of IETF plans
to hold a large
I also think this works.
Additionally, this has the benefit of being easy to write-up (I can
easily construct the delta from the current text). :-
On 8/3/2012 3:34 PM, Randy Bush wrote:
One other option does occur to me however, and I'm not sure why I
didn't think of it before: for *every*
Sandy,
Just upload the old version as draft-sidr-bgpsec-rollover-00.
Link: http://www.ietf.org/id/draft-sidr-bgpsec-rollover-00.txt
Roque.
On Jul 29, 2012, at 1:26 AM, Murphy, Sandra wrote:
The eventual response from the wg showed consensus for adoption of this draft.
The authors may
I would like to see the receiver rules deal will peers outside the cluster
who set the entering cluster flag maliciously.
dougm
--
Doug Montgomery Mgr. Internet Scalable Systems Research / ITL / NIST
On 8/6/12 3:05 PM, Matt Lepinski mlepin...@bbn.com wrote:
I also think this works.
Doug,
Sounds reasonable. What would you like those receiver rules to say? Are
you saying that if I am a receiver and I believe that I am not a member
of a confederation and I receive an update that has any confederation
marking then I tear down the session (or treat as withdrawal, or
I am in favor of having a WG document addressing this topic. But, I
agree that the proposal
MUST be consistent with the RPKI CP (RFC 6484).
Steve
On 8/4/12 2:12 PM, Alexey Melnikov wrote:
Hi,
On behalf of SIDR WG chairs I would like to initiate 2 weeks
acceptance call for
speaking as regular ol' member
How about those who set the flag stupidly or by accident?
:-)
With current change of the flag semantics to this-is-a-inside-confed-hop, it
would be difficult to cause damage by setting the flag outside the boundaries.
(Self-induced injury by a neighbor looks
Sure, stupidity is indistinguishable from malus, without understanding
intent.
I wasn't proposing any specific reaction.
But if our behavior is now to strip backwards through consecutive confed
flags ... I want to make sure we are rock solid that I can't game that.
While I realize it might be
Slides from the last interim in reston have sizing estimates from Geoff Huston
on the eventual targets for the rpki system size. We should codify these in the
requirements draft(s) in order to evaluate the current systems and future ones
against a consistent benchmark.
-chris
Did not state the obvious, sorry.
Please review the minutes and post any additions or corrections to the list.
--Sandy, speaking as wg co-chair
From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Murphy, Sandra
[sandra.mur...@sparta.com]
After re-reading the -02 version, I do not think that this draft, as
written, should be be adopted. I also retract my 'at mic' statement that
this could work if termed as interim in function - as I doubt that there
is any real mutual understanding of 'interim'.
So while the current RFCs do not
I am very concerned the impact this kind of activity has on the integrity of
public allocation registries.
How are external parties meant to understand what should exist, if the RPKI
signing leaps over intermediate parties that are explicitly listed as having
substantive authority over the
RFC5065 says if you receive a confed sequence/set from a peer that isn't
in your confederation, you treat it as a malformed AS-PATH and refer to
4271 rules for such.
It is an error for a BGP speaker to receive an UPDATE message with an
AS_PATH attribute that contains AS_CONFED_SEQUENCE or
18 matches
Mail list logo
