routing-wg
Threads by month
- ----- 2026 -----
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2000 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1999 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1998 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1997 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1996 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1995 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1994 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 1993 -----
- December
- November
- 3 participants
- 4432 discussions
These are some notes that I made as I was preparing my presentations
for the RegTechs meeting in San Diego Jan31/Feb 1. I have revised them
(some what) in light of some of the conversations & presentations made
at the RegTechs meeting.
There are undoubtably holes & inaccuracies in these notes; please
correct any that you see.
--asp(a)uunet.uu.net (Andrew Partan)
BGP4 deployment status
There are not that many folks that have deployed BGP4 yet. This
is not good.
So far, AlterNet, Ebone, SprintLink, ICMnet, EUnet, TIPnet, PIPEX, and
AS1133 (CERN) have deployed BGP4 (that I know of). ANS is behind their
announced schedule. This list is incomplete (I sure hope that there
are other folks out there that are running BGP4 that I do not know
of). Europe seems to be further ahead than the US (I have heard that a
number of European networks are using BGP4; but I don't have a list).
Not all of these folks are running BGP4 between them yet - e.g.: the
AlterNet/AS1133 link is still BGP3.
People are not making public their BGP4 deployment plans, nor are they
making their routing plans public (ala the RIPE routing registry
database). Without this data, it is really hard to know when or if we
can announce CIDR routes safely.
There are already CIDR-routes (non A/B/C routes) that are being
announced in the Internet today. When I last checked (Sunday 1/30/94),
all but one of the more specific routes (the A/B/C nets) were also
being announced.
BGP4 is real; BGP4 works; people need to deploy it; people need to
deploy it now.
We still don't know all of the folks that need to deploy BGP4.
We still don't know what will break if CIDR routes are used.
Implementation status:
Cisco code is working & deployed in most of the nets that are
running BGP4. Gated code is working & deployed on AS 1133. 3com
code is working on the BGP4 test net. I don't know the status of
any other code.
Why is it so important that we get BGP4 & CIDR working & working now?
Routing table growth.
16 Meg ciscos may only be able to support 25K-30K routes. [The
jury is still out on this one; cisco is continuing to improve their
code to put more routes into the same amount of memory. cisco is
also looking at 64 Meg routers.]
Peter Lothburg took a look at his routers (Ebone & ICMnet) and found
that he could only support approx 18K routes total!
On ciscos (at least), the number of routes that you can support depends
on how much free memory you have - memory is used for the forwarding
table, the routing table, and for updates (and other things). The more
destinations you see the larger your forwarding table is - so central
routers (like ICMnet & Ebone) will have more memory used for forwarding
tables. Routing table size is the total number of routes you have plus
how many different paths you have to each of those routes (the Ebone
and ICMnet see nearly every route with something like 5 paths).
Routing updates use memory for both incoming updates from your peers
(eBGP & iBGP) and for outgoing updates (most notably for iBGP peers -
since every incoming update from an eBGP peer is (typically) sent to
every iBGP peer). The more routing updates you get (the more unstable
the overall network is), the more memory you will use. Central routes
tend to see lots more updates (this is not entirely true since cisco's
BGP4 code has some dampening of updates - they delay forwarding updates
for a short while, so that if a net goes down & then back up fairly
quickly, you may not see any update at all downstream).
When ciscos start running out of memory, they try to conserve memory by
delaying processing of incoming updates and sending of outgoing updates
(rather than just hitting the wall & tipping over). This means that
routing may take longer to stablize & may not ever stablize as things
get really bad.
In any case, Peter's routers have about 1.9 Meg free today; AlterNet
routers have approx 4 Meg free - the same number of total routes, but
different routing policy and (probably) fewer destinations, updates,
and paths.
The ANS ENSSs may only be able to support 25K routes. [ANS thinks that
they can up this by another 5K routes to a total of 30K.]
We are now at 16,788 routes (as of 1/30/94 17:00 EST).
[17,410 as of 2/11/94, 14:00 EST.]
I did some analysis of routing table growth from a number of
different angles, and all pointed to running out of memory by mid
summer (unless we do something). [This used 25K as the drop dead date -
we should be hitting 18K in about 1.5-2 weeks.]
The growth rate seems to be 1000 net every 3 weeks.
[I looked at routing table sizes & growth over the last few months;
also at current doubling time (9 months; ref ALE working group);
also at free memory usage in my routers. All of my projections
came out with approx the same drop dead date of mid summer. I also
did not leave any memory for things like packets, so my dates are
overly optimistic.]
[I also looked at some data provided by Merit (their active net
counts), and their projections agree very closely with mine - approx
mid summer for 25K routes and 1000 nets every 3 weeks.]
We need to attack the routing table size on a number of fronts -
router vendor code changes (to use less memory per route), router
hardware changes (to add more memory), changes in routing policies
(things like more use of default routes & suboptimal routing),
newer routing protocols (that do not need full routing tables on
a large number of routers; things like route servers), and BGP4/CIDR
deployment.
The one that seems to be the easiest & quickest to deploy is
BGP4/CIDR.
The problem is that if I CIDRize my own routes, I can save about
1000 routes in my own tables (and push death off by maybe a month
or so).
I need you to CIDRize your routes to save space in my routing
tables.
I could also proxy aggregate your routes, but proxy aggregation is
hard. If I hear your routes via several possible paths, and if
the same aggregation is not done in the same way on all of the
paths, then traffic may go over suboptimal paths (since traffic
always takes a more specific route over a less specific route).
Proxy aggregation is doubly hard, if I don't know about all of the
possible paths that I could hear your routes over.
[There was some discussion about where it was safe (or safer) to do
proxy aggregation - basically it all boils down to knowing the (local)
topology and lots of communication between the parties involved.]
This gets to routing registries.
People have to publish their routing policies in some public place
so that other people can look at these policies and try to figure
out if some change that they are contemplating (like announcing
CIDR routes) will cause problems elsewhere in the Internet.
These routing policies need to be in some common format, so that
tools can use them.
The only such database that I know of is the RIPE database. People
should use this. Two folks from RIPE will be giving a talk on this
later (Daniel Karrenburg & Tony Bates). [Merit will also be doing a
routing policy database & is going to coordinate with the RIPE folks.
The Merit & RIPE folks should be able to say more on this.]
A bit more on proxy aggregation.
If you know the local topology well enough, and if there is
communications & coordinations among the people involved, you can do
proxy aggregation safely.
A couple of examples:
BGP4 network 'B' connects to non-BGP4 stub network 'S'.
S has no other connections to the rest of the world.
B --- S
B can do proxy aggregation of S's nets. [Note that B can probably
proxy aggregate w/o even talking to S, but this is probably a bad
idea.]
BGP4 network 'B' connects to non-BGP4 network 'S'.
'S' has just one other connection to non-BGP4 network 'T'.
T has no other connections to the rest of the world.
B --- S --- T
B can do proxy aggregation of S's and T's nets.
BGP4 network 'A' connects to non-BGP4 network 'S'.
BGP4 network 'B' connects to non-BGP4 network 'S'.
S has no other connections to the rest of the world.
A --- S --- B
A & B can do proxy aggregation of S's nets. Note that A and B need to
do the *same* proxy aggregation, or things may not work (routing follows
the most specific route).
There are other examples; they all depend on complete knowledge of the
(local) topology and coordination between all of the parties involved.
Obviously as the topology gets more complex, and the number of parties
grows, this gets to be a harder & harder problem.
Some of the conclusions on deployment of BGP4/CIDR
People are deploying BGP4; the code seems to be working just fine.
People are going to be announcing CIDR routes and doing proxy
aggregation fairly shortly (like w/in the next week or so). Partially
this is a matter of self defense, so that routers don't tip over.
It looks like things will work, if there is a large enough BGP4 core,
and if people are either part of the BGP4 core or have a default route
to the BGP4 core, or have a default route to someone who has a default
route to the BGP4 core (basically a path of defaults, all going towards
the BGP4 core).
I think that the sites that are currently doing BGP4 form a large
enough core for things to work. If ANS can get things working to join
the BGP4 core, then things will be better; however ANS already has code
deployed that can use a default route (most likely to AS1133). It
would also be very useful for the CIX-West routers to be part of the
BGP4 core.
I also think that everyone either is already part of the BGP4 or has a
default route towards it. This point was brought up at the RegTechs
meeting, and no one voiced any objections.
So, I think (& hope) that we are in (more-or-less) good shape.
The next step: publish your plans for BGP4 and CIDR!
--
Jean-Michel
1
0
New/Revised RIPE Document Announcement
--------------------------------------
A revised/new document is available from the RIPE document store.
Ref: ripe-108
Title: Support of Guarded fields within the RIPE Database
Author: Tony Bates
Date: 11 February 1994
Format: PS=45180 TXT=18019 bytes
Obsoletes:
Obsoleted by:
Updates:
Updated by:
Old:
Short content description
-------------------------
This document describes an overview of the RIPE database attributes
which are guarded, the procedure for updating these guarded attri-
butes and the general use of "guarded" fields within the RIPE data-
base.
FTP Access
----------
All RIPE documents and Internet RFC`s are available via anonymous FTP
from host ftp.ripe.net. Type "ftp ftp.ripe.net".
Login with username "anonymous" supplying your email address as the
password. After logging in, type "cd ripe/docs/ripe-docs" followed
by the command "get filename".
The relevant filenames for this document are:
ripe-108.txt for the ASCII version
ripe-108.ps for the PostScript version
Electronic Mail Retrieval of Documents
--------------------------------------
Documents can also be retrieved from the RIPE document store using a
mail server program. For more information on how to use the program,
send email to: mail-server(a)ripe.net with "send HELP" in the body text.
RIPE NCC Interactive Information Server
---------------------------------------
Type "telnet info.ripe.net". This is a menu driven service allows
the document store to be browsed. After reading documents you are
prompted as to whether you would like to receive an email copy of the
document you have just read. If you would, you simply enter your email
address and the document will be mailed to you.
Below are details of alternative methods of access.
Gopher Access
-------------
The same documents are available via a "gopher" server at
"gopher gopher.ripe.net".
WAIS Access
-----------
There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index
for RIPE documents "ripe-docs.src"
WWW Access
----------
For those who wish to add this home page at the RIPE NCC to their own
customized home pages, it can be accessed as:
http://www.ripe.net
MIME Mail Reader
----------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version of the RIPE
document.
SEND ripe/docs/ripe-docs/ripe-108.txt
1
0
Here are the draft minutes of the Routing WG meeting in Amsterdam.
Comments welcome,
--
Jean-Michel
----------------------------------------------------
RIPE Routing-WG Draft Minutes
Amsterdam, Tuesday January 25th
Minutes: Jean-Michel Jouanigot, Gilles Farrache (scribe)
0. Previous minutes, agenda.
The previous minutes and the agenda were approved. Gilles
Farrache volunteers as a scribe.
1. Ripe-81
1.1 Introduction; AS registration statistics (NCC)
Tony Bates presented briefly some statistics about the
Ripe-81 objects registration in the RIPE database during
the plenary session. Almost 70% of the ASes in Europe
are now registered. This ongoing effort should continue,
and AS guardians are encouraged to check that their
routing policies are well registered and kept up-to-date.
Ripe-81 seem now to be well accepted within the
community.
1.2 Guarded attributes (NCC)
1.2.1 Implementation (discussion, hopefully agreement)
Marten Terpstra presented the implementation of
the Guarded attributes in the RIPE database. The
implementation was agreed. For more details, see
"Support of Guarded fields within the RIPE
Database", Final Draft. This document can be
obtained from the RIPE NCC, and will soon be
registered as a RIPE document.
AS objects cannot be registered using the
'auto-dbm(a)ripe.net' automatic update procedure.
These objects have to be sent to
'ripe-dbm(a)ripe.net'.
When 'inetnum' object is deleted, and this
network is tagged with an AS, the guardian of
this AS receives a notification.
This new procedures should be operational
beginning of February.
1.2.2 Block splitting (Marten), discussion
At the last Working Group meeting, an agreement
was reached concerning 'block splitting': when
one network within a block is tagged with an AS
or a community, the block has to be split, and
the owner of this object notified. Daniel
Karrenberg expressed some concerns about this,
arguing that the Database should not modify an
object since the users of the database (Local
Registries) may have problem to follow up these
modifications. Since no better solution was
found, it was agreed to confirm this decision,
unless a better solution is found by the Database
Working group.
1.3 Use of Ripe-81; conversion of Ripe-60 (reminder, brief)
The action on Jean-Michel Jouanigot to coordinate
this migration is kept open: the migration is
postponed to February, when all the necessary
tools in the RIPE database concerning guarded
objects are implemented.
1.4 Ripe-81 enhancements
A new version of the Ripe-81 document, including
some extensions, was sent out on the working
group list, titled 'RIPE-81++'.
1.4.1 DMZ (Description of Inter-AS Networks in
the RIPE Routing Registry" (ptraceroute issue).
Status (brief)
This extension, proposed by Daniel Karrenberg
some time ago, is already integrated in
RIPE-81++, and implemented in the RIPE database
by the PRIDE Project. It is now commonly used.
1.4.2 Colouring, proposal, discussion
Jean-Michel Jouanigot presented a few slides
explaining this new extension. Details about
colouring can be found in Ripe-81++; the
principles are:
o Currently: 1 policy per AS; Variations =
Communities
o Colours : small variations within one AS; hints
for CIDR aggregation; avoid network based lists
o Implementation: Path attribute (BGP); local to
an AS; associated with communities.
This new idea was discussed, and a series of
clarifications were made:
o There is some kind of overlap between colours
and communities, but a colour is local to an AS,
and the colour information is set at the source
of the network announcement, and not in the
receiver of this route (network based lists based
on communities).
o Someone using colours for routing should trust
the remote AS for colouring his networks properly
when they leave its AS.
o One can use both mechanisms (colours and
communities) to express routing policies. It is
therefore proposed to extent Ripe-81 so that it
can support:
as-in: AS1234 10 COM1, where COM1 is a community.
o It is proposed to limit the number of colours
to 16 per AS, since it is the number of bits used
in the BGP path attribute today. It was observed
that the latest draft of BGP4 dropped the BGP
path attribute. The attendees of the coming IETF
from RIPE should propose to restore it.
o A network can be marked with several colours.
1.5 Ripe-81 limitations and pending issues
1.5.1 AS macros (Ripe-81 proposal), examples,
discussion
The idea of AS macro was already described in the
Ripe-81 original document. It was agreed to
accept the AS macros principle, include it in
Ripe-81++ and ask the Ripe NCC to implement it.
Action: RIPE NCC, to implement the AS macros
1.5.2 Default route representation (Blasco), what
can't we represent ?
Antonio Blaco Bonito presented his concerns about
default route expression in Ripe-81 format.
Jean-Michel Jouanigot presented several
configurations were the routing policies can't be
expressed in RIPE-81 format, since Ripe-81 does
not understand the notion of AS Path. There was
a long and well debated discussion about the idea
of AS Path in Ripe-81. This is a known
limitation of the syntax, and network operators
are sometime not able to express the policies
they are implementing. Such a limitation
prevents Ripe-81 to be used to generate Router
configurations. Two different approaches were
proposed:
a) Daniel Karrenberg: Add an 'advice' in the AS
object, something which could express "I don't
want to cross AS X".
b) Laurent Joncheray: Include the AS Path
concept in Ripe-81.
Solution (a) goes along with RIPE-81 principles:
keep it simple. But up to what point can we go
in this direction ? What's the purpose of
RIPE-81 if we can't generate the router
configurations out of the database ?
Solution (b) implies that the network topology
would tied with the policies, and it may be
difficult to keep the Routing policies coherent
inside the database. Macros could possibly help.
Since no consensus was reached, it was decided to
investigate further in both directions:
Action on Daniel Karrenberg: Write down a
proposal for solution (a)
Action on Laurent Joncheray: Write down a
proposal for solution (b)
1.5.3 Inter-AS Local Information, discussion
This extension, as well as the action attached to
it (Peter Lothberg), was dropped.
2. Closing, AOB
A FAQ on CIDR by Daniele Vannozzi was sent to the Working
Group mailing list. This document was unanimously
recognized as good and it was advised to be proposed as
an RFC. Comments on this documents should be sent to
Daniele Vannozzi, with copy to the list. The RIPE NCC
will make the document available.
Since RIPE is studying a possible reorganization of its
working groups, the chairman asked the participants if
new topics should be dealt with or if the scope/charter
of the group should be changed. The following was
suggested:
o CIDR and Aggregation should become a high priority of
the group
o BGP4/IDPR follow on
o The group should avoid, as much as possible,
overlapping interest with other RIPE working groups,
especially with the Database working group and the EEPG.
----------------------------
1
0
[Apologies for wide distribution, think it is important though]
Folks,
Please find below a slightly updated version of the guarded attribute
procedure document. For those of you who manage an AS, please not that
starting coming Monday, the aut-sys field in the network object will
become guarded, and can only be updated thru the procedure described
below. We have created accounts for all ASes we currently see routed
in Europe, and if you do not have your account yet, please come and
get it as soon as possible and check out the files we have created for
you. Please send requests for these accounts to <ripe-dbm(a)ripe.net>.
Also if you know some of your AS neighbors have not got their account
yet, and are perhaps not on any of these lists, pass this message.
If you have questions, send them to ripe-dbm(a)ripe.net as well, or
directly to me.
-Marten
Support of Guarded fields within the RIPE Database
* FINAL DRAFT *
Tony Bates
Document-ID: ripe-1nn
1. Introduction
The RIPE database contains several significant attributes which make
it well suited for use as part of operational procedures and confi-
guration. Most significantly are the attributes which make up the
RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely
the "aut-sys" and "comm-list" attributes. For these attributes to
be of use to service providers they must be:
o Properly authorised.
o Efficient for both maintainers of the attributes and the main-
tainers of the whole database.
This document describes an overview of the RIPE database attributes
which are guarded, the procedure for updating these guarded attri-
butes and the general use of "guarded" fields within the RIPE data-
base.
2. The Database Guarded Attributes
All the guarded attributes currently supported in the RIPE database
are contained within the "inetnum" or network object. However, the
association corresponds to their relevant guarded database objects.
If we look at a simple example this becomes clear:
inetnum: 192.87.45.0
netname: RIPE-NCC
descr: RIPE Network Coordination Centre
descr: Amsterdam, Netherlands
country: NL
admin-c: Daniel Karrenberg
tech-c: Marten Terpstra
connect: RIPE NSF WCW
ripe-1nn.txt February 3, 1994
- 2 -
aut-sys: AS1104
comm-list: SURFNET
ias-int: 192.87.45.80 AS1104
ias-int: 192.87.45.6 AS2122
ias-int: 192.87.45.254 AS2600
rev-srv: ns.ripe.net
rev-srv: ns.eu.net
notify: ops(a)ripe.net
changed: tony(a)ripe.net 940110
source: RIPE
This shows that the RIPE-NCC network belongs to autonomous system
1104 and is in a community known as SURFNET. This is valuable infor-
mation that could easily be used for example for routing policy pur-
poses (as well as other operational uses). Currently support for the
following set of guarded attributes is implemented:
aut-sys
The "aut-sys" attribute has a direct mapping to "aut-num"
objects as defined in RIPE-81. That is the Autonomous System
(AS) that the network number is a part of. As defined in RIPE-
81, a network can only belong to one AS and hence the "aut-sys"
attribute can only contain one AS number. The syntax of the
"aut-sys" attribute is:
AS<positive integer between 1 and 65535> (1). i.e. AS1104
comm-list
The "comm-list" attribute has a direct mapping to "community"
objects as defined in RIPE-81. A network can belong to more
than one community. The syntax of "comm-list" is:
Multiple text strings which cannot start with "AS" or any of
the <routing policy expression> KEYWORDS defined in RIPE-81.
routpr-l (2)
The "routpr-l" attribute has a direct mapping to "rout-pr"
objects as defined in RIPE-60 [4]. Networks can belong to more
than one routing privilege. The list of networks within a rout-
ing privilege represents the group of networks accepted/allowed
by a set of routers described by the information in the "rout-
pr" object. The syntax for "routpr-l" is as follows:
_________________________
(1) This represents a change from RIPE-50 [3] where
the "aut-sys" attribute was defined to be a positive
integer only, not containing the string "AS" at the
start. This change has been made to be consistent with
the "aut-num" object syntax.
ripe-1nn.txt February 3, 1994
- 3 -
Multiple text strings representing the routing privilege.
bdrygw-l
The "bdrygw-l" attribute has a direct mapping to "bdry-gw"
objects as defined in RIPE-60 [4]. Networks can belong to more
than one boundary gateway. The list of networks within a boun-
dary gateway represents the group of networks advertised by a
set of routers described by the information in the "bdry-gw"
object.
The syntax for "bdrygw-l" is as follows:
Multiple text strings representing the boundary gateways iden-
tification.
As these attributes are tightly coupled to their associated objects
it makes sense for these attributes to be updated not by the network
maintainer but by the maintainer of the referenced object(s). The
basic premise behind this is that these attributes should be used
for various operational procedures such as setting routing policy,
accounting and so on. For these attributes to be used by network
operators for day to day operations they need to be guarded in such
a way that can be trusted and are guaranteed to be unique - with any
conflicts quickly and easily resolved. The procedure for achieving
this is detailed below.
3. The Basic Procedure
For each of the guarded attributes detailed above, a list of all
networks having this attribute is kept separately from the general
database itself. These lists (also called `guarded files') will be
maintained and be served as the `only' source of membership informa-
tion used in the database. Normal database updates `never' change
these attributes. If an update includes such an attribute and a
discrepancy between the values in the update and those in the data-
base is found, a diagnostic message will be sent to the originator
of the update and the guarded value(s) will not be affected. The
attributes as defined in these files are incorporated in the data-
base once a day. To ensure proper control and authorisation, these
lists will be maintained at the RIPE NCC on the same machine that
contains the RIPE database. The "guardians" of the corresponding
database objects will have to maintain their own guarded files. The
guardians are provided with individually assigned login accounts at
the RIPE NCC. The guardians can themselves decide in what manner
they want to update their file. The NCC will offer interactive
logins, ftp logins or any other means that might be deemed useful.
_________________________
(2) It should be noted that both "routpr-l" and
"bdrygw-l" attributes have been agreed to be phased out
in preference of the "aut-sys" and "comm-list" attri-
butes as soon as the `guarded field' mechanism is in
place.
ripe-1nn.txt February 3, 1994
- 4 -
3.1. Some Details
As stated each guardian will be issued with an account on the cen-
tral NCC machine known as `guardian.ripe.net'. This account will
contain a `restricted' environment which will allow the guardian of
the relevant object to update their associated guardian file (3).
Wherever possible the account name issued to the guardian will be
the same as the object name.
For example, the guardian of the AS1104 aut-num object will receive
an account known as "AS1104". With each guardian account the
corresponding file will be parsed at each update run (once a day).
This file will contain the list on networks associated with the
object. See appendix A for details of the format and syntax of the
guardian files.
A tool will also be provided within the restricted environment to
syntax check the guarded file to avoid against possible typos and
errors.
With each account, an electronic mail address (this is a mandatory
attribute for all guarded objects) will be used by the NCC and data-
base software. To make this flexible for the guardian a ".forward"
file with the account which can be change when required. This will
mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to
correct guardian.
3.2. How does it work ?
For each of the guarded files found on `guardian.ripe.net' the data-
base software will load any guarded attribute value(s) for the net-
work object(s) listed in the guarded file. This will take place at
the same time as the database is garbage collected (currently at
0500 MET). If a conflict is found (i.e if more than one entry exists
for an attribute which can only contain one entry, currently only
"aut-sys" contains this property), the current value will remain
unchanged and all guardians involved in the conflict will be sent an
electronic mail message informing them of the conflict. See Appendix
B for an example.
If no conflict is found the attribute will be updated with the
guarded value.
Correspondingly, to remove a guarded attribute just remove the net-
work entry from the relevant guarded file and it will be deleted at
the next update run. To be notified of this delete the "notify"
attribute should be used.
_________________________
(3) As stated, the mechanism for updating the guardi-
an file will initially be by interactive login or file
transfer. However, this doesn't preclude other mechan-
isms in the future.
ripe-1nn.txt February 3, 1994
- 5 -
If a guardian file contains an entry which is not in the database
then the guardian will be notified as part of the conflict handling
procedure.
If an update is sent to the database software using another mechan-
ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri-
bute, this will not be allowed to change the guarded attribute. If
the value of the attribute is the same as what is currently
registered in the database then no warnings will be given. However,
if the update contains a value for a guarded attribute that is dif-
ferent to that registered in the database, a warning will be sent to
the originator and the guarded value will remain unchanged. Any
changes of other (unguarded) fields in the update will be checked
for syntactic correctness and if they pass will go through to the
database irrespective of any conflicts for the guarded fields.
When through the normal database update procedure an object with
guarded attributes is deleted, the guardians of these guarded attri-
butes will be notified of this deletion. Only deletions will be
notified in this way to guardians. For normal changes the "notify"
attribute of the database should be used.
Although the guarded process will run once a day as part of the
database garbage collection procedure it will also be possible to,
"on request to the NCC", run an emergency guarded update process for
a particular guarded object.
To have complete guardian accounts removed from the NCC machine, and
thus all references to this guarded value, please contact the RIPE
NCC at <ripe-dbm(a)ripe.net>. Removing an account and the guardian
file that goes with it means that this guarded value will not be
added any longer to any of the objects in the database.
4. Getting it started
As this is a new (and much needed, especially for the "aut-sys"
attribute) mechanism, a degree of `bootstrapping' is needed to make
it easier for network providers and IRs to transition to using the
guarded file procedure. The NCC has built an automated generation
scheme for attributes that are known to be in use (currently, this
means AS numbers). For all the AS numbers seen to be routed in
Europe, accounts for the guardians have already been put in place
having the guardian's mailbox point to a mailbox at the RIPE NCC.
For these ASs currently guarded files are generated on a daily basis
by analyzing European full routing tables. This means there could
(and almost certainly will) be some conflicts within the generated
guardian files.
As soon as the account is handed over, the auto-generation for that
guardian account stops and the mailbox is changed to the correct
guardian mailbox. Guardians can of course make use of the auto-
generated guarded files if they wish to check against their own
records. From the moment of `hand-over' it is now the guardians
responsibility to make sure their associated network(s) get the
ripe-1nn.txt February 3, 1994
- 6 -
correct guarded attributes by listing them in the guarded files.
The advantage of having this `bootstrap' method is that it will
allow population of the guarded "aut-sys" attribute to take place
immediately this functionality is enabled in the RIPE database
software. It also acts as an incentive for networks operators and
local IR's to transition to the guarded file procedure as soon as
possible.
5. Conclusion
The update procedure as detailed above has the following advantages:
o Authorisation of adding/deleting is guaranteed.
o No need for mailing back and forth of authorisation messages.
o Simple procedure for both database maintainers and guardians.
o Guardians keep full control of their attribute.
It allows for the addition of any number of guarded attributes in
the future. It describes a simple but effective procedure for main-
taining the guarded files whilst not precluding alternate mechanisms
in the future.
6. References
[1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P.,
Terpstra, M., "Representation of IP Routing Policies in the
RIPE Database", RIPE-81, February 1993.
[2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in
the RIPE Routing Registry", RIPE-103, December 1993.
[3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50,
April 1992.
[4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992.
ripe-1nn.txt February 3, 1994
- 7 -
Appendix A - Format of Guardian Files.
We propose to keep the file format as simple as possible. The name
of the file is identical to the name of guarded object. The format
used within the file is kept simple. It allows lines to be either
comments or the actual object entry that is to be guarded. A comment
must contain either a semi-colon (;) or hash (#) at the beginning of
the comment line. The object name entries must be exactly the same
as they are in the database. Currently, the only object containing
guarded attributes is the "inetnum" object so the file can contain
either the `well-known' dotted quad network notation or RIPE dotted
quad range notation. Here is a simple example of what the AS1104
guarded file would look like. The file would be stored in the home
directory of the AS1104 account on guardian.ripe.net and be called
AS1104 (told you it was simple). It would contain something like the
following:
#
# File : AS1104
#
; An alternate comment format
;
; This file was updated jan.dijkstra(a)gouda.nl
; on 940109
;
192.16.183.0
192.16.185.0 - 192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0
Empty lines in the file are also ignored but you are encouraged to
keep the file as concise as possible.
As stated above, a tool known as `checkguard' will be available to
make it simple to check the syntax of the guarded file.
ripe-1nn.txt February 3, 1994
- 8 -
Appendix B - Example of conflict handling
If a conflict occurs (e.g. by listing the same network number in
more han one AS guarded file), then each of the guardians involved
will be notified on the conflict by electronic mail. Let's look at a
simple example. Suppose the guardians for AS1104 and AS2122 update
their relevant guardian files and create a conflict by having the
same network in them. For this example he network in question is
"192.16.183.0". Here is the AS1104 guardian file:
#
192.16.183.0
192.16.185.0
192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0
And here is the AS2122 guardian file:
#
192.16.183.0
193.0.0.0 - 193.0.7.0
As you can see "192.16.183.0 exists in both files.
At update time the following mails are generated. Firstly, to the
guardian of AS2122.
Date: Fri, 14 Jan 1994 13:22:43 +0100
Message-Id: <9401141222.AA07125(a)ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net>
Subject: Guarded attributes conflicts found
To: as2122(a)ripe.net
Dear Guardian,
One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.
Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.
Kind Regards,
RIPE Database Conflict Department
------
"192.16.183.0" also appears in guardian files: AS1104
And similarly to the AS1104 guardian.
ripe-1nn.txt February 3, 1994
- 9 -
Date: Fri, 14 Jan 1994 13:22:42 +0100
Message-Id: <9401141222.AA07121(a)ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net>
Subject: Guarded attributes conflicts found
To: as1104(a)ripe.net
Dear Guardian,
One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.
Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.
Kind Regards,
RIPE Database Conflict Department
------
"192.16.183.0" also appears in guardian files: AS2122
>From this you can see conflict can be quickly and easily resolved,
assuming good collaboration between the guardians. The existing
database entry will of course not be changed with regard to the
guarded attribute) as long as there exists a conflict.
ripe-1nn.txt February 3, 1994
1
0
Dear all,
this is the draft minutes of the Database-WG meeting(s) at the 17th RIPE
meeting.
Any input and comments welcome, especially from those being affected by
these things in one way or the other :-).
Best regards,
Wilfried.
-------------------- start of draft minutes --------------------
17th RIPE Meeting:
Draft minutes for the DB-Working-Group meeting 25.1.1993, Amsterdam.
-----------------------------------------------------------------------------
Due to the scheduling (and the un-avoidable overlap) of some WG meetings,
the items on the agenda were treated in a different order than originally
proposed. However the minutes follow the original ordering.
0. Opening, Scribe, Admin
The DB-WG meeting was opened and Ruediger Volk volunteered to take notes.
As a direct result of the preceding meeting of the Routing-WG and following
other discussions the proposed agenda was amended (DB statistics for
Domain-Object, maintainance of e-mail attribute and .forward files for
guarded objects, timing considerations for guarded objects and values,
aspects of ownership of objects and deletions and inter-dependancies).
1. New Databse software
1.1 . current status
Marten Terpstra gave a concise report on the current state of the "new"
database software. Due to timing constraints (and the lack of documentation)
there is still no official distribution of the "New DB Software". However it
has already been successfully installed at a couple of sites.
The slides for the presentation can be found in
ftp.ripe.net:ripe/presentations/ripe-m17-marten-DB.ps.Z
1.2 . experiences
No operational problems were mentioned. Operation of the software, including
the organizational environment, is going very smooth and was generally
appreciated.
1.3 . documentation (who, how, when, what)
Documentation is still missing. A new effort is needed and will be made early
February. It has to be taken into account, that Marten Terpstra will primarily
work on the PRIDE project, reducing his involvement with the DB software.
Action (Wilfried Woeber, NCC): produce the necessary documentation for the
new DB software.
2. RIPE-Handles
RIPE-Handles are urgently needed to make progress in the area of Database
Exchange. Several possible methods of assigning these handles were discussed.
the group reached consensus that the RIPE-Handles will be of the form
RIPE-XYZ9999.
It was decided that from the DB's point of view, there exists only ONE
handle: the RIPE-Handle. Thus this handle is stored in the person object
in the "nic-hdl:" attribute.
For the initial population/conversion of the current entries, the value of
the NIC-Handle will be taken and converted to a RIPE-Handle by appending the
string "-RIPE". E.g. the NIC-Handle for Wilfried Woeber (WW144) will be
converted to form the RIPE-Handle (WW144-RIPE). This conversion will be done
only once for the inital population. There will then be a short period, when
missing handles can be provided by means of "vanity-handles". After a
to-be-announced flag-day, RIPE-Handles will be required for any operation on
person objects in the Database. Any vanity handles used MUST be properly
registered with the NCC! The same syntax has already been adopted by the
JPNIC and the AUNIC.
*** Please note that during the discussion (by accident) we all were talking
about a prefix format ***
The NCC was mandated to circulate an updated proposal, including operational
aspects, and after a short review-process (e-mail), go ahead with the
implementation.
Action (NCC): update and re-circulate the RIPE-Handle proposal and then go
ahead with the implementation.
3. PRIDE - DB Interaction
Editorial comment: RIPE-81++ was treated in the Routing-WG.
Currently there is no real pending issue with regard to the interaction
between the PRIDE project and the RIPE-DB. After discussing possible future
modifications or additions to DB objects, the NCC was mandated to go ahead
and implement changes/additions to support the PRIDE project (like the hidden
flags/options), unless there is a direct influence on operational aspects or
changes to the user interface to the RIPE-DB.
4. Future needs
4.2 . Delete Operation vs Guarded Field interaction
Various aspects of implementation of guarded objects were reviewed.
With regard to possible "delete:" operation on network objects that are
tagged with a guarded AS-value, consensus was to automatically notify the
guardian of the AS-value. Changes to such objects do NOT generate a
notification message. This functionality can be achieved by using the
"notify:" attribute. The "notify:" attribute for an object is evaluated
before the update is made. The technical issues of RIPE-81 was treated in the
Routing-WG.
Generally the transaction of deleting an object must be described.
The document with the proposal for implementing guarded attributes is to be
updated and recirculated for comment (e-mail, 14 days comment period). Then
the NCC goes ahead with the implementation as soon as possible.
Action (NCC): update and re-circulate the Guarded Fields proposal and then go
ahead with the implementation.
4.3 . Phase-out of RIPE-60 stuff
Jean-Michel Jouanigot continues to coordinate the migration to the RIPE-81
functionality. Any technical issues treated in the Routing-WG.
4.4 . Tools
A proposal to have a certain kind of "template-mode" for checking and/or
updating database objects was discussed. Several possible ways of
implementing this were discussed (like a special flag for the whois-client,
an interactive method at the NCC, providing a full template for further
processing). Any solution proposed should be usable on most platforms.
Action (NCC): investigate and propose facilities for a "template-mode" to
support the maintaining database objects.
4.5 . Syntax checkers (distributed, and/or @ the NCC)
The need for syntax-checking facilites for objects was again stated. The NCC
was asked to look into providing this functionality and come up with a
proposal.
Action (NCC): Investigate and propose a syntax-checking facility for the new
database software.
5. New/Revised Objects
5.1 . CLNS Routing "dom-prefix:"
Henk Steenman provided an introduction to the current version of the proposal
to have a database object for CLNS Routing. The only technical amendment
discussed was to present the CLNP addresses in the format of
xx.xxxx.xxxx.xxxx (no trailing dots). The NCC may have to review the current
shell of scripts supporting the database operations for limitations in
line-length.
The NCC was mandated to go ahead with implementing this object after another
short round of review (e-mail) of Henk's updated specification.
Action (Henk Steenman): update and re-circulate the "dom-prefix:" proposal.
Action (NCC): implement the CLNS Routing Object.
>>>>>>>>>>>> I'm going to ask Henk to provide the (updated) proposal for the
presentations directory!?
5.2 . status of "connect:" and value "LOCAL"
Decision about the future of the "connect:" attribute for a Network Object
was postponed after full deployment of the RIPE-81 stuff. It is expected that
the "connect:" will be phased out and be replaced by a different mechanism
(community?). The "connect:" attribute is no longer mandatory.
5.3 . Domain Object
The status of the Domain Object was reviewed, prompted by the fact of poor
coverage in the database. Again the object was felt to be useful, although
currently there is little operational influence of registering (or NOT
registering) domains in the database. Consensus was to ask the DNS-WG to
review and maybe update the definition of the Domain Object.
Action (Francis Dupont): Have the DNS group review the Domain Object and come
up with either a recommendation for retirement or with an updated
functionality
5.4 . others
The "notify:" attribute is already implemented and is already used by the
database software.
The "maintainer:" attribute is already implemented but currently not used by
the databse software.
6. Exchange Format
6.1 . current status
No progress has been made due to the lack of RIPE-Handles. Can be progressed
after implementation of RIPE-Handles.
6.2 . recommendations for further action
As an aside - the group propsed to NOT enforce uniqueness of network names.
7. DB statistics (Domain-Object)
Having stistics about the DB coverage of domains was seen to be potentially
useful. Postponed to wait for the Domain Object review by the DNS-WG.
8. Maint. of e-mail: and .forward for guarded objects
After evaluating possible szenarios it was decided that an automatic
modification of either the "e-mail:" attribute of a guarded object or the
.forward file for the guardian's account is not desirable. Responsibility of
the maintainance remains with the guardians.
9. Timing considerations for guarded objects, values, secondary DBs
Some operational issues of implementing guarded fileds were reviewed. Aspects
discussed in more detail were:
- timing and interlock: Some mechanism must be set up by the NCC to allow for
checking the merge/update status of the current version of the database.
This should allow for an automatic delay of retrieving the DB for local use
and/or providing read-only copies. The NCC will come up with a technical
proposal how to do this.
- change control: in order to preserve the update history for databse objects
a structured scheme was proposed. This method preserves the "changed:"
attributes supplied by any manual update process. In addition to that any
automatic up-date and/or merge operation done by the database software
maintains a single related "changed:" attribute describing the "agent"
performing the modification. From a formal point of view, regular
maintainance and/or merge operations are NOT treated as update operations,
thus e.g. they do not trigger (automatic) notification messages.
Action (NCC): Propose and implement a mechanism to check the current state of
the database with regard to garbage-collection and merging of
guarding values.
Action (NCC): Propose and implement a mechanism to properly keep track of
individual updates of objects and automatic merge/modification
operations.
10. Deletions, Ownership of Objects, Interdependency
This was a more general discussion, focussing on issues of "ownership" of
objects, inter-dependency of various components and quality of the
information in the database.
>From a formal point of view, there was agreement that we should stick with
the concept that the responsibility for maintaining objects remains with the
owner of the object. From an operational point of view it was felt necessary
to perform automatic modifications to certain attributes of an objects. In
the long run this could eventually lead to splitting objects along the lines
of maintainance. This is for further discussion.
Concern was voiced that we do not have the concept of winding down the use of
methods, removing out-dated information and/or deleting objects, closing
guardian's accounts, etc. It was felt that there is a need to analyze,
discuss and document these issues. For the time being these aspects have to
be covered in individual documents describing certain procedures, in the
long run this should be an intrinsic part of the documentation.
The aspect of "sanity checking" the information in the databse was shortly
touched. Given the current shortage of manpower in the NCC and the important
changes to be implemented in the near future this issue was postponed.
Z. AOB
None.
-------------------- end of draft minutes --------------------
1
0
Please find enclosed a DRAFT copy of a document describing the Guarded Field
procedure. This gives details of both the process for updating guardian files
as well as how conflicts are handled.
The current status is that the software is in final beta test and all the
auto-generated "AS" accounts/files have been generated (see doc for more
details).
Our plan is to turn the "guarded field" software on in the database on
February 7th. There will be a short introduction for both the paper and
implementation given in the routing working group session at next weeks
RIPE meeting.
All comments welcome. We plan to agree and close this document at the RIPE
meeting.
See you next week.
--Tony.
Support of Guarded fields within the RIPE Database
* DRAFT *
Tony Bates
Document-ID: ripe-1nn
1. Introduction
The RIPE database contains several significant attributes which make
it well suited for use as part of operational procedures and confi-
guration. Most significantly are the attributes which make up the
RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely
the "aut-sys" and "comm-list" attributes. For these attributes to
be of use to service providers they must be:
o Properly authorised.
o Efficient for both maintainers of the attributes and the main-
tainers of the whole database.
This document describes an overview of the RIPE database attributes
which are guarded, the procedure for updating these guarded attri-
butes and the general use of "guarded" fields within the RIPE data-
base.
2. The Database Guarded Attributes
All the guarded attributes currently supported in the RIPE database
are contained within the "inetnum" or network object. However, the
association corresponds to their relevant guarded database objects.
If we look at a simple example this becomes clear:
inetnum: 192.87.45.0
netname: RIPE-NCC
descr: RIPE Network Coordination Centre
descr: Amsterdam, Netherlands
country: NL
admin-c: Daniel Karrenberg
tech-c: Marten Terpstra
connect: RIPE NSF WCW
aut-sys: AS1104
ripe-1nn.txt January 19, 1994
- 2 -
comm-list: SURFNET
ias-int: 192.87.45.80 AS1104
ias-int: 192.87.45.6 AS2122
ias-int: 192.87.45.254 AS2600
rev-srv: ns.ripe.net
rev-srv: ns.eu.net
notify: ops(a)ripe.net
changed: tony(a)ripe.net 940110
source: RIPE
This shows that the RIPE-NCC network belongs to autonomous system
1104 and is in a community known as SURFNET. This is valuable infor-
mation that could easily be used for example for routing policy pur-
poses (as well as other operational uses). Currently support for the
following set of guarded attributes is implemented:
aut-sys
The "aut-sys" attribute has a direct mapping to "aut-num"
objects as defined in RIPE-81. That is the Autonomous System
(AS) that the network number is a part of. As defined in RIPE-
81, a network can only belong to one AS and hence the "aut-sys"
attribute can only contain one AS number. The syntax of the
"aut-sys" attribute is:
AS<positive integer between 1 and 65535> (1). i.e. AS1104
comm-list
The "comm-list" attribute has a direct mapping to "community"
objects as defined in RIPE-81. A network can belong to more
than one community. The syntax of "comm-list" is:
Multiple text strings which cannot start with "AS" or any of
the <routing policy expression> KEYWORDS defined in RIPE-81.
routpr-l (2)
The "routpr-l" attribute has a direct mapping to "rout-pr"
objects as defined in RIPE-60 [4]. Networks can belong to more
than one routing privilege. The list of networks within a rout-
ing privilege represents the group of networks accepted/allowed
by a set of routers described by the information in the "rout-
pr" object. The syntax for "routpr-l" is as follows:
Multiple text strings representing the routing privilege.
_________________________
(1) This represents a change from RIPE-50 [3] where
the "aut-sys" attribute was defined to be a positive
integer only, not containing the string "AS" at the
start. This change has been made to be consistent with
the "aut-num" object syntax.
ripe-1nn.txt January 19, 1994
- 3 -
bdrygw-l
The "bdrygw-l" attribute has a direct mapping to "bdry-gw"
objects as defined in RIPE-60 [4]. Networks can belong to more
than one boundary gateway. The list of networks within a boun-
dary gateway represents the group of networks advertised by a
set of routers described by the information in the "bdry-gw"
object.
The syntax for "bdrygw-l" is as follows:
Multiple text strings representing the boundary gateways iden-
tification.
As these attributes are tightly coupled to their associated objects
it makes sense for these attributes to be updated not by the network
maintainer but by the maintainer of the referenced object(s). The
basic premise behind this is that these attributes should be used
for various operational procedures such as setting routing policy,
accounting and so on. For these attributes to be used by network
operators for day to day operations they need to be guarded in such
a way that can be trusted and are guaranteed to be unique - with any
conflicts quickly and easily resolved. The procedure for achieving
this is detailed below.
3. The Basic Procedure
For each of the guarded attributes detailed above, a list of all
networks having this attribute is kept separately from the general
database itself. These lists (also called `guarded files') will be
maintained and be served as the `only' source of membership informa-
tion used in the database. Normal database updates `never' change
these attributes. If an update includes such an attribute and a
discrepancy between the values in the update and those in the data-
base is found, a diagnostic message will be sent to the originator
of the update and the guarded value(s) will not be affected. The
attributes as defined in these files are incorporated in the data-
base once a day. To ensure proper control and authorisation, these
lists will be maintained at the RIPE NCC on the same machine that
contains the RIPE database. The "guardians" of the corresponding
database objects will have to maintain their own guarded files. The
guardians are provided with individually assigned login accounts at
the RIPE NCC. The guardians can themselves decide in what manner
they want to update their file. The NCC will offer interactive
logins, ftp logins or any other means that might be deemed useful.
_________________________
(2) It should be noted that both "routpr-l" and
"bdrygw-l" attributes have been agreed to be phased out
in preference of the "aut-sys" and "comm-list" attri-
butes as soon as the `guarded field' mechanism is in
place.
ripe-1nn.txt January 19, 1994
- 4 -
3.1. Some Details
As stated each guardian will be issued with an account on the cen-
tral NCC machine known as `guardian.ripe.net'. This account will
contain a `restricted' environment which will allow the guardian of
the relevant object to update their associated guardian file (3).
Wherever possible the account name issued to the guardian will be
the same as the object name.
For example, the guardian of the AS1104 aut-num object will receive
an account known as "AS1104". With each guardian account the
corresponding file will be parsed at each update run (once a day).
This file will contain the list on networks associated with the
object. See appendix A for details of the format and syntax of the
guardian files.
A tool will also be provided within the restricted environment to
syntax check the guarded file to avoid against possible typos and
errors.
With each account, an electronic mail address (this is a mandatory
attribute for all guarded objects) will be used by the NCC and data-
base software. To make this flexible for the guardian a ".forward"
file with the account which can be change when required. This will
mean mail sent to <guardian-name(a)guardian.ripe.net> will go the to
correct guardian.
3.2. How does it work ?
For each of the guarded files found on `guardian.ripe.net' the data-
base software will load any guarded attribute value(s) for the net-
work object(s) listed in the guarded file. This will take place at
the same time as the database is garbage collected (currently at
0500 MET). If a conflict is found (i.e if more than one entry exists
for an attribute which can only contain one entry, currently only
"aut-sys" contains this property), the current value will remain
unchanged and all guardians involved in the conflict will be sent an
electronic mail message informing them of the conflict. See Appendix
B for an example.
If no conflict is found the attribute will be updated with the
guarded value.
Correspondingly, to remove a guarded attribute just remove the net-
work entry from the relevant guarded file and it will be deleted at
the next update run. To be notified of this delete the "notify"
attribute should be used.
_________________________
(3) As stated, the mechanism for updating the guardi-
an file will initially be by interactive login or file
transfer. However, this doesn't preclude other mechan-
isms in the future.
ripe-1nn.txt January 19, 1994
- 5 -
If a guardian file contains an entry which is not in the database
then the guardian will be notified as part of the conflict handling
procedure.
If an update is sent to the database software using another mechan-
ism (i.e. mail to auto-dbm(a)ripe.net) that contains a guarded attri-
bute, this will not be allowed to change the guarded attribute. If
the value of the attribute is the same as what is currently
registered in the database then no warnings will be given. However,
if the update contains a value for a guarded attribute that is dif-
ferent to that registered in the database, a warning will be sent to
the originator and the guarded value will remain unchanged.
Although the guarded process will run once a day as part of the
database garbage collection procedure it will also be possible to,
"on request to the NCC", run an emergency guarded update process for
a particular guarded object.
4. Getting it started
As this is a new (and much needed, especially for the "aut-sys"
attribute) mechanism, a degree of `bootstrapping' is needed to make
it easier for network providers and IRs to transition to using the
guarded file procedure. The NCC has built an automated generation
scheme for attributes that are known to be in use (currently, this
means AS numbers). For all the AS numbers seen to be routed in
Europe, accounts for the guardians have already been put in place
having the guardian's mailbox point to a mailbox at the RIPE NCC.
For these ASs currently guarded files are generated on a daily basis
by analyzing European full routing tables. This means there could
(and almost certainly will) be some conflicts within the generated
guardian files.
As soon as the account is handed over, the auto-generation for that
guardian account stops and the mailbox is changed to the correct
guardian mailbox. Guardians can of course make use of the auto-
generated guarded files if they wish to check against their own
records. From the moment of `hand-over' it is now the guardians
responsibility to make sure their associated network(s) get the
correct guarded attributes by listing them in the guarded files.
The advantage of having this `bootstrap' method is that it will
allow population of the guarded "aut-sys" attribute to take place
immediately this functionality is enabled in the RIPE database
software. It also acts as an incentive for networks operators and
local IR's to transition to the guarded file procedure as soon as
possible.
5. Conclusion
The update procedure as detailed above has the following advantages:
o Authorisation of adding/deleting is guaranteed.
ripe-1nn.txt January 19, 1994
- 6 -
o No need for mailing back and forth of authorisation messages.
o Simple procedure for both database maintainers and guardians.
o Guardians keep full control of their attribute.
It allows for the addition of any number of guarded attributes in
the future. It describes a simple but effective procedure for main-
taining the guarded files whilst not precluding alternate mechanisms
in the future.
6. References
[1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P.,
Terpstra, M., "Representation of IP Routing Policies in the
RIPE Database", RIPE-81, February 1993.
[2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in
the RIPE Routing Registry", RIPE-103, December 1993.
[3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50,
April 1992.
[4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992.
ripe-1nn.txt January 19, 1994
- 7 -
Appendix A - Format of Guardian Files.
We propose to keep the file format as simple as possible. The name
of the file is identical to the name of guarded object. The format
used within the file is kept simple. It allows lines to be either
comments or the actual object entry that is to be guarded. A comment
must contain either a semi-colon (;) or hash (#) at the beginning of
the comment line. The object name entries must be exactly the same
as they are in the database. Currently, the only object containing
guarded attributes is the "inetnum" object so the file can contain
either the `well-known' dotted quad network notation or RIPE dotted
quad range notation. Here is a simple example of what the AS1104
guarded file would look like. The file would be stored in the home
directory of the AS1104 account on guardian.ripe.net and be called
AS1104 (told you it was simple). It would contain something like the
following:
#
# File : AS1104
#
; An alternate comment format
;
; This file was updated jan.dijkstra(a)gouda.nl
; on 940109
;
192.16.183.0
192.16.185.0 - 192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0
Empty lines in the file are also ignored but you are encouraged to
keep the file as concise as possible.
As stated above, a tool known as `checkguard' will be available to
make it simple to check the syntax of the guarded file.
ripe-1nn.txt January 19, 1994
- 8 -
Appendix B - Example of conflict handling
If a conflict occurs (e.g. by listing the same network number in
more han one AS guarded file), then each of the guardians involved
will be notified on the conflict by electronic mail. Let's look at a
simple example. Suppose the guardians for AS1104 and AS2122 update
their relevant guardian files and create a conflict by having the
same network in them. For this example he network in question is
"192.16.183.0". Here is the AS1104 guardian file:
#
192.16.183.0
192.16.185.0
192.16.186.0
192.16.194.0
192.16.199.0
192.87.45.0
And here is the AS2122 guardian file:
#
192.16.183.0
193.0.0.0 - 193.0.7.0
As you can see "192.16.183.0 exists in both files.
At update time the following mails are generated. Firstly, to the
guardian of AS2122.
Date: Fri, 14 Jan 1994 13:22:43 +0100
Message-Id: <9401141222.AA07125(a)ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net>
Subject: Guarded attributes conflicts found
To: as2122(a)ripe.net
Dear Guardian,
One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.
Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.
Kind Regards,
RIPE Database Conflict Department
------
"192.16.183.0" also appears in guardian files: AS1104
And similarly to the AS1104 guardian.
ripe-1nn.txt January 19, 1994
- 9 -
Date: Fri, 14 Jan 1994 13:22:42 +0100
Message-Id: <9401141222.AA07121(a)ns.ripe.net>
From: RIPE Database Conflict Handler <ripe-dbm(a)ripe.net>
Subject: Guarded attributes conflicts found
To: as1104(a)ripe.net
Dear Guardian,
One or more conflicts have been found regarding guarded
attributes in the RIPE database. Some of the conflicts
concern the guarded values you are a guardian for.
Please verify and correct the conflicts below.
The guarded values for objects below have been set to
the value they had in the database before this guarded
attributes run.
Kind Regards,
RIPE Database Conflict Department
------
"192.16.183.0" also appears in guardian files: AS2122
>From this you can see conflict can be quickly and easily resolved,
assuming good collaboration between the guardians. The existing
database entry will of course not be changed with regard to the
guarded attribute) as long as there exists a conflict.
ripe-1nn.txt January 19, 1994
3
4
Hello all,
you can find below the draft on CIDR FAQ produced by Giuliana Tamorri.
All comments and suggestions welcome.
Daniele
----------------------------------------------------
GARR-NIS
January 1994
FAQ on CIDR
DRAFT DRAFT DRAFT DRAFT
1) What is CIDR?
Classless Inter-Domain Routing (CIDR) is an architecture for allocating
IP addresses in the Internet [1]. It plays an important role in
steering the Internet towards the Address Assignment and Aggregating
Strategy [3].
2) Why do we need to plan an architecture such as CIDR?
The IP address space is a scarce shared resource that must be managed
for the good of the community.
Due to the growth of the Internet, some scaling problems
arosen [2,3,6,11]:
- Exhaustion of the class-B network address space. More than half
of the total class B address space has been handed out. One
fundamental cause of this problem is the lack of an appropriate
sized network number for a mid-sized organization. Class-C,
with a maximum of 254 host addresses, is too small, while
class-B, which allows up to 65534 addresses, is too large to
be densely populated. The result is inefficient utilization
of class-B network numbers.
- Routing information overload. The size and rate of growth of the
routing tables in Internet routers is beyond the ability of
current software (and people) to be effectively managed. This is
mainly a problem for those routers which don't use
a default route, and have to carry a routing entry
for each network they need connectivity to.
The current growth trend is approximatelly exponential.
- Eventual exhaustion of IP network numbers. With more than half
of the class B networks assigned and a little over 6 percent of
the class C networks assigned, and the current growth in the
address allocation rate, this is a real, though not imminent
danger.
The first two problems will become extrimely critical in a near future.
CIDR defines a mechanism to:
i) slow the growth of routing table providing a mechanism
for aggregation of routing information
ii) reduce the need to allocate new IP network numbers managing
the allocation of Internet address space.
[page 1]
The last point takes great advantages from the assigment policy
reported in RFC 1466 [10] in which a managing schema for IP Address
Space is defined.
The rules of the class C network number allocation defined in
[10], will quickly accelerate the explosion of the routing
information carried by Internet routers.
Anyhow, assignment of consecutive class C network number
will facilitate and favourite the aggregation mechanism developed
by CIDR. The rule foresees to delegate to the network service
providers the address allocation of the class C network numbers.
3) Is CIDR a solution to the serious scaling problem of the Internet?
Yes, it is, but not a permanent one. It is a transition phase,
or a short-term solution, in order to allow the development of
a long-term solution, which will also cover the problem of the
exhaustion of IP network numbers.
CIDR will mainly deal with the solution (since the present problem, a
short-term one) of the routing table explosion problem.
4) Which are the aspects analyzed in realising an Address Allocation
schema?
Some of the technical and administrative aspects of an IP address
allocation faced in deploying a CIDR architecture are reported in [1]:
- Benefits of encoding some topological information in IP
addresses to significantly reduce routing protocol overhead;
- The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
- The recommended mapping between Internet topological entities
(i.e., service providers, and service subscribers) and IP
addressing and routing components;
- The recommended division of IP address assignment among service
providers (e.g., backbones, regionals), and service subscribers
(e.g., sites);
- Allocation of the IP addresses by the Internet Registry;
- Choice of the high-order portion of the IP addresses in leaf
routing domains that are connected to more than one service
provider (e.g., backbone or a regional network).
- Identification of specific administrative domains in the
Internet.
[page 2]
5) Which is the Authority to which an organization could ask for a network
number?
The centralised procedures for obtaining IP network numbers from the
Global Internet Registry (known as InterNIC previously the DDN NIC)
is now replaced by a distributed allocation schema [10,12,13].
At the present, there are a number of Distributed Regional Registries
to which Internet Registry (IR) and the Internet Assigned Numbers
Authority (IANA) have delegated the registration function on a
geographic area.
These Regional Registres cover many geographical areas; but until an
organization is identified in those regions, the IR will continue to
serve as the default registry. That is, the IR remains the root
registry and continues to provide the registration function to all
those regions not covered by distributed regional registries.
So, it is possible for network applicants to contact the IR directly,
but it will be referred to the Regional Registry, if any.
Regional Registry in turn delegates blocks of IP network numbers to
local IR's. They are of two types: "service provider" and "registry
of last resort". An IP service provider is an organisation that
supplies Internet connectivity to its customers or users (examples
are academic network providers and commercial network providers).
"Registry of last resort" local IR's are managed by organisations
that are prepared to handle requests from organisations that
have no present or planned connection to the Internet.
The diagram below shows the distributed hierarchy of IR.
Global IR (InterNIC)
|
|
Regional IR (RIPE NCC)
|
________________________|____________________
| | | |
Local IR Local IR Local IR Local IR
/ /
( "REGISTRY" (SERVICE PROVIDERS) (SERVICE PROVIDER)
OF LAST RESORT")
In Europe, the IR has now delegated blocks of IP network numbers
to the RIPE NCC as the registry for the European region, which
following the main criteria, delegates blocks of IP network numbers
to local IR's.
If you are NOT a customer of a service provider, then you should
send your completed application form to the "registry of last resort"
local IR. Currently only one of this type of registry exists in the
european countries.
6) Which are the criteria to submit an appropriate request for a block
of class C network number?
It mainly depends on the organizational network topology, ie number
of internal LANs, and on the needed address numbers, taking in mind
[page 3]
the end system type, ie hosts, routers, printers, terminal server,
etc.
The following schema, which takes in consideration the number of
hosts to be connected per network, could be a starting guide to
evaluate the number of class C networks to be applied for.
1 class C ----> 254 hosts
2 class C ----> 508 hosts
4 class C ----> 1016 hosts
8 class C ----> 2032 hosts
16 class C ----> 4064 hosts
32 class C ----> 8128 hosts
Moreover, if the network is divided into logically distinct LANs
across which it could be difficult to use a smaller number of
class C network numbers, the above criteria may apply on a
per-LAN basis.
It is important to submit the request with an engineering plan
which can motivate it.
If the request will be inappropriate, it will be investigated and
suggested a different solution which could take advantage of the
feasibility of subnetting Class C network numbers which can resolve
the need of a great number of Class C network; in particular, it
can resolve the problem of requesting a network number for
every subnet.
If there is a need for more than 4096 unique IP addresses it
could conceivably receive a Class B network number.
The maximal block of Class C network numbers that should be assigned
to a subscriber consists of 64 contiguous Class C networks. This
would correspond to a single IP prefix of 18 bits.
It is also important that an organization could foresee its growth
in requesting the block of contiguos network numbers. As a
consequence, submitting its forms to its Local Registry, an
organization must indicate which could be its immediate growth
in terms of number of machines to be connected and of subnet
numbers foreseen for its network.
7) When could an organization consider to approach a subnetting criteria?
If an address space needed for an organizatin covers only about
tens addresses, and there are no plans to expand in the future,
it makes little sense to allocate a full class C network number for
this local network [11].
More details on subnetting technique can be found in [14], a
Standard Internet.
However, two issues must be taken into consideration in subnetting
class C networks:
i) subnets and hosts numbered "0" and "-1" are reserved
for special purpose in IP (broadcast and this host/subnet
indication.
[page 4]
ii) which kind of protocol to be used to distribute subnets
information within the network.
Limits imposed by the first point have led to the development of some
technique which can improve the address space utilization.
One of them is "variable-lengh subnet mask" (VLSM).
For the second issue, it is suggested to use a new generation
interior protocol. With old ones, such as RIP, it is quite impossible
to distribute information on subnets. While with the new ones, as
OSPS, integrated IS-IS or RIP-2, announced destinations carry
a corrisponding network mask, favouring the subnetting mechanism.
8) Which would be an appropriate request for a class B network number,
in order to be approved?
An organization applying for a class B network number must present
a subnetting plan which documents more than 32 subnets within its
network and must have more than 4096 hosts.
The submitted document must demonstrate the impossibility of
engineering the network with a block of class C network numbers.
The engineering plan must include both how many hosts and how
many hosts per subnet the network will have within the next
24 months.
9) What does hierarchy mean in Internet addressing? How could hierarchy
help in reducing the growth of routing table?
The situation in which each domain may have non-contiguous network
numbers assigned to it could lead to a dissemination of routing
information in the Internet.
If routing domains are randomly interconnected, it is difficult to
obtain a degree of routing data abstraction. Moreover, at a lower
level, if IP addresses within a routing domain are all drawn from
non-contiguous IP address spaces (allowing no aggregation or
abstraction), then the information exchanged between boundary router
consists of an enumerated list of all the IP addresses.
Anyhow, being service providers and service subscribers (ie sites,
routing domain) arranged hierarchically in the Internet, it is
natural to map this hierarchy also to the IP routing components.
The aim of using a hierarchical routing is to achieve some level
of routing data abstraction: an element lower in the hierarchy
reports summary routing information to its parents. The idea is to
assign to any group of routing domains an address prefix from a
a shorter prefix given to a routing domain which has the function
of interconnecting the group of routing domains.
It is clear that the routing abstraction carries more advantages
at a higher levels of the hierarchy.
10) Does it mean all the routing domains in the Internet need to convert
to CIDR?
No, it is not required all Internet domains to be converted to
use CIDR, neither now nor in the future; anyhow, it is assured
[page 5]
the global connectivity, including for those non-CIDR domains
for which, however, optimality of routes could be impacted.
The only constrain on a non-CIDR-capable domain is the need to
default towards the CIDR-capable parts of the Internet for routes
which have been aggregated to non-network boundaries [2].
Anyhow, it is strongly reccommended that all non-backbone/transit
Internet domains also implement CIDR because it will reduce the
amount of routing information inside them.
Any connected domain that supports IP version 4, could implement
CIDR.
On the contrary, it is imposed ALL Internet domains providing backbone
and/or transit service to fully implement CIDR, ensuring
a slow growth of the routing table, while providing Internet-wide
connectivity.
11) Which are the protocols supporting CIDR architecture?
Two main protocols realising the CIDR architecture are:
i) Border Gateway Protocol 4 (BGP-4)
ii) Inter-Domain Routing Protocol (IDRP for IP)
Each of them are inter-domain routing protocol, but the last one
has been standardized within ISO as multi-protocol.
BGP-4 is an extension of BGP-3 that provides support for routing
information aggregation and reduction based on CIDR architecture.
They are quite interchangeble [6].
12) What is an aggregate? What is an IP-prefix? What an IP-mask?
CIDR removes the concept of class A, B and C networks providing
a new representation of the destination address as a combination
of an address and a mask. The aim is to represent multiple contiguos
class C networks with a single routing table entry [11].
CIDR requires that inter-domain routing protocols be capable
of handling reachability information that is expressed solely in
terms of IP address prefixes [2].
It is possible to support aggregation through the use of an IP
address prefix.
Indipendently of the "class" of IP network number, an aggregate
collects a set of network addresses matching a pattern. In other words,
an aggregate combines announcements for a set of separate networks
into a single net aggregate.
It is now visible how the notion of "class" in routing information
will lose importance.
It is not mandated the use of a particular IP address prefix, and
till now there is no standardized one.
[page 6]
In [1], an IP-prefix is a tuple: <IP-address IP-mask> such that a
bitwise logical AND operation on the IP-address and IP-mask components
of a tuple yields the sequence of leftmost contiguous significant bits
that form the IP address prefix. For example a tuple with the value
<193.1.0.0 255.255.0.0> denotes an IP address prefix with 16 leftmost
contiguous significant bits.
In [7], which describes the NSFNET aggregation schema, an aggregate
is described as: <net-IP prefix-length>.
This refers to the IP prefix "net-IP", with a mask which has
"prefix-length" 1's as counted from the high-order end. For example,
<192.64.128 17> is equivalent to <192.64.128, 255.255.128.0> [7].
They choose to use a prefix-length rather than the mask, considering
it more compact.
13) What is a CIDR Aggregate Registry?
It has become evident the need for sharing of aggregate information;
there is a clear need to have a separate database which will allow
aggregate information from any Autonomous System to be stored and
made available for easy electronic retrieval. This information can be
used for routing coordination and policy configuration in the larger
inter-domain context.
One of the expected uses of such a database is to help determine, as
CIDR matures, the granularity of aggregation of network reachability
information with respect to policy.
In [7], Merit proposes an implementation of an "Aggregate Registry"
to provide sharing of aggregate information for the Internet
inter-domain routing community. It should be a community
registry and MERIT invites all to use and make use of it. It will
consist of a list of aggregate announcement statements.
14) Who does realise aggregation?
Speaking in term of BGP, a border BGP router of an AS will be
responsable for generating the aggregated route for a whole set
of destination IP addresses (NLRI) under its administrative control.
NLRI [6] stays for Network Layer Reachability Information and
represents a set of destination IP addresses over which a border
BGP speaker has an administrative control.
When aggregating NLRI, a border BGP must be cognizant of the implication
on routing policies [6].
[page 7]
References:
[1] Y. Rekhter, T. Li, "An Architecture for IP Address Allocation with
CIDR" RFC 1518, T.J. Watson Research Center, IBM Corp., cisco Systems,
September 1993.
[2] R. Hinden, "Applicability Statement for the Implementation of Classless
Inter-Domain Routing (CIDR)", RFC 1517, Internet Engineering Steering
Group, September 1993.
[3] V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain Routing
(CIDR): an Address Assignment and Aggregation Strategy", RFC 1519,
BARRNet, cisco, Merit, and OARnet, September 1993.
[4] Y. Rekhter, C. Topolcic, "Exchanging Routing Information Across
Provider Boundaries in the CIDR Environment", RFC 1520, T.J. Watson
Research Center, IBM Corp., CNRI, September 1993.
[5] C. Topolcic, "Status of CIDR Deployment in the Internet", RFC 1467,
CNRI, August 1993.
[6] Y. Rekhter, S. Hares, "Application of the Border Gateway Protocol and
IDRP for IP in the Internet", <draft-ietf-bgp-idrp-usage-00.txt>.
[7] M. Knopper, S. J. Richardson, "Aggregation Support in NSFNET
Policy-Based Routing Database", RFC1482, Merit/NSFNET, June 1993.
[8] C. Huitema, "IAB Recommendation for an Intermediate Strategy to
Address the Issue of Scaling", RFC 1481, Internet Architecture Board,
July 1993.
[9] C. Topolcic, "Schedule for IP Address Space Management Guidelines",
RFC 1367, CNRI, October 1992.
[10] E. Gerich, "Guidelines for Management of IP Address Space", RFC 1466,
Merit, May 1993.
[11] H. Eidnes, "Pratical Consideration for Network Addressing using CIDR
Block Allocation", Network Address Assignment, Proc.INET '93.
[12] "European IP network number application form & supporting notes",
ripe-107.
[13] D. Karrenberg, M. Terpstra, "European Internet Registry: IP Address
Space Assignment Procedures", ripe-104.
[14] J. Mogul, J. Postel, "Internet standard subnetting procedure", RFC 950,
Stanford, ISI, Agust 1985.
[page 8]
--
Daniele Vannozzi Phone: +39 50 593280
GARR - Network Information Service Fax: +39 50 904052
Via Santa Maria 36 Telex: 500371 - CNUCE
56126 Pisa - Italy E-mail: vannozzi(a)nis.garr.it
----- -----
1
0
21 Jan '94
Here is the proposal for the CLNS routing domain object for the RIPE
datase as will be presented next tuesday during the DB workgroup meeting.
This version is almost similar as the one presented at a previous
RIPE meeting.
The main differences are a new attribute "dom-name", an introduction
describing shortly why such an object is desired and an appendix that
gives a very short comment on the breakdown of NSAP's for some
commonly used AFI's.
- Henk Steenman
SARA, NIC
- --------------------- CUT HERE ---------------------------------------------
CLNS routing-domain object for the
RIPE database
Version 1.2
Jan 1994
Henk Steenman
Henk_Steenman(a)sara.nl
+31 20 5928038
CLNS routing-domain object Page 2
Introduction.
____________
In the RARE lower layer technology work group for CLNS it was recognised that
in order to coordinate routing between CLNS routing domains a central registry
for such domains was necessary.
At a meeting of the work group at the 27 IETF in Amsterdam it was decided to
write a registry specification. At this meeting the RIPE NCC offered to extend
their database for IP domains/networks with CLNS related objects if a sound
proposal came forward.
Below a description of a database object for CLNS routing domains is defined.
The object can be used to describe some general information of a CLNS routing
domain such as NSAP prefix, name, description and responsible persons. It can
also be used to describe routing policies in a manner comparable to that for
IP domains ( AS's ) as defined in the paper RIPE 81 [1].
The attributes describing routing policy are intended to be set-up such that
routing tables for static inter-domain routing can be derived from them or
excisting routing can be checked against the described policy.
It is desired that tools are made to serve these tasks.
It is understood that the object as described below is subject to change when
CLNS routing developes. An example of this could be the future availability of
IDRP for dynamic inter-domain routing.
In an appendix, some generally used combinations of the Authority and Format
Identifier (AFI) and the Initial Domain Identifier (IDI) are shown.
CLNS routing-domain object Page 3
Object Description
_________________
dom-prefix:
Defines an unique routing domain, characterised by a
NSAP prefix , within a certain prefix hierarchy.
Example:
dom-prefix: 39528f1100
dom-name:
String representing the routing domain.
Format: Text string.
Example:
dom-name: SURFnet-CLNS
descr:
Description of the organisation and place of its location
Format is equal to the descr attribute as defined for IP
autonomous systems in [1].
bis:
Format : < bis NET > < dom-prefix >
NET of boundary intermediate system to between two
domains
Example: SURFnet BIS for EuropaNet
bis: 39528f1100100020000000000100000c0429b400 39528f1103
CLNS routing-domain object Page 4
dom-in:
Description of accepted routing domain prefixes, from
other domain BIS. Analogue to "as-in" in [1].
Format:< dom-prefix > < cost> <routing policy expression >
For every BIS you peer with, there should be such an entry
<dom-prefix> is the routing domain prefix where the BIS
you peer with belongs to.
<cost> is a relative cost to discriminate between different
routes to the same domain. The lowest cost gives the most
preferred route.
<routing policy expression > can be expressed in the
following way's
1: list of "dom-prefixes"
Example:
dom-in: 39528f1103 100 39124F 470005
2: KEYWORD
Only one keyword for the moment
ANY - accept everything you get announced.
3: A logical expression of 1 and/or 2.
The following operators should be defined
AND
OR
NOT
Parenthesis are used to group rules.
Example:
dom-in: 39528f1103 ANY AND NOT 39756f
Accept all announcements from EMPB BIS except for the
Switzerland routing domain.
CLNS routing-domain object Page 5
dom-out:
Routing domain prefixes announced to other BIS'.
Analogue to the "as-out' tag in [1].
Format : < dom-prefix > <routing policy expression >
<dom-prefix> is the routing domain prefix where the BIS
you peer with belongs to.
<routing policy expression > As defined with the dom-in
tag.
Example:
dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910
Advertise to Europanet the SURFnet-CLNS routing
domain but not the PTT-Research routing domain.
default:
Indication how default routing is done
default: < dom-prefix> <cost>
<dom-prefix> again is the prefix of the domain where the
BIS peer is in.
<cost> indicates which default path is preferred. In a
static routing environment this doesn't make sense.
Example:
default: 39528f1103 10
Default everything is routed to 39528f1103
CLNS routing-domain object Page 6
admin-c:
Administrative contact.
Format equal to admin-c in [1].
tech-c:
Technical contact
Format equal to tech-c in [1].
guardian:
e-mail and/or postal address of domain guardian.
Analogue to AS guardian in [1].
source:
Source of the information.
Equal to source field in [1].
remark:
remarks or comments
Equal to remark field in [1]
changed:
Who and when of last change.
Equal to change field in [1].
CLNS routing-domain object Page 7
Example:
_________
dom-prefix: 39528f1100
descr: SURFnet-CLNS domain.
bis: 39528f1100100020000000000100000c0429b400 39528f1103
dom-in: 39528f1103 100 ANY AND NOT 39528f1100000910
dom-in: 39528f1100000910 100 39528f1100000910
dom-out: 39528f1103 39528f1100 AND NOT 39528f1100000910
dom-out: 39528f1100000910 39528f1100
default: 39528f1103 10
admin-c: Victor Reijs
tech-c: Henk Steenman
guardian: domain-guardian(a)surfnet.nl
source: RIPE
changed: henk(a)sara.nl 930716
SURFnet accepts from EMPB ( 39528f1103 ) all prefixes but one,
39528f1100000910, which is PTT-research that is connected to both EMPB
and SURFnet. From PTT-research SURFnet only accepts the PTT-research prefix.
SURFnet announces to EMPB, 39528f1100 but not 39528f1100000910.
To PTT-research only 39528f1100 is announced.
Translated to static routing; on the SURFnet BIS connected to PTT-
research, there is a static route to 39528f1100000910. And on the SURFnet
BIS connected to EMPB there is a static route to all other
know prefixes. On both the PTT-reserach and EMPB BIS's connected
to SURFnet there is a static route to 39528f1100.
CLNS routing-domain object Page 8
Appendix A.
___________
Definition of NSAP structure is defined in OSI 8348 Ad2 [2].
In general:
NSAP's are always an integer number of octets where the AFI is always one
octet and the IDI is always an integer number of octets.
NSAP's are hierarchical structured and once the AFI is decided upon,
structuring of the rest of the NSAP is up to authorities down the tree.
Two common AFI are 47 and 39 and can be described by some general rules.
AFI: 39
Describes that the following two octets are the ISO DCC country codes. Since
these codes are always described by three digits, padding with an "f" is
necessary to complete the 2 octets. Further structure is done by the authority
for each country and there is no general rule.
AFI: 47
IDI: 4 defines OSINET.
Followed by a two byte organisation identifier.
IDI: 5 defines US-GOSIP
Version 1 defines a two byte organisation identifier.
Version 2 defines a one byte data format identifier,
a two byte zero field
a three byte administrative authority
a two byte routing domain id.
^L
^L
CLNS routing-domain object Page 9
References
__________
[1] :
RIPE-81, Representation of IP routing Policies in the RIPE database,
Tony Bates, Jean-Michel Jouanigot, Daniel Karrenberg, Peter Lothberg and
Marten Terpstra, Feb. 1993
[2] :
Network Services Definition, Addendum 2, covering Network Layer Addressing.
1
0
Here is the agenda of the coming Routing-WG.
Blasco, I put you on the agenda just to introduce the subject
(you remember de discussion on the list), but I will present the
issues myself (I'll have some slides about it).
If you want any other item to be discussed, please let me know.
See you all in Amsterdam,
--
Jean-Michel
-------------------------------
RIPE Routing-WG Draft Agenda
Amsterdam, Tuesday January 25th
0. Previous minutes; action list (5 minutes)
Minutes taker
1. Ripe-81
1.1 Introduction; AS registration statistics (NCC)
1.2 Guarded attributes (NCC)
1.2.1 Implementation (discussion, hopefully agreement)
1.2.2 Block splitting (Marten), discussion
1.3 Use of Ripe-81; conversion of Ripe-60 (reminder, brief)
1.4 Ripe-81 enhancements
1.4.1 DMZ (Description of Inter-AS Networks in the RIPE
Routing Registry" (ptraceroute issue). Status (brief)
1.4.2 Colouring, proposal, discussion
1.5 Ripe-81 limitations and pending issues
1.5.1 AS macros (Ripe-81 proposal), examples, discussion
1.5.2 Default route representation (Blasco), what can't we
represent ?
1.5.3 Inter-AS Local Information, discussion
2. Closing, AOB
------------------------------
2
1
Hello all,
having proposed myself as volunteer in documenting the FAQ on CIDR and
subnetting, I have tried to collect a list of documents on which basing
in writing the FAQ.
I would like to have any suggestion from you regarding which documents,
included into the following list or not, would be better to focus the arguments.
Moreover, I would appreciate any hint about which queries are commonly asked.
Many tanks in advance
Giuliana Tamorri
===============================================================================
001: [1000] ripe-m-14 1731
002: [1000] rfc1520 507
003: [1000] draft-ietf-iesg-cidr-01 82
004: [ 870] draft-fuller-cidr-strategy-03 56
005: [ 826] draft-egevang-addrtrans-01 619
006: [ 783] draft-rekhter-cidr-environment-01 58
007: [ 609] draft-ietf-bgp-idrp-usage-00 1294
008: [ 609] draft-ietf-sip-ipae-transition-00 3468
009: [ 609] draft-ietf-sip-overview-00 1237
010: [ 583] ripe-073 1719
011: [ 565] draft-ietf-osinsap-allocation-00 2441
012: [ 542] ripe-m-12 1452
013: [ 542] ripe-m-15 1481
014: [ 542] ripe-048 403
015: [ 539] rfc1482 619
016: [ 522] draft-hares-idrp-05 1191
017: [ 522] draft-ietf-bgp-application-03 1179
018: [ 500] ripe-m-16 1709
019: [ 478] 1id-abstracts 2574
020: [ 478] draft-iab-ipversion7-00 914
021: [ 478] draft-ietf-bgp-bgp4-implement-00 282
022: [ 478] draft-nsfnet-aggregation-00 60
023: [ 458] ripe-104 308
024: [ 435] draft-ietf-ripv2-protocol-analysis-00 222
025: [ 410] rfc1519 1347
026: [ 348] draft-ietf-osids-ipinfo-x500-dir-00.ps /local/spool/ftpp 2467
027: [ 348] draft-ietf-osids-ipinfo-x500-dir-00 1254
028: [ 333] rfc1517 227
029: [ 316] rfc1467 507
030: [ 304] draft-hitchcock-eid-00 292
031: [ 291] ripe-100 1957
032: [ 290] rfc1380 1235
033: [ 273] rfc1518 1515
034: [ 250] ripe-062 1451
035: [ 250] ripe-087 1764
036: [ 217] 1id-index 858
037: [ 217] draft-houldsworth-sc6-documents-00 315
038: [ 217] draft-ietf-bgp-bgp4-06 3191
039: [ 217] draft-ietf-ipidrp-sip-01 1180
040: [ 217] draft-ietf-ospf-mib-01 5428
041: [ 217] draft-rekhter-ipaddress-guide-08 56
042: [ 208] ripe-a-14 141
043: [ 208] ripe-079 1390
044: [ 208] ripe-083 1040
045: [ 208] ripe-085 174
046: [ 208] ripe-088 979
047: [ 208] ripe-090 1578
048: [ 208] ripe-095 979
049: [ 208] ripe-098 979
050: [ 171] rfc1540 1907
051: [ 162] rfc1481 115
054: [ 85] rfc1347 561
055: [ 85] rfc1387 171
056: [ 85] rfc1539 1235
058: [ 59] rfc1454 843
059: [ 51] rfc1383 787
060: [ 42] rfc1335 395
061: [ 42] rfc1371 507
062: [ 42] rfc1466 563
063: [ 42] rfc1475 1963
--
---------- -------------
Giuliana Tamorri E-mail: giuliana(a)jolly.nis.garr.it
GARR-NIS Phone NIS: +39 50 593360
c/o CNUCE - Istituto del CNR Fax: +39 50 904052
via S. Maria, 36 Telex: 500371 - CNUCE
56126 PISA Italy
---------- -------------
1
0