RIPE 67

Routing Working Group - RIPE 67
Thursday, 17 October 2013, 14:00-15:30
Working Group co-Chairs: João Damas, Rob Evans
Scribe: Robert Kisteleki

A. Administrative Matters

João Damas, Working Group co-Chair, opened the meeting, thanking the stenographer, scribes and chat monitors. He invited comments about the Routing Working Group minutes from RIPE 67 – there were none, and the minutes were marked as final.

João also added that there had been some discussion about the irrtoolset that hadn't been continued far beyond the first posting and follow-up. João stated that if there is a demand for further discussion, then to come to him directly.

B. Charter Discussion

João opened, stating that he had not followed this up and that he and Rob Evans, Routing Working Group co-Chair, had decided that they would welcome input during the coming months with a goal of publishing the draft re-charter of the Working Group around January 2014, to be discussed at the following meeting.

C. Reinventing the Access Network - Anastasios Chatzithomaoglou, Forthnet

The presentation is available at:
https://ripe67.ripe.net/presentations/273-Anastasios_Chatzithomaoglou_-_Reinventing_the_Access_Network_-_17.10.2013.pdf

Mikael Abrahamsson, T-Systems, asked as to the reason for keeping the BRAS there. Anastasios responded that this was because they needed PPPoE. Mikael added that, had it been changed, Anastasios would have dramatically cut down the need for layer-two forwarding and simplified the network and Anastasios agreed. The speaker then asked if Forthnet are doing access resale via PPPoE and Anastasios said it was simply being continued because of the past.

Aleksandr Saroyan, Ucom, asked if they had considered placing their BRAS closer to the access layer. Anastasios replied that they taken a look at that, and also had received proposals from the incumbent to place their BRAS closer to the access layer, but the problem is that the closer you have to move, the more devices you need. Aleksandr agreed but commented that Anastasios has a smaller layer 2 domain, which is great in that it is flexible. Anastasios commented that it's still large enough but that he didn't have the numbers from the other side. The number of actual devices, the number of aggregation, the number of BRAS would give a better idea how large the network is. He added that it's not so scaleable, at least at the moment. If they move them closer to the edge, they would need to almost double them. Aleksandr asked if business customers' traffic goes through BRAS. Anastasios replied that it was the same, but without BRAS and with an access router terminating the IP traffic. He added that there is no difference - the edge network is a network that consists of BRAS for PPP customers, BNG for IP customers, and some access routers and multi-service routers for business customers.

Peter Lothberg, Stupi, asked whether Anastasios had a drawing showing that the organisation runs the network, asking if it's one router per manager or is it one router per person. Anastasios responded that a single organisation manages everything.

D. Evolving Peering with a New Router Architecture - Jean-David Lehmann, Compass EOS

The presentation is available at:
https://ripe67.ripe.net/presentations/340-RIPE67_-_Compass-EOS_-_New_Router_Architecture_-_17_Oct_2013.pdf

There were no questions for Jean-David.

E. RPKI on Minority Address Space - Alex Band, RIPE NCC

The presentation is available at:
https://ripe67.ripe.net/presentations/330-RPKI_RIPE67_Minority.pdf

Andy Newton, ARIN, asked for confirmation that these are self-signed certificates and if these are new trust anchors or if they are signed by the current trust anchor. Alex Band responded that they are signed by the RIPE NCC's own trust anchor and that they will be in a position to cross-sign this. He added that this can be signed by the ARIN certificate, if all RIRs are in a position to cross-sign. Alex noted that there need to be talks about this, especially in the IETF sphere, on what the requirements are in order to do this and to put the RIPE NCC in the best position when moving forward. He pointed out that, right now, for the user side, the attestations made by the RIPE NCC about the minority space and all of the prefixes that were placed on the "ARIN minority certificates" is essentially an attestation made by the RIPE NCC and not signed by ARIN. However, the framework allows you to have it signed by ARIN eventually. Andy asked if the intent is to reuse the keys in these certs to have them signed by an ARIN certificate and Alex confirmed that this was the intention.

