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@ripe.net' automatic update procedure. These objects have to be sent to 'ripe-dbm@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. ----------------------------