Hi Gilles, I guess we wouldn't be able to check against those accidents at the time of a DB _update_... But checking the RR internal _data_ consistency could maybe become part of the RIS (or similar) project? Henk, any comments? An interesting aside: I guess similar problems could occur with RPSL-based RRs? -WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To: staff@ip.tele.dk, peering@tli.de, ip-oper@tli.de, admin-c@tli.de CC: farrache@cc.in2p3.fr, db-wg@ripe.net, routing-wg@ripe.net Subject: Loop in AS macro Date: Wed, 10 Jan 2001 10:28:15 +0100 From: Gilles Farrache <farrache@cc.in2p3.fr> Dear database managers, I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails) Could you correct those macro and will the Ripe database management provide any control on that kind of loop ? Gilles as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff@ip.tele.dk notify: peering@tli.de mnt-by: AS3292-MNT changed: jesper@skriver.dk 20001103 changed: toba@tdk.dk 20001117 changed: tee@tdk.dk 20001123 changed: jesper@skriver.dk 20001228 changed: jesper@skriver.dk 20010109 source: RIPE as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering@tli.de mnt-by: TALKLINE-MNT changed: thomas@tli.de 19990923 changed: thomas@tli.de 19991020 changed: thomas@tli.de 19991025 changed: thomas@tli.de 20001023 changed: thomas@tli.de 20001025 source: RIPE as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff@ip.tele.dk notify: peering@tli.de mnt-by: AS3292-MNT changed: jesper@skriver.dk 19990922 changed: jesper@skriver.dk 19991019 changed: jesper@skriver.dk 19991025 changed: jesper@skriver.dk 19991210 changed: toba@tdk.dk 20000903 source: RIPE --------------------------------------------------------------------------------
Gilles, Wilfried, and all, This is not a bug, or even an inconsistency. Consider the following as-macro objects: as-macro: AS-X members: AS-Y, AS123 as-macro: AS-Y members: AS-X, AS456, AS789 In this case, AS-X and AS-Y both expand to the same aut-num objects: AS123, AS456, and AS789. However, they may have different maintainers, contacts, descriptions, and so on. In RPSL, many more kinds of loops are possible as well, in as-set, route-set, and filter-set objects. External software that deals with the set objects needs to do loop detection in order to prevent infinite loops. For as-set objects (which are as-macro objects in RIPE-181), this is fairly easy: keep a list or hash of the AS sets expanded, and don't expand them again. For route-set and filter-set objects it is not quite so easy. If you need help with these, you can send me and e-mail and I can explain the techniques that I've used for these objects. Shane Kerr <shane@ripe.net> Database Software Engineer RIPE NCC +31 20 535 4427 p.s. This is actually a feature, not an bug. :) p.p.s. It has been argued (by me) that RPSL allows objects that are logically impossible, but the RFC authors don't seem to think so! On Wed, 10 Jan 2001, Wilfried Woeber, UniVie/ACOnet wrote:
Hi Gilles,
I guess we wouldn't be able to check against those accidents at the time of a DB _update_...
But checking the RR internal _data_ consistency could maybe become part of the RIS (or similar) project?
Henk, any comments?
An interesting aside: I guess similar problems could occur with RPSL-based RRs?
-WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To: staff@ip.tele.dk, peering@tli.de, ip-oper@tli.de, admin-c@tli.de CC: farrache@cc.in2p3.fr, db-wg@ripe.net, routing-wg@ripe.net Subject: Loop in AS macro Date: Wed, 10 Jan 2001 10:28:15 +0100 From: Gilles Farrache <farrache@cc.in2p3.fr>
Dear database managers,
I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails)
Could you correct those macro and will the Ripe database management provide any control on that kind of loop ?
Gilles
as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff@ip.tele.dk notify: peering@tli.de mnt-by: AS3292-MNT changed: jesper@skriver.dk 20001103 changed: toba@tdk.dk 20001117 changed: tee@tdk.dk 20001123 changed: jesper@skriver.dk 20001228 changed: jesper@skriver.dk 20010109 source: RIPE
as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering@tli.de mnt-by: TALKLINE-MNT changed: thomas@tli.de 19990923 changed: thomas@tli.de 19991020 changed: thomas@tli.de 19991025 changed: thomas@tli.de 20001023 changed: thomas@tli.de 20001025 source: RIPE
as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff@ip.tele.dk notify: peering@tli.de mnt-by: AS3292-MNT changed: jesper@skriver.dk 19990922 changed: jesper@skriver.dk 19991019 changed: jesper@skriver.dk 19991025 changed: jesper@skriver.dk 19991210 changed: toba@tdk.dk 20000903 source: RIPE --------------------------------------------------------------------------------
Shane and al, When I was at school (a long time ago) I learn what was called the "set theory" ( "Theorie des ensembles" in French) that was part of what was called the NEW Mathematics. In those courses I learned that : If set A is included in set B and if set B was included in set A then A = B. Whet your telling me is that there are New New mathematics (as there is a new economy) in which : if set A is included in set B and set B included in set A that does not implie A = B. I am very interrested by that theory and will be happy that you give me some pointers to it. :-) Or what is an AS-MACRO ? It is a set of AS (or a set of set of AS ....). So they have to follow the set theory. Gilles
On Wed, Jan 10, 2001 at 12:17:18PM +0100, Gilles Farrache wrote:
Shane and al,
When I was at school (a long time ago) I learn what was called the "set theory" ( "Theorie des ensembles" in French) that was part of what was called the NEW Mathematics. In those courses I learned that :
If set A is included in set B and if set B was included in set A then A = B.
Whet your telling me is that there are New New mathematics (as there is a new economy) in which :
if set A is included in set B and set B included in set A that does not implie A = B.
I am very interrested by that theory and will be happy that you give me some pointers to it. :-)
No, they are equal, but then might not be equal for all future (who knows, I cannot tell the future), so 2 AS's have 2 different AS macro's they ask people to accept, I cannot see the real life problem. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
Gilles Farrache (farrache@cc.in2p3.fr) on January 10:
Shane and al,
When I was at school (a long time ago) I learn what was called the "set theory" ( "Theorie des ensembles" in French) that was part of what was called the NEW Mathematics. In those courses I learned that :
If set A is included in set B and if set B was included in set A then A = B.
Whet your telling me is that there are New New mathematics (as there is a new economy) in which :
if set A is included in set B and set B included in set A that does not implie A = B.
No, that is not what Shane is saying. Indeed, they are equivalent. He is saying it is just a little tricky to figure out the members of A and B.
I am very interrested by that theory and will be happy that you give me some pointers to it. :-)
Or what is an AS-MACRO ? It is a set of AS (or a set of set of AS ....). So they have to follow the set theory.
Gilles
Cengiz -- Cengiz Alaettinoglu Packet Design Inc.
Shane Kerr (shane@ripe.net) on January 10:
Gilles, Wilfried, and all,
This is not a bug, or even an inconsistency. Consider the following as-macro objects:
as-macro: AS-X members: AS-Y, AS123
as-macro: AS-Y members: AS-X, AS456, AS789
In this case, AS-X and AS-Y both expand to the same aut-num objects: AS123, AS456, and AS789. However, they may have different maintainers, contacts, descriptions, and so on. In RPSL, many more kinds of loops are possible as well, in as-set, route-set, and filter-set objects.
RPSL defines semantics when loops exist. However, it does not promote them, or prohibit additional restrictions by the registry operators not to have loops.
External software that deals with the set objects needs to do loop detection in order to prevent infinite loops. For as-set objects (which are as-macro objects in RIPE-181), this is fairly easy: keep a list or hash of the AS sets expanded, and don't expand them again. For route-set and filter-set objects it is not quite so easy. If you need help with these, you can send me and e-mail and I can explain the techniques that I've used for these objects.
Shane Kerr <shane@ripe.net> Database Software Engineer RIPE NCC +31 20 535 4427
p.s. This is actually a feature, not an bug. :)
p.p.s. It has been argued (by me) that RPSL allows objects that are logically impossible, but the RFC authors don't seem to think so!
On Wed, 10 Jan 2001, Wilfried Woeber, UniVie/ACOnet wrote:
Hi Gilles,
I guess we wouldn't be able to check against those accidents at the time of a DB _update_...
But checking the RR internal _data_ consistency could maybe become part of the RIS (or similar) project?
Henk, any comments?
An interesting aside: I guess similar problems could occur with RPSL-based RRs?
-WW _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To: staff@ip.tele.dk, peering@tli.de, ip-oper@tli.de, admin-c@tli.de CC: farrache@cc.in2p3.fr, db-wg@ripe.net, routing-wg@ripe.net Subject: Loop in AS macro Date: Wed, 10 Jan 2001 10:28:15 +0100 From: Gilles Farrache <farrache@cc.in2p3.fr>
Dear database managers,
I notice a loop in the followings AS-MACRO, in fact AS-TELEDANMARKINTERNATIONAL is calling AS-TLI which is calling AS-TELEDK which is calling AS-TELEDANMARKINTERNATIONAL. (and all that make that our automatic filter generation tool fails)
Could you correct those macro and will the Ripe database management provide any control on that kind of loop ?
Gilles
as-macro: AS-TELEDANMARKINTERNATIONAL descr: Tele Danmark customers outside Denmark as-list: AS1902 AS12461 as-list: AS8881 AS-KOMTEL as-list: AS13194 AS-BITE as-list: AS6709 as-list: AS8650 AS-TLI as-list: AS8542 as-list: AS12294 AS-TSUA AS6807 AS8349 AS12788 AS12837 AS12872 AS13249 AS15386 AS15497 AS15929 AS16007 as-list: AS12546 as-list: AS15389 tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff@ip.tele.dk notify: peering@tli.de mnt-by: AS3292-MNT changed: jesper@skriver.dk 20001103 changed: toba@tdk.dk 20001117 changed: tee@tdk.dk 20001123 changed: jesper@skriver.dk 20001228 changed: jesper@skriver.dk 20010109 source: RIPE
as-macro: AS-TLI descr: Talkline GmbH, Internet Division descr: List of ASes according to Talkline Internet (AS8650) descr: and customers as-list: AS5605 as-list: AS6783 as-list: AS8650 as-list: AS8881 as-list: AS12461 as-list: AS12546 as-list: AS-TELEDK as-list: AS-GLOBAL tech-c: TLIP1-RIPE admin-c: TLIP1-RIPE notify: peering@tli.de mnt-by: TALKLINE-MNT changed: thomas@tli.de 19990923 changed: thomas@tli.de 19991020 changed: thomas@tli.de 19991025 changed: thomas@tli.de 20001023 changed: thomas@tli.de 20001025 source: RIPE
as-macro: AS-TELEDK descr: Tele Danmark and Tele Danmark customers as-list: AS-TELEDANMARKDANISH as-list: AS-TELEDANMARKINTERNATIONAL as-list: AS-BELBONEMEMBERS as-list: AS-GLOBAL tech-c: AS5071-RIPE admin-c: AS5071-RIPE notify: staff@ip.tele.dk notify: peering@tli.de mnt-by: AS3292-MNT changed: jesper@skriver.dk 19990922 changed: jesper@skriver.dk 19991019 changed: jesper@skriver.dk 19991025 changed: jesper@skriver.dk 19991210 changed: toba@tdk.dk 20000903 source: RIPE --------------------------------------------------------------------------------
Cengiz -- Cengiz Alaettinoglu Packet Design Inc.
Hi Gilles, We have the same mechanism here in germany, but our script has a simple check mechanism against macro loops. But i think, sometimes a macro loops is not only a bug but also a feature: If you migrate from one to another macro it is usefull to include the old in new and new in old macro, because your remote peer(s) are still using the old macro. cheers frank -- Frank Bohnsack email fb@de.uu.net UUNET, A Worldcom Company phone +49 (0)231 972-1495 EMEA Access & Backbone Networks fax +49 (0)231 972-1188 Team Dortmund web www.de.uu.net
participants (6)
-
Cengiz Alaettinoglu
-
Frank Bohnsack
-
Gilles Farrache
-
Jesper Skriver
-
Shane Kerr
-
Wilfried Woeber, UniVie/ACOnet