Peter Thimmesch, Addrex, asked if the RIPE NCC were also doing the certificate signing for 141/8, where the RIPE NCC is the maintainer and some of the blocks are ARIN and APNIC. Alex responded yes, and that the implementation made, in order to allow cross signing, is something that all RIRs are doing. This allows the RIPE NCC to cross sign, so that the they can also attest to the minority space that, for example, APNIC or LACNIC has out of /8 blocks that RIPE NCC manages. Peter Thimmesch also asked if the RIPE NCC was going to publish the manner of verification between themselves and the cross signing, asking what method is used for verification. Alex responded that the method for verifying is essentially comparing registry data, a process that the RIPE NCC has established over the last years. He added that, currently, the RIPE NCC is in a position where they are 100% confident that, for all of the minority space, if you compare the different registries, there are no conflicts no overlaps. All of the RIRs are currently unofficially agreed on who manages which minority space. He added, however, that it is really an attestation that the RIRs can only make between themselves and there is no over-arching entity that can provide that kind of solid proof.

Ruediger Volk, Deutsche Telecom, asked how well the division of the address space is assigned between the involved RIRs, and if there is actually a published list of that division? Geoff Huston, APNIC, responded that there is a delegated extended statistics file on the NRO website which lists every single number (IP or AS). It also lists the responsible RIR and the status. He added that, if you tie it with a similar file - a republication of IANA - that shows where they gave the resource to, and the two combined provide all of the minority reports. Ruediger continued, that the question is then how well-aligned is the certificate with that data. Alex responded that it's 100% accurate.

Kaveh Ranjbar, RIPE NCC, pointed out that the RIPE Database imports all of these files every eight hours and if there is any conflict there is a notification. Over the past three months there have been no conflicts so the whole space is covered and there's been no conflict between RIRs.

Jared Mauch. NTT Communications, asked if the RIPE NCC is looking at creating a tool to take a ROA request and check it against the IRR data at the same time while suggesting that they clean up their bad objects. Alex responded that it is something they would like to implement within the RPKI validator, as the IRR data set is also really useful. He stated that you can have an attestation in terms of a ROA and if that is also backed by, for example, a route object that comes out of the IRR, that would be an additional positive statement about the intended BGP and something that can be included in the RPKI validator. However, he stated that whether it is actually implemented in the tool is something that depends on community demand. Jared was pleased by this response, and added that he thinks it is something that would be valuable to clean up the RIR data, to which Alex responded that, in terms of sort of ROA management, the RIR data set and the RPKI data set are two things that currently need to be managed completely separately. He added that he would like to provide a single user interface to cover both ROAs and route objects, giving an example of the current situation where the route object matches the ROA automatically. He added that the RIPE NCC is really focused on making sure that all outer space is eligible for certification. Alex emphasised that all of the current work is really focused on finishing the infrastructure and making sure that you have a complete data set in any resource that can be signed and covered by a ROA.

Richard Barnes, BBN, asked how the certificates for minority allocations are arranged and, if he wanted to validate these certificates as part of my verification system, would he need to install each of these as a trust anchor. Tim Bruijnzeels, RIPE NCC, responded that they are not self-signed. The RIPE NCC has one self-signed trust anchor that includes the majority /8s that the RIPE NCC manages, in addition to all the other space from other RIRs. The RIPE NCC uses that to sign the majority certificate for themselves and the other ones for the other RIRs, so there is just one trust anchor involved. Richard asked if they are extending the top-level RIPE NCC certificate to include the minority allocations and Tim confirmed.

Andy Newton then asked that, when the RIPE NCC has the other RIRs and when the RIPE NCC re-uses the keys to other RIRs to sign the certificates, will the RIPE NCC revoke the current ones that were just signed. Alex responded that he didn't know yet, and it is part of the discussion that needs to happen at the ECG level in the IETF. Once the RIPE NCC knows the outcome of that, they will build an implementation.

Geoff Huston asked, if he were a holder of ERX space in RIPE with a /8 belonging to ARIN, he would logically expect the validation path to come through ARIN to RIPE to him for that space, which is different from space that he had from RIPE so it's two certificates. He noted that in the current RIPE NCC scheme, he would only have one certificate because the RIPE NCC has a single trust anchor with
everything, and asked for confirmation. Alex confirmed that yes, Geoff would only have the one certificate, adding that Geoff wouldn't want to end up in a situation where he would have two signatures over a single certificate even if that were technically possible. Geoff replied that it is possible, but a different matter.

F: aut-num object (The “Via” Attribute in the RIPE Database and a Suggestion on Changing How Peering Relationships are Shown in RPSL) - Johan Åhlén and Denis Walker, RIPE NCC

The presentation is available at:
https://ripe67.ripe.net/presentations/334-Routing_Presentation_rev_1.pdf

During the first half of Denis's presentation there was a break for questions:

