January 1996 - routing-wg - mailman.ripe.net

RIPE Action 21.9: Fwd: E-J B: Draft doc m.cast router in routing reg.
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

FYI, this is the original proposal as circulated by Erik-Jan Bos. -Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Subject: Draft document multicast router in routing registry From: Erik-Jan Bos <erik-jan.bos(a)surfnet.nl> Date: Sun, 07 May 1995 11:49:46 +0200 Mbone-EU, please find below a first version of a document describing a multicast router in a routing registry. I would like to have your comments and we can discuss it at the next Mbone WG meeting. I realize some of you might not have a chance to read it before the meeting. Well... here it is, I'll try to bring copies to the meeting. See you in Rome. --- Start of document A Multicast Router in the Routing Registry Erik-Jan Bos Document ID: ripe-nnn May, 1995 **** DRAFT ** WORK IN PROGRESS ** DRAFT **** ABSTRACT This document describes an addition to ripe-122 (Specifying an "Internet Router" in the Routing Registry) in which it is possible to define a multicast capable Internet routing within a routing registry. 1. Introduction With the growing of the Mbone worldwide, managing the Mbone becomes a complex task. The multicast-bone is starting to suffer from problems that used to be present in the unicast-bone several years ago, such as routing coordination. Today, registries are available for administering policies and routes and routers [1]. Tools are availble [2,3] for checking and analyzing the real world against what is registered. The Mbone could and should benefit from these technologies coming from the unicast world. The features of the specification described in this document will be usable e.g. in the RIPE Data Base, after review by the RIPE Data Base WG. After implementation tools could be developed for mapping and analyzing the Mbone. Furthermore, administrative details (such as contact person) are easily administered by well known procedures and easily retrievable. 2. Multicast routers versus unicast routers An "Internet Router" or a "gateway" in the current version of IP (IPv4) can be defined as follows [4]: "Gateways in the Internet form a cooperative, interconnected structure. Datagrams pass from gateway to gateway until they reach a gateway that can deliver the datagram directly." This definition can be applied to both unicast and multicast routers. Since both a unicast and multicast router are fulfilling the "Internet Router" function for different natures of traffic, there is no need for a special routing registry data base object. Moreover, both functions could be present in the same box. 3. Multicast router specification Since an Internet Router can perform both types of routing, this fact should be registerable in the routing registry. Each router is uniquely defined by by its object name, also known as the fully qualified domain name. Below is an example of a internet router object, specifying a multicast router: inet-rtr: broodjeham.surfnet.nl localas: AS1103 ifaddr: 192.87.106.102 255.255.255.0 ifaddr: 192.87.4.99 255.255.255.0 mpeer: 192.87.108.13 16 1 admin-c: Erik-Jan Bos tech-c: Henk Steenman notify: netmaster(a)surfnet.nl remarks: SURFnet Multicast router changed: Erik-Jan.Bos(a)surfnet.nl 950505 source: RIPE Several pieces of important information are present in this object. First of all there is the FQDN of the router, acting as object name. The Home Autonomous System Number is shown, which for a multicast router is merely for identification purposes only. Furthermore, the ifaddr:-lines show that this router has two interfaces, in two different networks. Finally, the DVMRP peers are shown with IP address, treshold and metric. All other attributes are common to other objects already defined for a routing registry [1]. For exact syntax definition see next chapter. 4. Multicast router Syntax Definition The multicast capable router object is defined here. Each of the possible attributes are shown, on a single line. The second column defined whether the attribute must be present [mandatory] of could be present [optional]. The third column defines whether exactly one line is allowed [single] or that more than one line of the same attribute is allowed [multiple]. In case an attribute has more lines than one, the name of the attribute must be repeated on each line. inet-rtr: [mandatory] [single] localas: [mandatory] [single] ifaddr: [mandatory] [multiple] mpeer: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] notify: [optional] [multiple] remarks: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] Each attribute has the following syntax: inet-rtr: The fully qualified domain name of the router. localas: The Autonomous System to which the router belongs. ifaddr: An interface IPv4 address of the router. mpeer: A multicast peering of the router. Format: <mpeer address> <mpeer treshold> <mpeer metric> Example: mpeer: 192.87.108.13 16 1 Status: mandatory, multiple instances allowed. admin-c: Full name or uniquely assigned NIC-handle of a contact person for administrative matters. tech-c: Full name or uniquely assigned NIC-handle of a contact person for technical matters. notify: An e-mail address to which notifications of changes to this object should be send. remarks: Remarks or comments, for clarification purposes only. changed: The e-mail address and date of a change. source: Source of the information. 5. Acknowledgements This specification, being an addition to ripe-122, leans on the specification done by the author of ripe-122. Credits go to Tony Bates. Furthermore, the RIPE Mbone WG has done reviewing of this document and they receive credits as well. 6. Security considerations Security is not considered in this document. 7. References [1] Bates, Tony, "Specifying an Internet Router in the Routing Registry", ripe-122, October 1994. On-line at URL: ftp://ftp.ripe.net/ripe/docs/ripe-122.txt [2] PRIDE Tools Release 1. On-line at URL: ftp://ftp.ripe.net/pride/tools/pride-tools-1.tar.Z [3] Merit Inc. RRDB Tools. On-line at URL: ftp://rrdb.merit.edu/pub/meritrr [4] Douglas Comer, "Internetworking with TCP/IP", Prentice-Hall, 1988. ISBN: 0-13-470188-7. --- End of document __ Erik-Jan. --------------------------------------------------------------------------------

1 0

RIPE Action 21.9: proposal for an ext. of inet-rtr (Mbone R.)
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

