Dear all,
The following describes a mechanism for "Cross Notification in the
Routing Registry" to be implemented shortly at the RIPE NCC. The
mechanism has been modified to incorporate the feedback received
during RIPE 27. Appended is a short history explaining how the
proposal reached its current form.
If this mechanism is of interest to you, please review the document
and send any comments or questions you may have to myself. Unless we
hear show stoppers, we will start the implementation in the week of
July 21, 1997.
Greetings,
Carol Orange,
RIPE NCC
--------------------------------------------------------------------
Cross Notification in the Routing Registry
Carol Orange, July 1997
Suppose you register the announcement of a route covering some /24.
When you make the announcement, it may be useful to know that the
/24 has already been registered as being announced in another AS.
Alternatively, if a user of a /24 which is announced by you decides
to become multi-homed, it may be of interest to you. Overlapping
routes are often unintentionally announced in a single AS, and a
mechanism for detecting such errors would certainly be handy.
In the following, we propose a simple cross notification mechanism
which will allow routing registry users to be notified of overlapping
route announcements in the Routing Registry (RR).
Consider the route object:
route: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
origin: [mandatory] [single] [primary key]
hole: [optional] [multiple] [ ]
withdrawn: [optional] [single] [ ]
comm-list: [optional] [multiple] [ ]
advisory: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]
To address the considerations above, we propose the following
notification mechanism be implemented in the Routing Registry:
1. Whenever a route object is added to the routing registry, a check
is done to see if the address space overlaps with that in any other
route object in the RR. If so, a notification will be sent to the
submitter of the route object.
This will always happen and is not dependent on any notification
attributes described below.
2. A new field called "cross-nfy:" will be added to the route and
aut-num objects. This field:
a) contains a contact reference, specified as either
+ a NIC-handle pointing to a person or role object,
the email address of which will get the notification; or
+ a mntner ID referencing the maintainer to be notified;
b) is optional; and
c) is multiple (so that more than one contact can be notified).
This attribute is used to request notifications of the addition or
removal of route objects which overlap the address space of the
already registered route objects in which this attribute is specified.
If the "cross-nfy:" attribute is used in:
+ a route object, then a notification will be sent for any
overlaps with the address space specified in the route object;
+ an aut-num object, then a notification will be sent for
overlaps with the address space specified in each route object
in which the given AS number is specified in the "origin:" attribute.
The contact in "cross-nfy:" will receive an e-mail whenever:
+ a route is registered which overlaps this address space; or
+ a route is removed which overlapped this address space.
If all is well, the former will indicate the introduction of
multi-homing, and the latter will indicate the cancellation of the
multi-homing. It is expected, however, that the former will often
indicate an error, and the latter its removal. Either way, it will be
useful to know about the registration and elimination of overlapping
announcements.
Some Important Notes
--------------------
1. At the time of implementation, the notification may take up to 24
hours, due to the current mirroring scheme employed in the RR. This
time will be reduced when the mirroring scheme is improved.
2. Exact address space matches will be distinguished from non-exact
overlaps in the notification messages.
3. After the implementation of RPSL, it will be useful to allow
one or more route-sets to be specified in the "cross-nfy:" attribute
in addition to the contact reference. For example, using:
cross-nfy: <ContactA> <route-set1> <route-set3>
cross-nfy: <ContactB> <route-set2>
in an aut-num object would allow ContactA to be notified upon
registration and deletion of routes overlapping the address space
covered in <route-set1> and <route-set3> and ContactB to be notified
with regards to route registrations with address space overlapping
that covered in <route-set2>. In this way, a more selective notification
scheme can be specified without adding "cross-nfy:" to every route object.
Acknowledgements
----------------
Thanks to the RIPE Routing and Database working groups for lively
discussions resulting in constructive input on this notification
mechanism. Daniel Karrenberg was the first to mention the need
for a notification mechanism in the RR. Chris Fletcher, Joachim
Schmitz and Wilfried Woeber have all made essential contributions.
------------- ------------- ------------- ------------ -------------
Appendix - Some History
At the January meeting of the Routing WG in Amsterdam, various
possible hierarchies for authorization in the Routing Registry (RR)
were considered. During the discussion, a suggestion was made that
"hierarchical notification" would be useful even in cases where
authority is not well defined. This suggestion enjoyed strong support
of both the Routing WG and the Database WG.
At the start of May 1997, a proposal was submitted to the mailing
lists of the RIPE Routing and Database WG's describing a notification
mechanism designed to meet the stated requirements. During the RIPE
meeting in Dublin, it was agreed to that the notification mechanism
should be implemented, with the following modifications:
1. Whenever a route object is submitted in the RR, a notification
should be generated to the submitter if the address space overlaps
with any other route object in the RR. [RIPE27 - Routing WG meeting]
2. The attribute should be named "cross-nfy:" rather than "x-notify:"
to avoid any misunderstandings with respect to other conventions. In
particular, mailers often interpret "X-field:" to mean "ignore this
field". [private discussion Chris Fletcher]
3. If the address space covered in the route object matched the
address space in another route object, be sure this is clear in the
notification message. [RIPE27 - Routing WG meeting]
4. - Notifications should be sent to the appropriate contact not only
if an overlap is introduce, but also when an overlap is eliminated.
[RIPE27 - Routing WG meeting]
5. The "cross-nfy:" field should be available for the "aut-num:" object
as well as for the routing object. If "cross-nfy:" is in the
"aut-num:" object, it applies to all routes with that aut-num as
origin. [RIPE27 - Database WG meeting]
It has since been suggested that it would be useful if the mechanism
would be extensible for the "route-set:" objects defined in RPSL
(see draft-ietf-rps-rpsl-02). To make use of the route grouping
functionality supplied by the "route-set:" object, we suggest the
following extension be considered:
6. In the "aut-num:" object, allow "cross-nfy:" to be a multiple
attribute, and in addition to specifying who should be notified,
specify for which route-sets. If no route-sets are specified, then
the notification will take place for all route objects with the given
"aut-num:" as origin. [private discussion Joachim Schmitz]
