These are unedited transcripts and may contain errors.
Routing Working Group session
15 May 2014
2 p.m.
JOAO DAMAS: Hello, welcome. This is the routing group meeting at the RIPE
68. If you want to be at the other Working Group, not in the routing one,
it is taking place upstairs on floor number 1.
So very welcome. We are about to start. The agenda is pretty packed and we
are being asked to make it short so we see how that works. I am the Chair
of the routing /WO*G /TKPWRAOUFPLT /ROP Evans sitting here in the first row
is my co?chair.
We'll go through the agenda. That's the proposed agenda. Does anyone have
anything that they would like added or modified? We'll adopt that agenda.
Let's start with some administrivia.
The minutes of RIPE 67, they were circulated a couple of weeks ago. We
didn't see any comments. Does anyone have any comments. If not we will
declare them final and ask the RIPE NCC to publish them. I'd like to thank
you our stenographer who does an excellent job as usual, of transcribing
everything that is said here, please do take into account that there is a
speed limit to this.
When you go up to the microphone as part of this, also please identify
yourself that it can be written down and also for the remote participants.
We have a minute taker here today, an an bud he have from the RIPE NCC,
thank you very much and we have a scribe monitor as well.
Having said that, let's jump straight into the agenda. First speaker is
Benno, if you could come up.
BENNO OVEREINDER: Thank you. RD L. So, RD L, a little bit of background.
We will talk about something which will replace RPSL. How did all this work
start? So, two years ago I started talking with people about improving the
tools to configure your routers, and we call that project, well, the project
is called Engrit, and in a discussion with people there is someone, maybe we
should get rid of RPSL. Well, whatever, next time I talk with other people
and we talked about a tool chain how valuable it would be to improve the
quality of routing and ease the process, and again someone suggested, maybe
we should get rid of RPSL. Maybe? I don't know...
And the last RIPE Meeting, we sat together and with a number of people also
here in the room, and again a couple of people said maybe we should rid of
RPSL. And here we are, giving a presentation about RDL, something which is
planned to replace RPSL.
This work is actually done, developed by Per, known from EU Net until 1999.
And he is now working ?? he worked for Cisco and other companies, and is now
working on this project for us.
So, RDL, the rationale. The idea is, well, making mistakes cost you
reputation, costs money and routing configuration is complex, so any way to
ease this process is valuable. So that's the main goal. So, can we find a
way to improve the quality of our routing configuration and ease the
complete process and have some verification tools in place to check if our
configuration is correct, that's the intended effect we want to.
Again, RDL is an acronym. A high level route documentation level. So,
something like you document your routes and your policies, so it's human
readable, or intended to be human readable. It's a dual purpose. Of course
RDL has to be translated to our browsers, so there is a translation from our
RDL to our Cisco configuration and the RDL to our Juniper configuration, or
bird, but it is also a description and a publication for your routing
policies for others to check and for validation tools to prove correctness.
So, these are the goals of the RDL. And RDL is not the next generation of
RPSL NG. When appropriate we will reuse parts of RPSL, the data sources
used by RPSL, some objects published already, publication repositories,
these are all still in flux, of course, these are ideas about how we can use
that, and we want ?? we certainly have to give credit to the people who
developed RPSL and the language has ?? but the language, or RPSL is about 50
years and it shows its age and the current practice of routing changed and
it's not easily reflected in RPSL language.
So RDL is more about describing your topology of your network. It covers
both iBGP and eBGP, we'll come to that later and it's about policies,
describing your routing policies.
I'll keep a close eye on my time because I tend to use more than allocated.
RDL is also not YANG. So, at the start of this recreated an excellent
tutorial on YANG and NetConFig, and it's the way forward for routing
configuration management, but RDL is not about router configuration and
management, it is about BGP routing policies. So, YANG, it's human readable
but there is a lot of details add it's riddled with details and difficult to
read. RDL is intended for human, so it should be in some way readable and
easy to write down your policies and your topology. And of course with YANG
could be a target for RDL language, and YANG and NetConfig can be used to
refigure your router.
There is a lot of confusion about what's the policy, what is enforcement of
an action. A policy is something, as you say, a policy thief will be
prosecuted. And what is an action? Arrest the thief, nosey parker, well
it's a reformed criminal. So...
Analogy is speed limits, for example, so, where does the speed limit ??
we'll come to that later I guess. Yeah, let's stay here.
Thinking enforcement instead of policies, so if you don't split it, people
start thinking about enforcing and enforcing starts degenerate into route
filter mechanism and we want to think on a more high level and a more
abstract way about how we should route our network and how to apply our
policies.
So, in RDL we split, we make this a clear distinction what we mean with
policies. Where it applies, it can be topological location, when it
applies, your NLRI attributes can be used when it applies, and what to do,
filter it, manipulate attributes, etc.
So, think as an analogy of speed limit. So, speed limits are applied.
Where? On public roads, not on private roads, not on a race track. So
that's the where. When? Well when you exceed the speed limit, advertise
you are on the road and what? Well you get a fine, disqualification, in
jail.
And together these three entities, aspects, they jointly describe policy.
This is translated to a network policy. So, actually, I want to skip this
one, we'll come back to this example later in RDL, so for speeding up the
presentation.
So the language, RDL the language. Very important is we want to describe
your topology of your network, and some flexible intuitively way. Actually,
let's go further.
So, the topology. So how are we describing your topology and your topology
is the base, so you don't go think how you would like to have your network,
but you go to your network, you draw it up and then you try to ?? you
describe that topology, the map, into RDL. So, RDL has three logical
components: These are zones, and they may contain other zones, and routers.
Routers may contain one or more BGP peers. And you have peers. So these
are ?? you describe your topology with these three components. And each
object can also have a number of attributes: AS number, address, that kind
of things. And also very nice is, iBGP is configured automatically. So we
see that example later on, how we play with that.
So, there is an RDL topology example, so we have here an network, Hibernia
?? we got a number of used cases and examples from people from Hibernia.
Their AS number 5580 and they have a number of zones, Europe, US, Asia
Pacific and with each zone you can define countries. But again these are
just free form identifiers, it only makes sense for your network, so EU, N
L, it makes sense for us to think about our network, it's topological
organised. And within the Netherlands, at Amsterdam we have a router, it
has its address, 134 etc., and it peers with RIPE, again it's a free form,
nothing session here and here we have a short?cut of short notation, the
address of the router, and its AS number. And something similar we can do
in US region and for Asia Pacific.
So, what the zone? The zones are an important concept here because they
define ?? well they are the containers for policies where similar policies
are applied. And well I used here geographical correlation but not if your
network doesn't look like that, that's not relevant. We chose this in this
example. You go to your network, you draw the map and that defines your
topology in the language.
And again, the zone maps identifies the reference points for policies, where
policies apply on these boards. I will in the next example, I will give you
how it works. So we define the nobogons policy in my network and I don't
want to export bog once outside my network, so we have a new policy, where
does it apply, well where my AS number is not equal to my peer AS number, so
it's outside my network. When? Well if the NLRI prefix are in the bogons
list, we use RPSL to specify our bogons, the N percent is here, well, a
match. But we could also have an include set notation, but we still
thinking about a correct syntax for this. And then what we do? We reject
the bogons. So in this way we can filter out bogons exporting outside our
network.
Another ?? well another ?? well a useful example. So, in Hibernia they use
route reflectors between US and Europe. And so how do we deal with that?
So, instead of a full mesh between Europe and US routers, we define that the
routes should go through the route servers and route reflectors, and within
a zone and EU and this full mesh between only between EU. We have a router,
RR 1 and another router RR 2 and define a new zone and here iBGP is by
default full mesh, but now we say iBGP, to routers, the route reflectors and
the local mesh, so it's only in EU is the full mesh but not for the whole
zone is a full mesh. And then we go on like before, we define a zone NL
etc., etc. Similarly, in a US we define the zone and again instead of the
default full mesh we say in the zone also the iBGP, the two route reflectors
in the local mesh, only in the US there is a full mesh and between US and
Europe routes are export via the route reflectors. You can do some
verification that you don't make any mistakes. Another example we want to
deprioritise routes from the EU imported into the US. So we have a new
policy here where when we import routes from zone US or including, so peers
in the zone US use this notation, and the peer remote zone is in Europe.
When? It's not relevant, we set the local previous of 90. So this prevents
intended routes or this prevents traffic going unintentionally from US to
Europe and back the US. So intraUS traffic stays within the US.
Another example. Changing iBGP to the full mesh. It only requires a few
edits. This is the example just two slides ago. We remove the route
reflectors, we don't need them. Remove the iBGP that we wanted it local
mesh for the zone and here, now the whole zone use the iBGP full mesh, so
these are four lines of code which can be removed and if you were to do it
on the routers, then routers already require something like in the in order
of 100 configuration changes, of 100 lines of configuration change.
And the nice thing is, we don't have to do anything for a policy. The
policy still is valid. So, although we changed part our iBGP topology, how
iBGP is being used, full mesh or local mesh in Europe. The policy stays the
same. This is still valid, we still only import zones ?? at the moment we
import zones in US from Europe, we give them a local pref. And that's just
the trick, like Tommy Cooper always said after a trick, "Just like that
,"and people my age and older, I expect a pun on the microphone later on.
I want to skip this.
I want to give acknowledgements to the people who really helped this out.
Jaap and Andreas at the beginning of last ?? the beginning of last year, the
beginning of this year we had a lot of telephone conversations and e?mail
exchange, they provided examples they did some review of the RDL language,
and thank you for that. But we still look can for used cases, so used
cases, ideas, how RDL could be used in these for your network, more than
welcome so please contact us. So, RDL is not about configuring routers, but
it's about documenting and programming your network.
It's open source project, and it's open discussion, so please, if you are
interested, subscribe here to the ?? it's called the progress mailing list.
So, things we discussed, we have meetings, the notes are published on the
mailing lists, documents are published or mailed to the mailing list. So,
please subscribe. Apparently I am the admin of the project. But for the
real stuff, Petr is responsible, you can contact Petr also directly. On
this.
And that concludes mew of my presentation.
AUDIENCE SPEAKER: Rudiger: I know I haven't been paying attention as much
as I wanted, and as ?? well, okay, you gave me the opportunity to look into
stuff and for the presentation, I think there is a big gap. You have not
shown any example that shows how policies actually can apply and how a
modular approach shows up when we actually have any external relation, and I
suspect, I suspect when you start up and say you want to do something that
can follow up on to RPSL, you are exactly missing what's happening there in
a way that is not helpful. And from my experience and my development
experience, the interesting question is: How do the things actually show up
on defining particular peers and peering sessions? That's the point where
the ?? how well does the modular tee of the stuff actually hit the point of
deployment?
BENNO OVEREINDER: We have to work on that. Any input, comments, are
welcome, and I will get you Rudiger, I will be more proactive to get you
involved.
CHAIR: I just have a quick question. I mean, I get the documenting part,
that's clear. I don't quite get the distinction you have there between
non?configuring routers and programming the AS. Programming the AS is
pretty much configuring the routers.
BENNO OVEREINDER: Configuring ?? yeah ?? but RDL is ?? so you are not
forced to think about configuring your router. So, the tools are shaping
our thought and the lack of good proper tools has shaped the way we think
about routing configuration. And what RDL tries to do is to get rid of the
idea we have to configure routers and think about, well I was thinking about
the brilliant presentation of I won't be earlier where he did the selective
blackholing and it belows up in your face because all the complexity you
need in your communities, and job did write a script for that not to make
any errors. But that's the way we don't want to think in RDL about how to
configure routers, we want to do it on a higher level and of course
translating this RDL to YANG and NetCon translated ?? well, but we want to
abstract from that and give people the opportunity to think differently
about routing ??
JOAO DAMAS: So this is one of the input would be combined with other data
sets to transform into the final configuration.
BENNO OVEREINDER: Yeah.
AUDIENCE SPEAKER: Geoff Huston. There is something about this that just
makes my brain go into this ?? this is weird, it's it doesn't strike what I
understood about particularly inter?domain routing. I thought a lot about
inter?domain routing as a negotiation. You want to optimise your position,
your AS. I want to optimise mine. My exports are your imports, and we each
express preferences in prefixes and the routing protocol negotiating what's
happened. So, in other words, I don't get the world all my way and you
don't get it all your way and I can't describe my AS and go these are my
conditions and the rest of the world can get stuffed and live with it
because I suspect that no one else would find any room to peer with me.
Right?
BENNO OVEREINDER: Yes.
GEOFF HUSTON: Then you sort of say this is actually about saying what I do
absolutely. And it's kind of, there is something that doesn't quite work
here. Now that's just the mental model of what routing is, which then
translates into how do I describe my policies as they interact with your
policies at a policy level, how does that get down into protocol interaction
and what I offer and what you accept? Because that's really what happens in
routing, what I offer is not necessarily what you accept, but you know, I
have got to offer it and you have got to accept it. So I'm kind of thinking
of that conceptual model and then wondering how this fits in, I see a bunch
of absolutes in what you are saying, I see it, I don't know if it's true or
not, and I see in routing much more of an elastic negotiation and the
protocol does it brilliantly oddly enough, I'm not sure if it was deliberate
or accidental, and there is something about this that I'm finding it hard,
that's all.
BENNO OVEREINDER: Thank you.
GEOFF HUSTON: I thought I'd share the pain.
RUDIGER VOLK: I would like actually to comment on that. Geoff, there are
two views of this engine. There is the look and actually that's a question
also for Benno, how that reflects in the language. There is a view where we
are looking at the inter?domain relations and then there is the view of I am
running and constructing a complex machine within my AS, and well, okay, it
is much too preferred ?? it is much preferred if I conceptually take on that
task when I am addressing the whole machine and understand that I need lower
level concepts for implementing the dam stuff and that's what goes into
router configurations, and yes, it is much to be preferred to think at the
higher level, and that, I think, is what approaches like this and what I
have been doing a couple of years ago are addressing. It is not only the
iBGP coordination, it is ?? I'm generating certain flavoured services on the
edge and I have the mechanisms, I construct the mechanisms to make them work
internally. So in conceptual model, I actually distinguish between well,
okay, defining services and the interpretation of the services. And when I
go to my model for describing the peering, I call upon the services that I'm
delivering to this particular customer, well, okay, that's old stuff, that's
actually internal machinery that may want to be reflected on the external
documentation, and the question for a language like this is: Does the
language provide something where you can tear off the part that you publish
and that is actually of interest, of legitimate interest public world and
the other half which is what you are doing internally which should not be of
interest and okay, where you may have parts that you really do not want to
share.
AUDIENCE SPEAKER: Hello, I am Benno, as you mentioned I was in the team
that initially gathered the requirements. Unfortunately I didn't have a lot
of time after that. So, I was watching your presentation with the same
level of surprise as with everybody else and expectations. But, at the
requirement levels there was a lot of things that Rudiger and Geoff
discussed, so, I remember that I have been discussing about how this is, as
you said, the tool, a language for describing a policy first of all, not a
tool for configuration. And as a language that describes policy, it is
important to be able to define different views of the policy. Some part of
your policy may be public, may be a good tool to deposit in the RIPE
database. Some parts of the policy are internal. Some parts of the policy
you might need to exchange with your neighbours because your import is the
export of your neighbours, so, if you go to this mailing list and look at
the archives and find the requirement documents, much of what you said is
there. I'm not sure how much has already been addressed by what Petr has
already implemented, but I agree with what you say and I believe that what
Benno was doing and Petr are on the right direction.
CHAIR: Thank you very much. Benno.
Next up Job.
JOB SNIJDERS: Hello. The lack of slides symbolizes the lack of
documentation that we have today, how to do automated prefix filter updates
on your routers. Who of you filters the prefixes they receive from
customers? Who of you does this a hundred percent automatically? And
that's bad. I have Googled just now for automated prefix filtering, enter,
and then on page 1 a question is phrased to a NANOG mailing list which says:
How do you do this? And there is no answer. Who of the guys that does this
automatically, who does this with priority tree software? This is a
problem.
So, what I want to initiate within this Working Group is that we phrase a
how to document that you can reference newcomers to that document and say if
you want to do automated flicks filtering, this is how you do it, and as a
community we think this is a very sane way of structuring Configs, these are
the tools we use to push it to routers or generate filter sets, and it just
should be the end point, the document that really teaches you this is how we
do it.
Would there be interest in such a document? Only one. Let's go a step
further. Who would help me write this? Four people. I think ?? five even
?? awesome ?? it's a very big group now. You have a remark Rudiger?
RUDIGER VOLK: Yes. I think writing something is a great idea. My guess is
the how to actually very quickly runs into the question how to get a mutual
understanding of what the relevant and reliable data to be used is. And
that unfortunately is a damned rat hole.
JOB SNIJDERS: It absolutely is. When I generate filters, you know, you
start with the most accurate source and then you trickle down to the point
where you just hope for the best and lie crying at night in bed. But you do
this already today. And just documenting what the networks do today, so
others can can copy that style and have something that's automated instead
of manual, that already would be a huge improvement I think for this
community. Geoff?
GEOFF HUSTON: This is not the first time we have gone down this path and it
won't be the last.
JOB SNIJDERS: Why couldn't I find it with Google then?
GEOFF HUSTON: Typically the reason why some things haven't happened the way
you want is either we have gone a different direction, or it's really hard.
What gets really hard is that when I want to prefix filter somebody else,
they're injecting some routes themselves so I'd like to know the
authenticity of that injection, but they are transiting routes from somebody
else and all of a sudden I need to know about their policies or I am in
RPSL land. You know, straight away you start to go I'm back where I always
were. And this is hard because in general, to rely on a whole bunch of
published policies like using, oh, gee, a routing database, is fraught with
problems that we all know and have written our own customised tools because
we don't seem to understand enough of the problem that we all write
consistent good stuff. So, sometimes the problem that you think you're
attacking is a problems that we have been actually been attacking for many
many years and it's hard. And it's not that it's a lack of energy at the
wheel, it is just a hard problem. We always thought in this RPKI stuff or
at least personally I thought that a lot of this was about the origination
point. Sign something and I'll automate its entry because you own the
prefix. But when I push it onwards, what you gave me doesn't count any
more. It's my export policies that I need to sign as an AS and publish them
in something like a routing policy database. Does all this technology here?
Yes. Do we use it? No. Is it a lack of documentation? No. It's
something else.
JOB SNIJDERS: I disagree. If you Google for automated prefix filtering you
find nothing. There is a lack of documentation, I believe.
GEOFF HUSTON: You know, this might surprise you and it might surprise the
rest of the room, Google doesn't know everything.
JOB SNIJDERS: Thank you for your comments. So we have a small group of
people that volunteer to help. Send me an E maim and I will create a small
mailing list and we'll get this train rolling. I expect that we would be
able to, if there is a lack of tools, we could maybe write some software to
cover those gaps because recently IRR tool sets became abandoned wear. So,
yeah, please e?mail me, I will get it rolling. Gert. Gert Gert while I
think this is useful what you are proposing to do, I am wondering about
something else. How can we get more people to actually do prefix filtering?
There is too many networks that just accept and transit everything that
comes along. Wherever it's coming from, is. Auto prefix filtering is like
making the thing perfect for the 5% that do almost everything right. How do
we get the 95% that don't even do manual prefix filtering? This is not
actually targeting you, it's more targeting the room. Well, you brought up
the subject. If I had an answer, I would go around and whack people.
JOAO DAMAS: Every time this discussion happens, there is always the
question of scope. There are mechanisms that would be appropriate within
your own AS. Perhaps talking to your customers, and that perhaps don't
scale, when you do this in inter?domain, BIS basically what Geoff was
saying, certainly tools, people configure their Internet work from the
routing registry even if they have to run it themselves. It's when you talk
to others that things seem to be dodgy.
AUDIENCE SPEAKER: A direct answer, I'm not talking about interdomain
filtering really, I'm talking about transit networks not filtering their
customer ?? the prefixes their customers announced into the network and I'm
not talking about Rudiger, I know you do ?
RUDIGER VOLK: I am a pain in the back for most, and harder than most. But,
well, okay, Gert, actually having some documents that we could point people
to who are not doing the right thing actually would help as a little bit of
leverage, so, kind of the attempt of doing something there quite certainly
is a valuable idea. The interesting question is, how successful is it going
to be and how hard is the task?
ELVIS: Just to answer Gert. I used to work in Romania for an ISP before
moving on. In Romania 99% of case filter based on route objects. We used
to say we will accept your prefixes if the route objects are registered in
the RIPE database and we used to have scripts, proper written scripts,
in?house made scripts that would actually browse the RIPE database, search
for route objects or for IS sets and only accept those prefixes and those
would be run every 12 hours. So that's one thing.
The other thing, once I moved on from the NCC, we started our own internal
network for our own services before escrow's mail, blah blah blah, and we
wanted resilience, so we contacted a couple of providers and they signed
contracts with us for transit etc., etc. And there was no requirement for
prefix filtering or whatever, we just will told them we're going to use our
own IS and this is our AS. And then I was surprised that once everything
was done, I got a letter from the technicians saying, please sign this
letter allowing us to announce your AS number and let us know your prefixes.
JOB SNIJDERS: That's rough agencies.
AUDIENCE SPEAKER: Basically, as far as I know Romania still does the same
thing. 90 or even more percent of the prefixes accepted by the ISPs in
Romania must have a route object. You don't have the route object in the
RIPE database, your prefix is not accepted.
JOB SNIJDERS: Thank you.
GERT DOERING: I'm very happy to hear that. Thank you.
AUDIENCE SPEAKER: Hi, Romeo, RIPE NCC, a comment from the RC channel.
From Mateo: He is giving a comment for jab saying that the main problem is
in getting people populating the route objects in the IRDB.
JOB SNIJDERS: It's part of the problem, I agree.
AUDIENCE SPEAKER: And his affiliation is Jaguar networks.
JOB SNIJDERS: There are many networks, however, that will just refuse the
prefix if there is no route object. So there is a strong motivation for
lots of people to create a route object, otherwise it's not routable.
AUDIENCE SPEAKER: There was one addition from the same user. That the
problem is especially relevant when the customer is outside the RIPE region.
JOB SNIJDERS: True.
AUDIENCE SPEAKER: This is A, it from big low. I do operations in an area
where economic growth is like a big roller coaster ride, and in those kinds
of situations, customer network change is, it happens so much that it really
becomes hard to do automated prefix filtering, because customers tell you,
you know, this is the prefix that we're going to do, they make mistakes and
they make mistakes and registering to the IRRs and it's really regard to fix
those problems when the problem happens so much during the day. But, I do
also see that there is a lack of ?? I come from the APNIC region, and I do
see a lack of documentation in that area, maybe there is out in the world,
but people are just not seeing it yet. And I think it is also really good
that if there is a tool and also a guidance, and if it was presented to the
crowd, I'm not sure, but in the Asia Pacific region, some people that, you
know, have the will to do this, it would help them. So, being in that area,
if the document can sell, I'd be really happy to you know, discuss what the
crowd there, that this is out there, and people should take a look at it.
JOB SNIJDERS: Thank you for your encouraging words.
AUDIENCE SPEAKER: I have one more short thing. So, even if a prefix ??
Elvis ?? even if a prefix is from outside the RIPE region, it can still be
added to the RIPE database routing registry, RPSL maintainer and so on.
JOAO DAMAS: Yeah, it was used in that way, indeed. Okay. Thank you very
much. It seems like you have an idea, you have volunteers, work on it.
Come back.
Okay. Next up.
ANDREI ROBACHEVSKY: Hi. So, how can we get more people to do filtering?
How can we get more people to do source address validation? How can we get
more people to register their contact information then when a problem
happens they can be accessible? And really, I don't think this initiative
is solving those problems but my hope is that this initiative that we call
routing resilience manifesto is a step in this direction.
Right now it's a work of a small group of people. We drafted initial
version of this document, but let me describe the intention, the objectives
of this initiative first.
So, the attempt is to define a very pragmatic package that would be asked
from the operators that what to support this. At the same time we shouldn't
lose sight of how it looks likes our aspirations.
Well here I put the quote from Rogers, and he is the inventor of the term
"Diffusion of innovation" although this is not about innovation, I mean what
we are talking is nothing especially new or innovative. What I tried to
show here is that things we're discussing they are as much technical as
social. People don't do things in isolation. For people it's very
important to know if they do a BCP or deploy practice that this is practice
that others do as well. And this, this document trying to corral people
around that is trying to address the social part of the problem as well as
technical.
So, basic objectives is to raise awareness and encourage action by
demonstrating commitment of the growing group of supporters, so growing
group of supporters is crucial to the success of this initiative.
And secondary goal is to demonstrate industry ability to address complex
issues. So when we say Internet governance and multi?stakeholder things
that were discussed in the parallel session, I think that's about it, that's
how industry can get themselves, ourselves together and address those
issues, right, governance begins here.
So, what this document is looking at is a tangible and very clear message,
we do at least this, right, this is not all what we can do, we can do more
and much more and many of us is doing more, this is the least, this is a
minimum package and we expect you to do the same.
What's the kind of package? Well, the document, it basically contains some
layer 9 stuff, high level principles that recognise interdependence, a
commitment to ?? well, a commitment to best practices and a commitment to
work with customers and suppliers, encouraging them as well.
But more specifically, the juice of the document is in so?called guidelines
and those guidelines are not about how, right, it's more about what.
And how is, well the BCP is on new documents like what job has just
suggested, those are the how parts.
The end product is the landing page, published online. The published
document and a list of supporters. So those who endorse the document, their
name or name of the their company will appear on the list. And of course,
pointers to more specific information resources like BCPs practices,
operational documents, what have you.
As I said, it's a work in progress, so, a small group of network operators
working on that. ISOC role is just a neutral platform and coordinator. And
the following slides is not the complete or not even the draft version of
the document. It's just an illustration of how it shapes up.
Layer 9 principles, they are in the slides. You can read them later. But
let me jump to the core of the document.
And those are are three requested actions. So, I mean, it's not the full
solution, but the belief is that if those actions are implemented, are
supported, accepted on a wide scale, we live in a much better place. And of
course we can do better. So, three things, and let me just walk you through
them so you get an idea what we're talking about.
So, the first one preventing propagation of incorrect routing information.
The thing is to define not could be done but what probably should be done.
So it's, again, I draw your attention, it's not the limit, it's the
baseline, where we start.
Own announcements, customers, using prefix?based filtering, and ability to
communicate what the correct announcements are. Just an example. If your
neighbour, if your peer comes to you and says, hey, what kind of ?? if I
want to do filtering on our peering arrangements, what kind of information
can I use to validate your announcements? And you will be willing, and
we're not specifying here how, maybe it's an IRR, maybe you register ROAs,
maybe you do some other technology, but you are willing to communicate this
information to your neighbours.
Prevent traffic with spoofed source addresses, we are addressing this issue
for decades already. It seems like boiling the ocean, but I think we need
to start somewhere.
So, again, very simple case which looks like almost a no?brainer. It's a
single?homed stub customers, things you know for sure what you could expect
from them. Own End Users and own infrastructure.
And of course you apply filtering, you commit to apply filtering to keep the
Internet clean from garbage that you can emit.
Finally, is to facilitate global operational communication. Again the ask
is very simple. Publish contact information that, well you also communicate
that is available globally. I think many of you bumped into that problem,
when something happens you have no access to someone on the other side of
the Internet that can help you solve that issue. And that can help.
So, that's roughly the document, the manifesto. Next steps finalise the
draft, and if you are interested to help, please find me in the hallway and
we can discuss this further. I hope, if there is interest and if you ?? I
have a few questions for you guys, if you think that's a good way forward,
that's a useful activity, maybe this group of people can review the draft
document later when it's in a good shape to share with the wider community.
That's the second thing.
And then create a web space, the founding members, the group of operators
that already support this initiative, so, it's easier for others to join.
And launch and promote.
So here the questions: Is it something that you think is needed? Is it
something that is useful? Are we going into the right direction? Is
something missing? And interested in distribution and even more important
question, if such things appears up, would you be willing to support that
and endorse?
And that's it, what I have.
JOAO DAMAS: Thank you. Anyone have questions? Rudiger.
RUDIGER VOLK: Deutsche Telecom. My view is that the state of the art or at
least the state of the art as is commonly understood to be deployable is
lacking. And in such a situation, I am very reluctant to make statements
that says, well, okay, some minimum that can be documented as current
practice is a minimum and everybody agrees on that, actually the challenge
is finding a way to define a target where we actually have to move to. A
manifest with a minimum requirement like I'm seeing here, in my opinion,
comes too much with the danger that the people who will have to sign this
and who are ?? well, okay ?? who don't mind about say words like correct
are, well the semantics of correct in this context is not really easily and
well understood. But for signing such a document, people are relevant who
don't mind about that kind of stuff, and people like that will take the fact
that someone from their technical staff advises them to sign this, this is
good stuff, they will take it like everything will be fine after this, there
is no other challenge and we don't need to spend money or effort on
improving things. I can see that, yes, unfortunately the current state of
affairs is that indeed plenty of players are not even doing what you are
asking for in the manifesto, but ?? well, okay ?? setting too short a target
range can lead to a situation where you do not go beyond and where you ought
to go.
ANDREI ROBACHEVSKY: If I may respond. A few things. One thing if everyone
cleans their side of the street we live in a cleaner town and this is about
that.
Secondly, yes, understood, that's a trade?off right, a trade?off of setting
the market too high and getting more support. Right? It's a tricky thing
and we can discuss that.
Anded third: No one prevents us from going to manifesto Version 2, which
will say higher mark.
GERT DOERING: I wanted to say, I support this great stuff and sit down
again but after Rudiger's long speech, I need to state that I completely and
fully disagree with Rudiger here, which is ?? does not happen so often
actually, because I think this is something that is important to reach
fairly quickly, because if we continue people, especially the part about the
spoof package, it inject large amount of spoof packets being reflected off
innocent machines anywhere in the Internet, breaking large parts of the
Internet in the process, at some point in time I maintain the regulators
will come and try to solve this problem for us. I would vastly prefer to
solve this problem ourselves. If we hang up the manifest of what we are
going to solve too high, we are not going to solve the urgent things and I
think that what you have there is really urgent things, so, I think it's a
good way forward. If we ever get there and feel we should aim for more, I
don't think it will stop us go for Version 2. There will always be things
to fix. But there are some pressing things to fix first and this is it
basically. So, I support this effort and I'm not promising actual
contribution, because I know that my time planning is horrible, but I will
be happy to have the company sign it.
AUDIENCE SPEAKER: Daniel Karrenberg, no hat. Thank you for taking this
initiative. It's something that is slightly a different tack on it than we
did before and I think it's useful. From the point where I am and I'm not
an operator of BGP any more, it looks to me that the principles should be
formulated even more general and maybe even more in terms of the goals and
the ?? the real principles, and that the implementation is in the technical
documents and you are already going that way and that's a good thing. But
it still strikes me that the language is too techie and specific and that's
where you get the endless discussions. Maybe a way forward would be to
describe better the goals of what, and the principles of those three things.
Second remark is the ?? you have to be careful about the perception about
the third goal, because I think in this region, we have solved this not a
hundred percent but quite well, and already for a long time. And if we make
it a grand goal, there might be the perception that there is a problem there
in this region, and I don't think there is.
ANDREI ROBACHEVSKY: Just one quick response on language. Just let me show
?? so the actual guideline is this first line, right. The rest of the text
is explanatory, it's an illustration, so that's what we discussed also when
we were drafting. Just to maybe explain a little bit what is meant by the
required action. So, do you think this required action is general enough?
Forget about this text in the italics, okay, so this is ?? those are the
lines that are requested. The rest is just explanations, some explanations,
so people understand what we mean. And then the, the specifics come in
BCPs, operational documents and so forth.
DANIEL KARRENBERG: I think that's too short and I observe that we had some
discussion already about the stuff in italics. But by all means, I like ??
proceed with it, don't feel discouraged by what I said.
ANDREI ROBACHEVSKY: I'll pass your feedback.
GEOFF HUSTON: I feel like I'm arguing against motherhood and Apple pie. We
have been saying for the last ten years we should all be running IPv6. Why
aren't we? Not because we haven't got enough documents saying we should all
be running IPv6. There are room /TPULS of this kind of statements, but we
don't. So you have set us some very simple and accurate things about what
should happen in routing. Do you think they don't happen because folk are
ignorant about what they should do? I don't. So, you got to ask yourself,
why doesn't this happen? And why can't we address that problem? Because
quite frankly, if you bring up this kind of document about what should
happen when it's patently obvious that reality isn't, unfortunately, Gert,
you will invite regulatory intervention because you have set industry
practice, industry ignores it, the market has failed, it's time for a
regulator to correct the market. Exactly. So, just be very careful here
about understanding why what you want hasn't happened. And that's a really
important question here. Because I don't think we understand why incorrect
routing is so good that some Indonesia provider can slip up in an iBGP, BGP
condition figure and blast the world with incorrect configuration. We don't
understand this. And it's not because they wanted to propagate incorrect
information. They don't want to do it either. Right? So, making these
statements that we're lousy about what we should be doing, I don't think
helps us. There is a credibility as an industry. I think we have dot to do
more work at this to actually understand route cause, the information
available to operators and the tools available to operators and I'm sorry if
I'm banging on against all the things we have talked about for the last 20
years about how to make routing work properly. Statements like this
highlight our failings, unfortunately, because that's what we all wanted,
we're not arguing we don't want this, but the reality is we're not achieving
it and it's not because we're ignorant. It's because we lack the necessary
tools to do this. Okay?
ANDREI ROBACHEVSKY: So, there is this concept which is called the strategy
of the comments, and it was said that strategy of the comments in bigger
communities cannot be avoided. And the only way is either privatize or
regulation. Now a Nobel Prize winner, she demonstrated that social links
and collaboration can actually help ?? well, if not help, mitigate this
problem. So my theory here, and that I share with some of the authors of
this document, is that we are underestimating the collaborative nature our
the need for, you know, feeling someone else ?? you know, going down the
same path and this document can support that. Yes, economics is against us,
I fully agree with you, but the theory is if we help with the social aspect,
if we put more attention there and not just say hey let's do filtering here
in the Routing Working Group but make it more tangible, make it more
visible, that can help.
GEOFF HUSTON: Let me two a five?second battle. The tragedy of comments is
where self?interest works against common interest and natural motivation is
to maximise self?interest. When it works against common interest, we have a
problem. This is not that kind of a problem. Folks don't do this because
of self?interest. There is something else at play and it's not a tragedy of
the comments. So as I said, the route cause issues flying around as to why
routing becomes a mess, and it does, is quite difficult to understand, and
it's not, you know, self?interest getting in the way of common interest.
The tools around the tragedy of the common solutions don't necessarily apply
in this space. That's what I'm trying to sort of say. This is a difficult
problem. Not one that we have encountered in other spaces readily
identifiable, right?
ANDREI ROBACHEVSKY: What are you suggesting Geoff is also very important
and I'll go and find you in the hallway, be aware of that.
JOAO DAMAS: Thank you. I think ??
AUDIENCE SPEAKER: Sandy Murphy, Parsons. I stepped up to the mike because
of one sentence in here and a remark that you made about this would be
further amplified by best current practice. Network operators will utilise
prefix based filters. Geoff remarked that one of the fundamental problems
is identifying the legitimate origin of a BGP route announcements, the
origination of the route to a prefix. That prefix based filters is an
operational practice to try to solve that origination problem. That's the
operational practice right there. And it appears that all in all sorts of
documents. You know, BGP security documents, standards documents,
everywhere. How is this document any different from all the rest of those
documents when people sign are they promising to do something? Are or they
just stepping up to say mother pie, Apple, whatever? What is the difference
between ?? where is the goal versus the operational practice and what does
signing this mean?
ANDREI ROBACHEVSKY: Well the signing, I think the signing means that yeah,
you implement this thing. You are not just saying yeah, those are good
things, I support them but you implement those things, right. Can we check
that? I don't think we will please this. I think peer pressure is where it
can resolve. It will be publicly available, the document itself. A list of
people that endorse this will be publicly available, or organisations. So I
think that might create in my view enough peer pressure so people will not
sign up just to say hey, I think that's a good set of practices. No, when
you sign up you say yes, I think this is a good set of practices and I'm
implementing those practices. So I think if we make this different, very
clear, this document will have weight. That's my hope. Now to your comment
about prefix filtering and further to Daniel's comment I think yeah we need
to work more on this text to make sure that those are not specific
recommendations, because prefix filtering was introduced here only to
highlight the fact that many people think that IS path field ring is enough
and that's kind of the short card they are taking but I think we need to
work on the explanatory text more.
JOAO DAMAS: Thank you. We are badly over time, so, we'll just go next.
LUKASZ BROMIRSKI: Hello everyone, this is my first presentation on the RIPE
Meeting, so, don't shoot the messenger and I have to be very quick, because
I have learned that there are very important sessions after me, so I will be
very quick, buff all the contact details on the slides. And my idea about
this presentation was after reading the notes for some of the previous
Working Groups RIPE Meeting, there was a discussion about the blackholing,
but in my opinion, didn't end in something tangible so I decided to present
you the idea we are running in Poland for the last ten years.
And this is actually the BGP blackholing project. Nothing new, nothing very
special in terms of, I don't know, reinventing the wheel because you know
the mechanics and you know everything that stands in the back of it. I have
a lot more information about how the process works. This is very
transparent in terms of the configuration of the devices and so on.
Essentially we're running a set of route servers that are announced in the
IP prefixes for the IPv4 and IPv6, and this is again nothing new, because
there are better than us like team Cima for example, but what we enabled in
2004 when the Polish Internet was kind of booming in terms of new service
providers opening the operations, very shortly one after the other, what we
actually enabled is the sending of the prefixes between the interested
parties. So you can actually announce the information that you are being
attacked and the attack should be dropped by the originating party. Of
course, it's based on trust and we can have our very interesting discussion
after that for the last ten years I think we have built enough trust to
actually have some cooperating service providers and consent providers and
essentially customers, that are sending and receiving the IP traffic to
build some working community.
And right now we are moving into the phase when I would like to open the
project to the international community, if it's of interest for anybody. We
are actually using a number of communities, this is also documented on the
project page, if you have any information and dubs, try to ask me or just
join the mailing list, because it will be in English also.
So we are enabling not only remote trigger about blackholing base on the
source but based on destinations. As you can see on the slide we are also,
some of the project members are also trusting each other up to the point
when they actually event accept the prefixes marked by ?? marked by the
attacked victim and they actually can stop traffic from originating from
their own network, which of course again is based on trust. Requires
authentication things like that, but this is something that we are trying to
take care of.
What we are doing apart from just sending the prefixes and controlling them,
are the entrants and the announcement point. We are also experimenting with
BGP FlowSpec, so I have set up the two route servers that are based on the
IOS XR, we can send the employee spec information, receive them, check for
validity and things like that. I am also thinking about enabling the CIDR
for the blackholing project. Unfortunately, of course, the ROAs that are
being certified by RIPE usually have the shorter mask in terms of being
usable to actually the validity of the prefix being announced in the
project. Because if you are being attacked you are usually trying to stop
attack on a number of IPs, not entire, your entire network. But anyway, we
are also trying to work in that direction, I think also about setting
alternate cache for the project just to have the information that is being
validated.
What I have learned from the project and what we could do on actual
enabling. We can skip this, you can just check with the browser what's
going on in the port hole, is that by forcing people or by people that are
joined in the project, we can also enable some best practices and I fully
concur with Andrei and with others in this room that we need to have some
discussion about the best practices in the Internet. There is no easy way
to actually enforce that, but Service Providers, from my perspective,
Service Providers and our customers that are actually joining the project,
also open up into the discussion about, for example, enable the spoofing
prevention and things like that that are actually essential to be, for the
Internet to be healthy. And this is also a good discussion to have in terms
of what we can do actually in a tangible way to stop the spoof traffic, so
also stop the DDos attacks because this is also one of the major problems.
So my call?out to you is actually to just go lieu the page, ping me if you
are interested in becoming the member of the project or if you have some,
want to have some discussion about some technicalities of the project, it
will be ?? everything is on the web page, it will be soon translated into
English, it's not yet complete. If you want to join the project and donate
internationally some space to actually connect the equipment, also please
ping me, I would be very grateful to have this. We have a lot of equipment
and not enough place to say actually put it down. Right now in terms of the
coverage for Poland we are okay, we can skill a number of times higher than
we are right now, but for Europe and internationally I think it won't be
possible.
So that's all. Finished. Any questions?
AUDIENCE SPEAKER: Nick Hilliard: I think from a technical point of view
this tool looks really useful and some bits of me would really like to get
involved in this. From a political point of view, I can only ?? I can't
really find words to describe how catastrophically awful it is. There are
law enforcement agencies, courts, copyright agencies and a wide variety of
organisations around Europe who would love to get involved in this. And I
think from this point of view it is a socially very corrosive project, which
I find have I disturbing. Technically it's beautiful. Layer 9 and above.
Not so good.
LUKASZ BROMIRSKI: You are absolutely right. That's the problem that we
have the split of the ?? but I'm trying to focus on more technical part of
it and just do something.
Thank you very much.
(Applause)
JOAO DAMAS: Next up Alex Band from the RIPE NCC.
ALEX BAND: I'll try to do this as quickly as possible. You will certify
provider independent end user space, totally live, you can do it now,
essentially I'm done now. But this was proposed by Erik Bais on the 3 May
2013, reached consensus on the 2nd October, at which point we immediately
started with the implementation which turned out to be pretty complicated.
Because essentially, this is a service that was member only sitting in the
LIR portal and it now all of a sudden meant that we had to make the LIR
portal available for people who are not members. That was a little bit
tricky. There are a couple of requirements for getting this certificate.
First of all, you need to have an end user agreement with the RIPE NCC or it
needs to have been submitted to the RIPE NCC and verified. Essentially, the
whole 2007?01 policy thing, if you have that, if it's submitted and
verified, it's fine.
And we need to make sure that all of the database records about your
resources match with all of the information that we have in our registry.
That's a little bit our own fault obviously because we allow a lot of
freedom in the RIPE database, allowing people to change, for example, the
organisation ID or the organisation name within the RIPE database, making
the registry and the RIPE database out of sync. What we try to do is before
we give you a certificate, get those two things back in sync and make sure
that it never goes out of sync again. Which is something that we also
built. And thirdly, you need to prove that you have authoritative control
over the resources that you would like to get a certificate for. And this
could be either the sponsoring LIR or the PI end user, depending on who has
the maintainer over the objects in the RIPE database. And what we really
wanted was to have just one flow, something really simple, that both the
sponsoring LIR or the PI end user could go through and just request a
certificate, so I wanted one process for to cater to both audiences
essentially.
Which means that I can pretty much skip this slide because that's what I
told you.
Change the LIR portal, build single sign I don't know support, so again RIPE
NCC access sign on the RIPE database the authentication that the LIR portal
uses and we can match it to something that is happening in the RIPE
database, establishing that link. We have done that. We have logged a
couple of attributes in the system.
As I said, and lastly just make the flow super easy for users. I'm really
proud of what the team has achieved because this is really just what it is.
One box. The option address kind enough to allow me to use his registry or
his resources. You are signed in as a certain user. You can fill in your
name, organisation name, you can fill in a prefix, you can fill in,
essentially, whatever you know about your resources. Then it does a look?up
to see what the associated organisation is, and then it has a look on what
the maintainer of that organisation is.
So, you can, like I said, fill in the name or a prefix, if gives you the
maintainer and as soon as you properly fill in the password it establishes
that link, the link between the SSO account and the maintainer of the
organisation object in the RIPE database.
And then, it performance a couple of checks on the resources. So, whether
there is and org reference at all. Whether that org references match with
the RIPE NCC internal registry records. So the org ID. And it checks
whether the org name matches. If something is wrong it will give you a
little exclamation mark and it tells you, please, sponsoring LIRs should
contact LIR help [at] ripe [dot] net to get this resolved. We'll make sure that
everything is fixed together with an IPRA then everything will just show up
in green and you can continue to RPKI. It's as simple as that.
So, getting a certificate after this is just the normal process that LIRs
follow as well. So, these non?members, if you have done this process as a
non?member, we will then grant you LIR portal permissions. So, anyone can
then log into the portal and they will have access right now to RPKI
management only, and of course we have ideas on expanding that so you can
for example edit organisation details.
Ripe.net /certification, go and get your certificates, if you have any
questions, please let me know.
JOAO DAMAS: That was certainly clear and to the point. Thank you. The
process seems simple enough and if there is any questions? How could there
be?
(Applause)
ERIK BAIS: I actually do have a question. So, we actually played around
with this a bit, currently we see maintainers that have changed LIRs, so
we're not the sponsoring LIR any more, but we still see them in the drop
down list in the LIR portal. How does that work exactly? Because now if we
check them we say we don't have any resources to certify under this
organisation ID, for instance.
ALEX BAND: I really need to have a look at that specific case and find out
why that is happening in that way, because I don't really know. I don't
have an answer for you.
JOAO DAMAS: Okay, next up Denis.
DENNIS WALKER: I'll go through this very quickly, I have basically a couple
of things to announce to you and then a couple of questions to ask you.
We have made some changes to the syntax of the aut?num object which you need
to be aware of. We have added the option at sponsoring org attribute which
is always created by the registrations services but it is in your object.
We have added a mandatory status attribute which is auto?generated by the
software, this was needed partly for the Legacy situation, but it makes it
clear what the authoritative source of the aut?num object is.
Neither of these should be changed by the users, the one set by RS the other
is auto?generated by the software. We have tried to make the software as
tolerant as possible to mistakes, so we don't want to fail your updates,
specially auto?generated updates and aut?num objects. If you missed them
out or you put the wrong values in. We'll basically fix it for you, we'll
add a warning, but we won't fail your updates on them. We have wrote a very
extensive FAQ which explains all this, which means many of the questions you
ask. All the information is there for you to read.
A couple of questions: RIPE 66 George mike son from APNIC did a presentation
on simplified authorisation for route creation. Drop the requirement to get
the authorisation from an AS number. At RIPE 67 a paper was presented on
the quality of the routing data in the RIPE database. And at RIPE 67 I also
did a presentation on possibilities of restructuring the aut?num object.
Thins then, nothing has actually been said. So, basically, to me these are
still open questions, where do we go from here? Do you actually see a
problem with any of these things? Do you want us to do anything or do you
want us to just forget it and get on with our lives? Rudiger.
RUDIGER VOLK: Don't mess around with route. Yesterday, I had some comments
on what route is being used at the moment. Not everybody is using it the
same way. But traditional definition that has been in RPSL and in the RIPE
NCC's implementation has been used for a long time and I don't want to see
any change of that that's going to break our processes.
DENNIS WALKER: So, basically, we just want feedback from you. We want a
consensus. If you don't think anything is broken, you don't think anything
needs fixing, just tell to us drop it. If you see there is something that
needs doing with these issues, let's make a plan on how we move forward and
actually do something.
Last point. Is references to deleted ASNs, an open question to you is are
these a problem? When somebody deaths an ASN number and it still exist,
does this actually cause a problem with routing or can we just completely
ignore it and forget it and move on with our lives or do they need to be
cleaned up? So, if they do need to be cleaned up, should we fail updates on
your aut?num objects if you reference non?existing ones? Should we add
warning to tell you if you automate this process you probably won't even see
the warnings? Should we write some software to automatically clean them up?
If so, when should we do, it straight away or after some delay? And a
situation, supposing ?? I have just randomly picked these two numbers.
Supposing AS 2 and AS 5 have some peering arrangement between them and you
delete AS 2, then we automatically delete all the references so it's clean,
and we reissue AS 2. Somebody actually updates AS 5 and puts back the
original peering agreement they had with AS 2, which is now a different
organisation. So, even doing automated clean ups, this isn't really always
going to work because there is this two?way relationship here which we can't
?? the software just can not know whether that relationship has just come
back and AS 5 was the new one or the old one unless you have some kind of
two?way process for matching up import export lines, so basically we don't
have answers to this. We are trying to clean these up so we can re?issue
them, but we don't have an answer for how to do it. Alex.
AUDIENCE SPEAKER: Please get on with your life.
DENNIS WALKER: But then, what you are saying is we can re?issue these 16
pit AS numbers and we don't give a damn the fact that they still splattered
all over the database?
RUDIGER VOLK: I guess, I guess it is not something that you wanted to do to
clean up all of the world, because there are about, I don't know, umpteen
many rerouting registries that contain garageage.
DENNIS WALKER: But we don't want to have a registry that contains garbage.
RUDIGER VOLK: Then have a look at what's out there and I can privately point
you to ones that have lots of garbage and ?? really okay ??
DENNIS WALKER: We're not looking at those we're looking at the RIPE
registry.
RUDIGER VOLK: Kind of, I think you should just say well, okay, people who
do not clean up their objects, do not clean up their objects.
DENNIS WALKER: So you are saying this actually has zero impact anywhere in
the routing situation.
RUDIGER VOLK: Well, the thing is if one of my customers gives me an AS set,
references some AS set that references another AS set that contains crap, I
may actually tell my customer that I do not accept AS sets that actually
evaluate to be ?? that I myself am their transit customer, as an example for
seeing crap. That happens in the real world. No ?? kind of, if people do
not ?? if people do not actually maintain their data, doing partial
corrections is not going to help a lot. You may ?? you may send out
warnings that hey, you got some crap in your thing and we have seen the
transition that makes your thing going from looks clean to definitely has
crap, but I would not interfere with the objects that are maintained by
their owners.
JOAO DAMAS: I think I am in full agreement with Wilfried. Warnings, okay.
Trying to secondguess stuff, there are many reasons why the AS may not be
there and if the end result is that because I don't do something I end up
giving transit to someone, I'm sure I'll fix that pretty quickly.
AUDIENCE SPEAKER: I think even doing warnings is doing too much, because
you can never make your warnings complete and really correct, the RIPE NCC
just does not have the information to do these checks. And the operational
impact is zero to none except if I mess up my own data or blithely accept
messed up data from someone else, and that's also not a problem that you can
fix.
NICK HILLIARD: In theory I have no major with this. What worries me is
that RPSL syntax is so convoluted that there are going to be a number of
edge cases where you start interfering with somebody's policy you may break
it in weird and unexpected ways. It's probably only going to affect a
handful of hard core RPSL users, but they do exist, so I'd be a little bit
cautious. I'd like warnings though, I think warnings are a pretty sensible
idea.
DENNIS WALKER: We had and action point from the services Working Group to
actually clean up these AS numbers that are now in quarantine because they
are still references. Is there consensus from this room to tell us,
basically, hands off and you don't want us to do any kind of automated clean
up of these references?
JOAO DAMAS: That's correct. Of the object itself when you have issued, I
assume you start again with a clean object. But the references, I think
it's just asking for trouble.
DENNIS WALKER: We were just about to do it, so you are basically telling us
hands off?
JOAO DAMAS: Yes, I think that's the answer.
DENNIS WALKER: As long as we know. If you tell us, that's fine. We were
about to run scripts which would automatically remove all these reference
and reformat some of your objects. If we're told not to touch them, fine,
we'll drop it.
JOAO DAMAS: Save yourself some trouble I'd say.
DENNIS WALKER: Okay. That's fine.
JOAO DAMAS: If you think you can do the warnings, that makes sense.
DENNIS WALKER: We have sent e?mails to everybody that owns an object or
manges an object that has references to deleted AS numbers. A few of you
actually cleaned them up. The majority didn't respond to the e?mails.
JOAO DAMAS: We are a little bit over time but still there was a promise we
made last, during the last meeting so we would like just to touch upon it a
little bit.
A few weeks ago we posted the proposed new Charter for the Routing Working
Group on the mailing list. We only received feedback from one person, Job
Snijders. I would like to see if ?? we're all here in this room, to see if
anyone has any other comments. I'll give you a few seconds to read it.
This is basically an update to what was already there to basically clean up
some stuff and expand it, to describe it better, what we think we are doing.
If you agree that this is not what we are doing or should be doing, then
speak up. Given that we are a little bit over time, I'm not going to press
you to actually say anything right now. If you want to think more about it
but please do comment on the list so that we can wrap this up before the
next RIPE Meeting.
Okay. With that said, is there any other business that people want to bring
up? It doesn't seem like it, so this is the end of the meeting.
Thank you very much for all being here. I hope to see you soon or at the
next RIPE Meeting in London, November I think it is.
LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