There is a fairly old action on Eric-Jan and me to circulate a proposal on extending the definition for the RIPE Database router object inet-rtr: The original definition is documented in ripe-122. The background for the proposed extension is the discussion about documenting the routing of "overlay" networks, most prominently the Mbone. Quite a while ago Erik-Jan Bos circulated a proposal to extend inet-rtr: with an mpeer: attribute. This proposed mpeer: attribute is/was intended to specifically document Mbone DVMRP tunnels. [ I'm going to re-distribute this paper in a separate message for those of you who don't have a copy readily available ] Further discussion revealed that by rearranging and extending the definition of the *existing* peer: attribute there is a possibility to make the concept even more general and potentially covering IP over IP, STUN, whatever. At the same time we could avoid inventing just another attribute. The current use of the attribute is: peer: <Peer address> <Peer AS> <Routing Protocol> [localAS ASnumber] The generalisation would involve changing that definition to peer: <Peer address> <Peer protocol> <peer-proto-specific info> So for the good old BGP peering this might then look like: peer: 192.87.4.6 BGP4 AS2122 localAS AS2121 for an Mbone tunnel this might be peer: 192.87.4.6 DVMRP metric thresh and for an IP-over-IP even peer: 192.87.4.6 IP Unfortunately this approach would require a non-compatible change to the existing peer: attribute. How many tools would be affected? What's the expected effort to fix these tools? Your opinions and input wrt to the concept and the proposal to change the peer: definiton for BGP peerings is appreciated - before we spend too much effort on the details.... Regards Wilfried -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

1 0

Re: Question on % of good routes and plea for an RA mail list was Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x?
by Steven J. Richardson 05 Jan '96

05 Jan '96

>From list-admin(a)merit.edu Thu Jan 4 05:03:27 1996 >Message-Id: <9601040929.AA14593(a)ncc.ripe.net> >To: hwb(a)upeksa.sdsc.edu (Hans-Werner Braun) >Cc: nanog(a)merit.edu, RIPE Routing WG <routing-wg(a)ripe.net> >Subject: Question on % of good routes and plea for an RA mail list was Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x? >In-Reply-To: Your message of Wed, 03 Jan 1996 15:21:50 PST. > <199601032321.PAA24966(a)upeksa.sdsc.edu> >References: <199601032321.PAA24966(a)upeksa.sdsc.edu> >From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> >Date: Thu, 04 Jan 1996 10:29:49 +0100 >Sender: Daniel.Karrenberg(a)ripe.net >The early NSFnet one was done to configure a single backbone. Remember >that EGP was the state-of-the-art. NSFNet provided last resort routing >and everyone was happy. More complex registries were not needed to keep >track of this even when "back doors" appeared. > >In Europe the situation was not like that at all. Despite great efforts >we were never blessed with a single pan-European backbone or even a >last-resort routing service. This is why RIPE developed a routing >registry that was capable of being useful in a general topology of >indepoendent ISPs. FYI: Lest anyone think that the PRDB was single-backbone-specific in _design_ or capability (it pretty much was in terms of data), let me note that, when Andy Adams and I rewrote the PRDB from a SPIRES DB to a RDBMS (with help from Tom Libert and Sue Hares), we explicitly designed in the ability to include data from other backbones. This was initially done to support both the T1 and T3 backbones, but it could easily have supported other backbones as well. >Daniel Steve Richardson/Merit

2 1

Question on % of good routes and plea for an RA mail list was Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x?
by Daniel Karrenberg 04 Jan '96

04 Jan '96

> hwb(a)upeksa.sdsc.edu (Hans-Werner Braun) writes: > It even predates the T1/... NSFNET backbone. We already used something > like that for the 56kbps Fuzzball based NSFNET backbone. In a sense, > the RIPE db etc. are latecomers here. Susan is correct, the NSFNET > implemented and formalized the routing data base in evolutionary > stages. Indeed there is an evoloution of routing policy databases/registries. The early NSFnet one was done to configure a single backbone. Remember that EGP was the state-of-the-art. NSFNet provided last resort routing and everyone was happy. More complex registries were not needed to keep track of this even when "back doors" appeared. In Europe the situation was not like that at all. Despite great efforts we were never blessed with a single pan-European backbone or even a last-resort routing service. This is why RIPE developed a routing registry that was capable of being useful in a general topology of indepoendent ISPs. We weren't more clever or had more foresight, we simply had the need earlier. I think it has been a good decision by the RA team to use this technology and to contribute to its development rather than inventing something new right away. Given the resources I would hope for more output in the way of tools etc. but I see it coming now. > Often despite complaints from many sites that wanted free and > uncontrolled flow of routing information. This is a great misconception about routing registries which comes from the time of the single backbone model. The routing registry and the backbone were then operated by the same people and used to enforce The Routing Policy. The situation is different now. Each ISP sets and enforces their routing policy. The routing registry only supports them in this. Of course a good routing policy is to not propagate routes to address space which is not assigned and to generally filter announcements from customers. But there is no way to use the routing registry to force ISPs to do reasonable things. > I am not arguing about whether the RIPE and the RA DB should or should > not be merged, just that there is a history to the steps taken, and > reconciling into a homogenious DB (format) would have to be a concious > effort by the parties seeing mutual benefit. Not that it should not > happen otherwise, it just won't, given project priorities. I am pessimistic at all. All routing registies use the same schema or very very similar ones. They currently call come from the ripe-181 specifications which are based on input from the RA people. The RADB, RIPE RR, MCI RR and all the others really form a global Internet RR which is quite useful already and can be made more useful. Two things are needed now: 1) Improve active maintenance by the registrars. This will by itself lead to better alignment between registries and remove duplicate registrations. 2) Produce and *deploy* more useful tools. If this is done well, ISPs will use those registries more and register in them because it is useful and interest. Daniel

1 0