- routing-wg - mailman.ripe.net

2nd draft agenda routing wg session
by SchmitzJo＠aol.com 22 Sep '97

22 Sep '97

Dear colleagues, there is a new topic on the agenda and I did not want to keep it from you ;-) Regards Joachim R I P E 2 8 A M S T E R D A M Routing Working Group Session 24-Sep-97 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 27 minutes - actions from earlier meetings B. Current Developments (Joachim Schmitz) - ietf - rpsl - rpsl transition session C. Report from the RIPE NCC (Daniel Karrenberg) D. Authorisation/Notification with Route Objects - implementations in database software (Carol Orange) - hierarchical authorisation of route objects revisited (Joachim Schmitz) - discussion E. Route Flap Dampening Parameters (Christian Panigl) - report from the task force - the route flap dampening paper F. PAIR - Overview and Introduction (Jake Khuon) Y. General Input from Other WGs Z. AOB

1 0

RIPE 28 draft agenda of routing wg session
by SchmitzJo＠aol.com 17 Sep '97

17 Sep '97

Dear colleagues, please find enclosed the draft agenda of the routing wg session for the RIPE28 meeting in Amsterdam next week. Additions, suggestions, comments welcome. Regards Joachim R I P E 2 8 A M S T E R D A M Routing Working Group Session 24-Sep-97 Draft Agenda A. Preliminaries (Joachim Schmitz) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 27 minutes - actions from earlier meetings B. Current Developments (Joachim Schmitz) - ietf - rpsl - rpsl transition session C. Report from the RIPE NCC (Daniel Karrenberg) D. Authorisation/Notification with Route Objects - implementations in database software (Carol Orange) - hierarchical authorisation of route objects revisited (Joachim Schmitz) - discussion E. Route Flap Dampening Parameters (Christian Panigl) - report from the task force - the route flap dampening paper Y. General Input from Other WGs Z. AOB

1 0

None
by Patrik Backstrom 03 Sep '97

03 Sep '97

1 0

new draft minutes from last routing wg session
by SchmitzJo＠aol.com 26 Aug '97

26 Aug '97

Dear all, taking the comments from Carol into account a second draft of the minutes from the last routing wg session is available from http://www.ripe.net/wg/routing/r27-routing.html Changes are marked by a vertical line to the left of the text. Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

help
by Ola.A.Johansson＠telia.se 30 Jul '97

30 Jul '97

help who routing-wg /inet(routing-wg(a)ripe.net) Ola Johansson <ola(a)internet.telia.com> Ola Johansson <ola.a.johansson(a)telia.se>

1 0

http://www.isi.edu/ra/rps/transition/
by Cengiz Alaettinoglu 29 Jul '97

29 Jul '97

Hi, Please visit http://www.isi.edu/ra/rps/transition/. This page contains RIPE 181 to RPSL transition strategy and related tools. You can o check out our transition plan as agreed by the registries at the end of last ietf meeting (please disregard the dates, as we are behind) o down load ripe181 to rpsl policy converter or a RIPE database server that can handle rpsl objects o query a mirrored IRR for alredy registered 120,000 objects o query a mirrored IRR in RPSL format, yes we have converted all 120,000 - 15 objects to RPSL. What is up with these 15 objects, ask me! o use a web page based interface to convert RIPE181 policy objects to RPSL using cut and paste, or type in your RPSL object to validate its syntax. Note that syntax checker is still partial, but it can handle the most common cases. Please provide us feedback. The success of RIPE181 to RPSL transition depend on early detection of errors. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/~cengiz

1 0

Power Tool For Webmasters
by powertools＠cybertools.net 29 Jul '97

29 Jul '97

With over 30 million documents on the Web today, and thousands more being added almost hourly, it is now harder than ever for potential customers to find your place on the Net. Which is why we've developed the Web Promotion Spider for Windows 95 / NT . This amazing new software automatically submits your site to over 250 (the list grows daily) major search engines, directories, and Usenet newsgroups! Not only that, The Web Promotion Spider has the ability to dynamically optimize your website, ensuring maximum visibility on the Internet - at the same time recording all registration data in a built in database. Originally engineered for use by the professional advertising industry, this program is easy and intuitive to use. Beginners will be amazed at how simple it is to take complete control over their search engine and index marketing efforts. But don't be fooled by its simplicity! The Web Promotion Spider is an industrial strength marketing tool and an extremely valuable part of any on-line publicity campaign. With this kind of power, it should come as no surprise that many of our customers have built profitable on-line promotional businesses with this product and their existing Internet connection! But don't just take our word for it. The Web Promotion Spider is available now for FREE immediate download on a limited trial basis (shareware). Visit http://www.cybertools.net/spider /////////////////////////////////////////////////////////////////////////////// If you wish to be removed from future mailings, please reply with the subject "Remove" and this software will automatically block you from future mailings. ////////////////////////////////////////////////////////////////////////////////