Ruediger Volk asked if it makes sense to actually try to invoke and actively ask developers of RPSL software and the standard body that has devised it. Denis then asked the participants if there is general support for having these new attributes at all. João Damas noted no overwhelming response from the participants. Andreas Polyrakis, GRNET, commented that he thinks that the RPSL is very inefficient in describing complex routing policies. His perspective is that it should be totally replaced with something more efficient. He stated that, in the RIPE Database, users are obliged to have a routing policy there and cannot have an aut-num object without a single import and a single export. He added that maybe we should just leave people who are interested in describing their exact policy there and leave also people who do not want to put anything there; let's not oblige them to put a comment for the sake of it. Denis corrected Andreas, adding that you choose an aut-num object with input and export and adding that they are optional attributes. He added that if you have an AS number in a database, that acknowledges the fact that this income has been registered to you and put no policy whatsoever. He noted that this, syntactically, is correct and that it has been this way for 12 years. João Damas noted that the attempt to replace RPSL is one possibility.

Kurtis Lindqvist, Netnod, commented that the standard is set, and should be accepted and announced as transparent. Denis responded that the RIPE NCC don't often make any change to these objects and therefore want to ensure that the community are happy with the changes. João agreed with Kurtis, that the standard itself is quite clear.

Benno Overeinder, NLnet Labs, commended Andreas's comments and added that he has been speaking with people about what can be used from RPSL and what kind of tool can be created with it, in order to improve the policy and usability. He invited participants to put forward their ideas.

Alexander Azimov, HLL, asked if Denis believed that getting these attributes would increase the quality of the data. He commented that there are a number of old attributes in the RIPE Database already and that the quality is poor. Denis responded that he thinks these are two separate questions - the question of whether the attributes have a value is not the same as a question about the accuracy of the values. Ruediger Volk added that he is quite sure that the objects put in there with the extended syntax would be better than the more “average” stuff. He noted that people are requesting this because they intend to use it, and using it with poor quality information would obviously not work so well. Whether this is a valid extension and whether it brings any kind of problem with it are two different things. He summarised that he does not see a problem currently, but would like to hear from the people who are looking deeper into this. João Damas stated that the only thing you can trust on an aut-num is whatever the AS number is in the object when it's first created by RIPE NCC.

Denis continued his presentation. More questions followed at the end:

João commented that he thinks the pending routing authorisation is a brilliant, simple idea. He asked for an example as to the second idea presented:

Denis stated that, if you took a peering agreement, which is like import, export, default, between, say, AS 10 and AS 15, if that was in a separate object which was called AS 10 - AS 15 and you put your policy in there and the other guy created an object AS 15-AS 10, and he put his side of the policy there, and you did that for all of your peering agreements, then you can manage it, He clarified that you can have a new peering agreement, you create one little object. Denis continued that if you change a peering agreement you change one little object. When you actually want the information back, it can be presented as the full aut-num object as it is now with your full documented policy information. João added that it's like a little subheading that only pertains to that relationship.

Kaveh Ranjbar added that, in the RIPE database, there are 21 object types. Seven of them are from the registry side of the database which is maintained properly. 15 of them are from the routing side, or the IRR side. An aut-num is the one which is actually in-between, and that's the only one. He continued to add that one of the other reasons behind this separation is because people familiar with routing know how to use an IRR and they have tools, but for the registry side it adds a lot of information which many the users are not interested in. Ruediger asked if Kaveh was suggesting to go the ARIN way. Kaveh responded no, and that he thinks there are benefits to having the two together - there is a link between the authorisation. He noted that, as Denis suggested, maybe the RIPE NCC can provide an object called "AS number" as an example, which only shows the registration data. The RIPE NCC could have the peering set and can keep the aut-num as a legacy object which is internally stored when the software automatically puts together the current object.

Ruediger was pleased with this “inventive” possible solution, asking Denis if he'd checked that there is no expression for defining separate peerings in RPSL at the moment, admitting that he hasn't checked, but believes there is there is little use for an object type for that. Denis added that he hasn't checked either, but it is possible. Ruediger added that, regardless, he does not think that it is a good idea to have a system where there is the defined output object type, or class, and you
start to create some structurally different input side, in which you ask your users to indirectly manage what is defined as the actual semantic object. Denis responded that maybe they should be thinking more about how they manage data and present information, acknowledging that this might be a much bigger question, not just the aut-num object. João added that a quick check says that RPSL indeed defines a peering object. The idea might be good, but they would need to see how it would look.

Z. AOB

There were no further comments.
João thanked everyone for attending and closed the session.