1 0

Re: Routing WG Minutes - RIPE 27, Dublin
by SchmitzJo＠aol.com 14 Jul '97

14 Jul '97

Dear Carol, you wrote: > >> RIPE 27 : Routing WG Draft Minutes > >> Chair : Joachim Schmitz (JS395-RIPE) > >> Scribe : Anne Lord (AL12-RIPE) > >> Attenders : 57 > >> [...] > >> 2. Hierarchical Authorisation / Cross Notification of Route Objects > >> in the IRR (Carol Orange) > >> > >> 2.1 Cross Notification [...] > >> After a fairly lengthy and interesting discussion, it was agreed to go > >> ahead with implementing the draft proposal given the following > >> modifications which were agreed: > >> > >> - the submitter of the route will always be notified as to whether the > >> object submitted was successful. Notification of overlaps can be built > >> into the acceptance/feedback message returned to the submitter. > >> > >> - for deleting a conflicting object, it was agreed to notify the > >> submitter of the conflicting object that there was no longer a > >> conflict in the database > >> > >> - notifications on overlap - either for newly submitted route objects, > >> or for deletions - will only be done for *existing* route objects if > >> explicitly requested by the "x-notify" attribute > > I've reworded the above adjustments as I understood them, and have > incorporated them in the newest version (to be submitted on the list). > You can keep whichever version you find clearer. They say the same > thing. > > - 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. This is regardless of whether > the new attribute for cross notification is used. I agree with this one. However, I suggest to keep the note that the notifi- cation to the submitter is included in the acceptance/feedback message on the submission mail - this keeps mail traffic low. > > - 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. Agreed. > > - Notifications should be sent to the appropriate contact not only if > an overlap is introduced, but also when an overlap is eliminated. Again agreed. However, in your proposal I am missing a bit the distinction between the two parties involved: (a) the submitter, and (b) the owner of a route object which already exists in the RR and the new submission is in conflict with it. I try to think a bit more about the text and probably rewrite it taking your suggestions into account. [...] > >> > >> 2.2 Hierarchical authorisation in the RR (Carole Orange) > >> (or "aut-num authorisation for route objects in the RR") > >> > >> The proposal is documented in a draft document which was previously > >> circulated to the Database WG and Routing WG mailing lists. Agreement > >> on this proposal is now sought so that it can be implemented. > >> > >> The goal of the proposal is to allow network operators who announce a > >> route in their AS to delegate this authority to others. > > No, the goal is to allow network operators who maintain an aut-num > object to determine who can submit a route object with their AS number > as origin. Yes. We must change this in the minutes. > > >> There has been > >> much discussion on the mailing lists and a specific "non-goal" of the > >> proposal is to produce an optimal hierarchical authorisation scheme > >> for the RR. This proposal is not CIDR based; hence the change of name > >> for the draft to avoid any confusion about CIDR based hierarchy in the > >> proposal to "Aut-num authorisation for route objects in the RR". > >> > >> The proposal works briefly by the following mechanism: > >> > >> A "mnt-route" attribute (in former drafts called "mnt-lower") is added > >> to the aut-num object. Currently the "mntner" object referenced > >> determines who can add/update/delete an object associated with that > >> aut-num (for more details see the draft which can be found at the > >> reference above in the archives of the mailing list, or look at the > >> Working Documents section of the Routing WG at the RIPE web server). > > No, this is not the case. There are currently no restrictions on who > can add/update/delete a route object specifying a given aut-num in the > origin. The proposal is intended address this authorization gap, by > allowing network operators to specify these restrictions, and as you > state above, by also allowing them to delegate this authority if they > so desire. You are again right. Sorry, this slipped. [...] > >> > >> 5. Route Flap Dampening Parameters (Christian Panigl) [...] > What I miss in this summary is that there seemed to be consensus at > the meeting that "it is beneficial if everyone adopts the same > parameters, because it allows problems to be detected and addressed on > the home front." (but perhaps that was obvious, and I'm being picky.) No, you are not picky. I consider this an important point and will add it to the minutes. Thank you very much for your comments! Regards Joachim

1 0

Cross Notification in the Routing Registry
by Carol Orange 11 Jul '97

11 Jul '97

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]

1 0

unsubscribe
by Marko Miinalainen 10 Jul '97

10 Jul '97

unsubscribe

1 0