From jan at go6.si Mon Oct 13 15:51:47 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 13 Oct 2014 15:51:47 +0200 Subject: [bcop] Correlation between network complexity and troubleshooting time (and resources)... Message-ID: <543BD8F3.3000805@go6.si> Dear BCOP community, While traveling the world and speaking with different operators - what I hear is some sort of need to have a document or "study" of ways to simplify your network in order to cut down costs of owning, running and mainly troubleshooting it. We can hear lot's of presentations (mainly from vendors and also young enthusiastic admins that sees complexity as a challenge) how to introduce new shiny features X that would do Y to your network, but also make it more complex to maintain and troubleshoot, specially makes troubleshooting longer when disaster happens. Operators started to understand that "less is more", but have troubles escaping the influences from the past, that are keeping them tied in complexity business, so the need emerged to put together some content that would explain pros and cons of complexity, how to weight and balance complexity vs. needed features and functionality and also the correlation of increased complexity on longer and harder troubleshooting. I had a quick word with some "usual suspects", but I would like to ask BCOP community if there's any interest in working together to pull this through and shed some light for new (and old operators) that making your network as complex as possible is not necessarily the best idea. If there is some interest - any volunteers to work on this subject/topic? See you all at BCOP TF meeting in London on Monday at 18:00, the first day of RIPE69 meeting ;) Cheers, Jan From benno at NLnetLabs.nl Tue Oct 14 16:34:49 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Tue, 14 Oct 2014 16:34:49 +0200 Subject: [bcop] tentative agenda and call for BCOPs Message-ID: <543D3489.2000907@NLnetLabs.nl> Hi all, We have a tentative agenda for the BCOP TF meeting on Monday 3 November, 18:00-19:00. There is still room for one or two new BCOP ideas to pitch for the TF meeting. Please send ideas to the mailing list, or directly to me or Jan . Agenda: - Opening and status update - Jan/Sander/Jen, IPv6 troubleshooting for helpdesks - Guillaume Valadon, BGP BCOP - Andrei Robachevsky, Routing Resilience Manifesto New BCOP ideas are welcome and hope to see you in London! Jan Zorz & Benno Overeinder -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From iljitsch at muada.com Wed Oct 15 16:00:14 2014 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 15 Oct 2014 16:00:14 +0200 Subject: [bcop] Deaggregation by large organizations Message-ID: Hi all, FYI, I just sent this to the IETF v6ops and grow lists: We are all familiar with PA (provider aggregatable) and PI (provider independent) address space. But it turns out a new type of IPv6 address space is starting to show up, which I'll call organization deaggregatable (OD) address space (until someone suggests a better name). How it works is like this: a large organization obtains a large block of IPv6 address space, either as a very large PI block or by becoming a local internet registry (LIR) and getting a regular LIR assignment directly from one of the five regional registries. However, rather than advertising that block in BGP as a single prefix, or perhaps a handful of prefixes, like an ISP would, they subdivide this block within the organization and then many subunits advertise subprefixes though different ISPs. The aggregate may or may not be advertised. The advantage to the organization is that they have provider independent address space that they'll never have to renumber out of, as well as having a single prefix that identifies all of the organization, which makes filtering easy. There seem to be two types of organizations that do this: geographically dispersed ones that advertise subprefixes in different locations, such as multinationals, and organizations with very independent subunits but with more limited geographical scope, such as national governments. This practice, especially if/when it becomes more common, presents two challenges: 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipality prefixes into the global IPv6 routing table. 2. Filtering. If people want to avoid large numbers of deaggregates in their routing tables, they may employ some kind of filtering, especially if the deaggregates are very long prefixes. This means that packets are no longer reliably delivered to the place announcing a more specific prefix. Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the consequences of different kinds of behavior and thus avoid unpleasant surprises. These are some of the things that could go into such best practices: - A well-understood maximum prefix length for IPv6, similar to /24 for IPv4. - An understanding of how the service providers that provide connectivity to multiple subunits of a large organization can work together in order to maximize availability and minimize costs for the organization, the service providers and other network operators. - A way to provide a point of last resort where traffic for the aggregate can be sent to if more specifics are filtered. - A set of communities that indicate whether a prefix is a more specific that is covered by an aggregate and/or is safe to filter without loss of connectivity. - A set of communities that indicate geographical origin of prefixes so remote more specific prefixes can be filtered while local prefixes are kept. - Guidelines for reserving address space in address plans. Is it better to have free space reserved so existing prefixes can grow, or keep reserved space together so tight prefix length filters are possible and reserved space isn't broken up into small pieces? Please note that I'm crosspositing this to v6ops and grow initially. If the chairs have any guidance on which working group is more appropriate for this discussion, please let us know and we can drop the other one. Also note that I haven't been following discussions in both wgs recently, so if this has been discussed previously, my apologies. Last but not least, this treads on RIR policy. But in my opinion, this is foremost a technical matter with global implications and as such is best discussed within the IETF rather than in the five respective policy development forums. From jan at go6.si Wed Oct 15 19:42:43 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 15 Oct 2014 19:42:43 +0200 Subject: [bcop] Deaggregation by large organizations In-Reply-To: References: Message-ID: <543EB213.702@go6.si> On 15/10/14 16:00, Iljitsch van Beijnum wrote: > Hi all, > > FYI, I just sent this to the IETF v6ops and grow lists: > > We are all familiar with PA (provider aggregatable) and PI (provider > independent) address space. But it turns out a new type of IPv6 > address space is starting to show up, which I'll call organization > deaggregatable (OD) address space (until someone suggests a better > name). Dear Iljitsch, My *personal* feeling is that RIRs (and NOGs) would be much more suitable place for this discussion, as IETF in principle and historically was not meant to deal with routing policy and/or routing table handling. Being said that, if you can join us on Monday, 3rd November at 18:00 in London for RIPE BCOP TF meeting, I think we can have appropriate discussion about this topic and also ask operators in the room if they would be interested to join and work cooperatively with you on this document. Dear BCOP community - Benno and myself would really appreciate some feedback on this topic before the meeting, so we can shape the message and discussion properly. Goal of the BCOP TF is to get operators together to document Best Current Operational Practice and I think this could be very well one of most needed ones. Cheers and thnx, Jan Zorz From erey at ernw.de Wed Oct 15 21:47:27 2014 From: erey at ernw.de (Enno Rey) Date: Wed, 15 Oct 2014 21:47:27 +0200 Subject: [bcop] Deaggregation by large organizations In-Reply-To: <543EB213.702@go6.si> References: <543EB213.702@go6.si> Message-ID: <20141015194727.GA35868@ernw.de> Guys, thank you very much, Iljitsch, for starting this - as I think - long needed discussion. Given I have some background as for the reasoning and perspective of "those organizations wishing to deaggregate" I will happily join the discussion in London. Please allow to point interested parties to this blogpost on the topic: http://www.insinuator.net/2014/10/deaggregation-by-large-organizations/, and to the slides referenced therein which might serve as a contribution to the discussion beforehand. cheers Enno On Wed, Oct 15, 2014 at 07:42:43PM +0200, Jan Zorz @ go6.si wrote: > On 15/10/14 16:00, Iljitsch van Beijnum wrote: > > Hi all, > > > > FYI, I just sent this to the IETF v6ops and grow lists: > > > > We are all familiar with PA (provider aggregatable) and PI (provider > > independent) address space. But it turns out a new type of IPv6 > > address space is starting to show up, which I'll call organization > > deaggregatable (OD) address space (until someone suggests a better > > name). > > Dear Iljitsch, > > My *personal* feeling is that RIRs (and NOGs) would be much more > suitable place for this discussion, as IETF in principle and > historically was not meant to deal with routing policy and/or routing > table handling. > > Being said that, if you can join us on Monday, 3rd November at 18:00 in > London for RIPE BCOP TF meeting, I think we can have appropriate > discussion about this topic and also ask operators in the room if they > would be interested to join and work cooperatively with you on this > document. > > Dear BCOP community - Benno and myself would really appreciate some > feedback on this topic before the meeting, so we can shape the message > and discussion properly. Goal of the BCOP TF is to get operators > together to document Best Current Operational Practice and I think this > could be very well one of most needed ones. > > Cheers and thnx, Jan Zorz > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From iljitsch at muada.com Thu Oct 16 11:47:04 2014 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 16 Oct 2014 11:47:04 +0200 Subject: [bcop] Deaggregation by large organizations In-Reply-To: References: Message-ID: <9633916F-AEA0-470F-ABBA-B2A8C265914A@muada.com> Let me address a few points that were brought up by different people, mostly on the v6ops and grow lists. Renumbering: We had great plans for making renumbering easy in the early days of IPv6. Remember A6 records and bitlabels in the DNS? But none of that went anywhere. The problem isn't so much that we can't push a prefix down the network or update the DNS (although both of these still have challenges associated with them), but that addresses tend to get hardcoded all over the place, starting with firewalls all the way up to homegrown applications. I don't think renumbering addresses this issue, although it could help steer some smaller organizations away from PI. A prefix length limit for the IPv6 DFZ: Someone mentioned that this didn't work in IPv6. When Sprint decided to make that /18, that didn't really work. But there's a de facto /24 limit that everyone understands. With IPv6, that would translate into a /48. Obviously no router can hold 2^48 or 2^45 prefixes, so as a backstop against accidental/malicious IPv6 routing table explosion this doesn't help. Even exploding a /28 or so into individual /48s would kill the IPv6 DFZ. What COULD work is to have prefix length limits depending on the allocation size by the RIRs. Something like: 2100::/16 -> /48 2200::/16 -> /32 2200::/15 -> /29 However, for this to work well the RIRs would have to group allocations of the same size into separate blocks, with the result that it would no longer be possible to reserve space to grow an allocation. (Things like allocating a /48 but reserving a /44 reduce the opportunities for prefix length filtering because now the strictest filter you can make allows 16 x as many prefixes worst case than average case. The worst and average case need to be as close together as possible.) I'd say that allowing two or three extra bits for traffic engineering for PA blocks would be good. So for the part of the IPv6 space where /29s are allocated, allow /31s or /32s. As traffic engineering incoming traffic by deaggregation requires that different parts of the aggregate all generate similar levels of incoming traffic, this wouldn't usually work for organizations using PI so I'd say don't allow deaggregating below /48. Geographic communities: I know this is controversial. "Topology ain't geography". Actually, most of the time there is a significant correlation. If all German cities inject a more specific, do you really need to hear those in Tokyo or Seattle? Just send the traffic to Europe as per the aggregate and let them figure it out there. Compiling a list of communities that identify regions/countries/cities would allow for experimentation in this place without any downsides that I can see. Don't like this? Filter the communities. There's a handy list that you can copy and paste into your filter. Injecting an aggregate as a point of last resort: I think this can be done today and probably is done today. But a document describing how to do it would probably be helpful. I'm thinking along the following lines: The AoLR (Aggregate of Last Resort) service would entail a service provider announcing the aggregate without necessarily providing connectivity towards all the places announcing more specifics covered by the aggregate. So if ISP A announces the AoLR and ISP B provides connectivity to a more specific, ISP C would send traffic to A as per the aggregate and then A would immediately hand it over to B. So as part of the AoLR service, a service provider would agree to accept all more specifics that fall under the aggregate (up to an agreed prefix length) from all the networks providing connectivity towards those more specifics. This would be an attractive service for tier-1s to provide, because presumably, they peer with everyone everywhere, so in the case where they receive the traffic over peering and need to deliver it to another service provider over peering, this could probably happen in the same city, so they wouldn't carry the traffic over long distances. But the (sub-)organization(s) in question still gets to buy connectivity from a wider range of smaller service providers. In practice an organization would contract two or more service providers to provide the AoLR service for redundancy. Wouldn't they just get PI: Yes. That's why I think it's important to find a way to give these organizations what they need in a way that keeps the IPv6 DFZ growth on a workable trajectory. AS numbers: BGP assumes that an AS always has internal connectivity. This can be accomplished using tunnels, but it's much better to simply have separate AS numbers for each subunit. Would it make sense to allocate ranges of AS numbers to enterprise LIRs? Certainly with 32-bit AS numbers there's no lack of numbers, and this would allow tools to be developed to work on CIDR-like AS number ranges in the future. From jan at go6.si Mon Oct 20 12:21:59 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 20 Oct 2014 12:21:59 +0200 Subject: [bcop] IPv6 troubleshooting for helpdesks document - please read before BCOP TF meeting in London Message-ID: <5444E247.1020007@go6.si> Dear RIPE BCOP community, We circulated this work in second draft some time ago and we received no substantial change requests but mostly good words about its usefulness. Reaching this stage I would like to ask those of you who did not read it yet (and would like to) to have a look at the doc as we'll ask for sense of consensus at the BCOP meeting in London - if community thinks that document is good enough to be published as BCOP RIPE document as part of normal RIPE series of documents. We'll ask for technical accuracy consensus in IPv6 working group, what we are seeking here is a consensus on usefulness, structure and content itself - that this is actually a good practice to follow. http://go6.si/ipv6-troubleshooting-for-helpdesks/ Direct link to PDF: http://go6.si/docs/IPv6-troubleshooting-for-helpdesks-v01.pdf All comments, suggestions, change_requests or support are more than welcome. Thank you and see you in London, Jan Zorz From nathalie at ripe.net Mon Oct 20 13:07:38 2014 From: nathalie at ripe.net (Nathalie Trenaman) Date: Mon, 20 Oct 2014 13:07:38 +0200 Subject: [bcop] IPv6 troubleshooting for helpdesks document - please read before BCOP TF meeting in London In-Reply-To: <5444E247.1020007@go6.si> References: <5444E247.1020007@go6.si> Message-ID: <1D2D2172-0656-4FE2-B3A0-AA596030AC26@ripe.net> Hi all, On 20 Oct 2014, at 12:21, Jan Zorz @ go6.si wrote: > Dear RIPE BCOP community, > > We circulated this work in second draft some time ago and we received no substantial change requests but mostly good words about its usefulness. > > Reaching this stage I would like to ask those of you who did not read it yet (and would like to) to have a look at the doc as we'll ask for sense of consensus at the BCOP meeting in London - if community thinks that document is good enough to be published as BCOP RIPE document as part of normal RIPE series of documents. We'll ask for technical accuracy consensus in IPv6 working group, what we are seeking here is a consensus on usefulness, structure and content itself - that this is actually a good practice to follow. > > http://go6.si/ipv6-troubleshooting-for-helpdesks/ > > Direct link to PDF: http://go6.si/docs/IPv6-troubleshooting-for-helpdesks-v01.pdf > > All comments, suggestions, change_requests or support are more than welcome. > > Thank you and see you in London, Jan Zorz > First of all, kudos for the content. I have not 1 comment about that :) Then?I think it would be wise to have a designer look at the document and make it easier to read (layout). The purpose of this document, I presume, is to have a printed copy/pdf/bookmark on the front line supporters desk(top) and they have to use it a bit as a flow chart, working their way down to eliminate issues. For that reason, I suggest a clearer layout. Cheers, Nathalie From jan at go6.si Mon Oct 20 13:16:14 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Mon, 20 Oct 2014 13:16:14 +0200 Subject: [bcop] IPv6 troubleshooting for helpdesks document - please read before BCOP TF meeting in London In-Reply-To: <1D2D2172-0656-4FE2-B3A0-AA596030AC26@ripe.net> References: <5444E247.1020007@go6.si> <1D2D2172-0656-4FE2-B3A0-AA596030AC26@ripe.net> Message-ID: <5444EEFE.50606@go6.si> On 20/10/14 13:07, Nathalie Trenaman wrote: > First of all, kudos for the content. I have not 1 comment about that > :) thnx ;) > > Then?I think it would be wise to have a designer look at the document > and make it easier to read (layout). The purpose of this document, I > presume, is to have a printed copy/pdf/bookmark on the front line > supporters desk(top) and they have to use it a bit as a flow chart, > working their way down to eliminate issues. For that reason, I > suggest a clearer layout. Can you be a bit more specific and go a bit more into details? I like way where the suggestion goes, but I'm nut sure I understand and/or know how to get there and how the document would look like at the end... Cheers and thnx, Jan From nathalie at ripe.net Mon Oct 20 13:40:59 2014 From: nathalie at ripe.net (Nathalie Trenaman) Date: Mon, 20 Oct 2014 13:40:59 +0200 Subject: [bcop] IPv6 troubleshooting for helpdesks document - please read before BCOP TF meeting in London In-Reply-To: <5444EEFE.50606@go6.si> References: <5444E247.1020007@go6.si> <1D2D2172-0656-4FE2-B3A0-AA596030AC26@ripe.net> <5444EEFE.50606@go6.si> Message-ID: <3667F83B-7E08-4706-AF42-9CDC540171C8@ripe.net> > >> >> Then?I think it would be wise to have a designer look at the document >> and make it easier to read (layout). The purpose of this document, I >> presume, is to have a printed copy/pdf/bookmark on the front line >> supporters desk(top) and they have to use it a bit as a flow chart, >> working their way down to eliminate issues. For that reason, I >> suggest a clearer layout. > > Can you be a bit more specific and go a bit more into details? I like way where the suggestion goes, but I'm nut sure I understand and/or know how to get there and how the document would look like at the end... For example, In section 6, I would frame the indented text of the http://isp.test-ipv6.com output, and highlight the actions. So you can see in one blink the result and what to do. I don?t know, I?m not a designer, but I have seen them do remarkable things for readability of documents :D Maybe one of the designers of the RIPE NCC can help out. I can ask them to make an example if you want? Cheers, Nathalie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwbensley at gmail.com Tue Oct 21 13:46:38 2014 From: jwbensley at gmail.com (James Bensley) Date: Tue, 21 Oct 2014 12:46:38 +0100 Subject: [bcop] Correlation between network complexity and troubleshooting time (and resources)... In-Reply-To: <543BD8F3.3000805@go6.si> References: <543BD8F3.3000805@go6.si> Message-ID: Hi Jan, I have seen papers from vendors before on this, such as http://www-05.ibm.com/uk/juniper/pdf/200249.pdf I am keep on this ideaology of keeping things simple as possible to reduce the surface area of potential human error. This is of course caveated against (i) unavoidable complexity because that's the service we've sold to a customer or just simply the service the customer requires and (ii) more densely interconnected networks can't avoid a minimum level of complexity. We can catch up at RIPE if you'd like? Kind regards, James. From jan at go6.si Tue Oct 21 15:18:59 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 21 Oct 2014 15:18:59 +0200 Subject: [bcop] Correlation between network complexity and troubleshooting time (and resources)... In-Reply-To: References: <543BD8F3.3000805@go6.si> Message-ID: <54465D43.6050409@go6.si> On 21/10/14 13:46, James Bensley wrote: > Hi Jan, Hi, > > I have seen papers from vendors before on this, such as > http://www-05.ibm.com/uk/juniper/pdf/200249.pdf > > I am keep on this ideaology of keeping things simple as possible to > reduce the surface area of potential human error. This is of course > caveated against (i) unavoidable complexity because that's the service > we've sold to a customer or just simply the service the customer > requires and (ii) more densely interconnected networks can't avoid a > minimum level of complexity. Would you like to discuss this at BCOP meeting? We could spend few minutes on this topic as apparently it's a interesting one for wider audience. The best possible outcome of BCOP TF meeting would be if we could get a small group of co-authors that would start documenting this topic... I learned that you start with a title and table of content and then everything is much easier :) > > We can catch up at RIPE if you'd like? Sure, see you in London ;) Cheers, Jan From jwbensley at gmail.com Wed Oct 22 10:49:44 2014 From: jwbensley at gmail.com (James Bensley) Date: Wed, 22 Oct 2014 09:49:44 +0100 Subject: [bcop] Correlation between network complexity and troubleshooting time (and resources)... In-Reply-To: <54465D43.6050409@go6.si> References: <543BD8F3.3000805@go6.si> <54465D43.6050409@go6.si> Message-ID: On 21 October 2014 14:18, Jan Zorz @ go6.si wrote: > Would you like to discuss this at BCOP meeting? We could spend few minutes > on this topic as apparently it's a interesting one for wider audience. > > The best possible outcome of BCOP TF meeting would be if we could get a > small group of co-authors that would start documenting this topic... I > learned that you start with a title and table of content and then everything > is much easier :) Well I don't want to get up on stage and talk about it if that's why you mean :) I swear alot and don't really hold it back very well. Happy to talk in person though and/or a beer of course! >> >> We can catch up at RIPE if you'd like? > > > Sure, see you in London ;) > > Cheers, Jan Sure, see you there! Cheers, James. From iljitsch at muada.com Wed Oct 22 22:36:31 2014 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Wed, 22 Oct 2014 22:36:31 +0200 Subject: [bcop] Deaggregation by enterprise LIR document Message-ID: Hi, I've posted a draft to the IETF draft repository: Controlled IPv6 deaggregation by large organizations draft-van-beijnum-grow-controlled-deagg-00 http://tools.ietf.org/html/draft-van-beijnum-grow-controlled-deagg-00 Please have a look. The idea is to garner more discussion. The second half goes into a good amount of detail regarding the encoding of geographical locations, feel free to skip over that part and stick to a higher level discussion of the issue. Iljitsch From jan at go6.si Fri Oct 24 11:21:31 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 24 Oct 2014 11:21:31 +0200 Subject: [bcop] Deaggregation by enterprise LIR document In-Reply-To: References: Message-ID: <544A1A1B.2080309@go6.si> On 22/10/14 22:36, Iljitsch van Beijnum wrote: > Hi, > > I've posted a draft to the IETF draft repository: > > Controlled IPv6 deaggregation by large organizations > draft-van-beijnum-grow-controlled-deagg-00 > > http://tools.ietf.org/html/draft-van-beijnum-grow-controlled-deagg-00 > > Please have a look. The idea is to garner more discussion. Dear BCOP community, I think this is the idea worth reading, specially because Iljitsch will present this document during BCOP TF meeting in London and then we can have a discussion about the idea and the operational usefulness of it - and maybe ask RIPE Routing WG to take a look into technical details of this document (Rob, are you here on this list? :) ) Author chose the RFC format and this is ok. We still don't have a "prescribed" format for BCOP documents in our TF and this is also ok - everyone can choose his/her own format and way of putting the content into documents - so don't be shy... Please, read the RFC, maybe ask Iljitsch to explain it in few sentences here on mailinglist before meeting and then give some feedback in London. Thank you, Jan From iljitsch at muada.com Fri Oct 24 13:02:37 2014 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 24 Oct 2014 13:02:37 +0200 Subject: [bcop] Deaggregation by enterprise LIR document In-Reply-To: <544A1A1B.2080309@go6.si> References: <544A1A1B.2080309@go6.si> Message-ID: On 24 Oct 2014, at 11:21, Jan Zorz @ go6.si wrote: > Author chose the RFC format and this is ok. We still don't have a "prescribed" format for BCOP documents in our TF and this is also ok - everyone can choose his/her own format and way of putting the content into documents - so don't be shy... I used the draft format (which looks like an RFC) because I also want to discuss this in the IETF. Here are the main parts of the text: Abstract The use of IPv6 addresses by large organizations doesn't fit the commonly used PA/PI dichotomy. Such organizations may hold a large address block which is deaggregated into subprefixes that are advertised by subunits of the organization. This document proposes a set of best practices to allow this deaggregation to be controlled through filtering so that on the one hand, the size of the IPv6 global routing table isn't unduly inflated, while on the other hand organizations that seek to deaggregate a large IPv6 address block don't see their reachability limited by remote filters. 1. Introduction Generally, two classes of global unicast address prefixes are recognized: provider aggregatable (PA) and provider independent (PI). PA prefixes are the prefixes advertised into the global routing table by ISPs, covering the addresses used by multiple customers of that ISP. PI prefixes are the address blocks used by a single organization. However, there is a third class of addresses: the addresses used by large organizations with subunites that independently connect to the internet. An example are multinational corporations. Another are national governments. Such organizations often desire a single IPv6 prefix so the addresses used by subunits are easily recognized as being part of the larger organization in firewalls and router filters. As such, many of these organizations become "enterprise LIRs" (local internet registries) at one or more of the five regional internet registries (RIRs) that distribute IP addresses. However, unlike regular LIRs (ISPs), they are not in the business of moving IP packets between locations, and as such different locations or subunits advertise deaggregates (subprefixes) of the organization's LIR PA prefix, often to different ISPs. This advertisement of deaggregates would be unexpected from regular LIRs, and as such, the deaggregates may be filtered. Currently, the IPv6 global routing table is small and in no immediate danger of growing beyond what today's routers can handle. However, without some of the limitations that are present in IPv4, the IPv6 routing table could conceivably grow at a high rate for decades to come, and would then at some point become hard to manage. This document proposes two mechanisms that will allow organizations that seek to deaggregate an enterprise LIR prefix to enjoy the same level of connectivity as users of PI and PA space while at the same time limiting the impact of this practice on the IPv6 global routing table. The first mechanism is the establishment of an "aggregate of last resort" (AoLR), the second mechanism is a set of communities that allow deaggregates to be filtered in some parts of a network without loss of reachability. This document is meant to start a discussion. As such, it may be split into several documents, and/or the venue for discussion and eventual publication is subject to change. 2. The aggregate of last resort service The assumption is that an enterprise LIR allocates addresses from a single block to different organizational subunits, and that these subunits advertise those smaller blocks to the ISPs they use to connect to the internet, where different subunits use different ISPs. For reasons of cost and routing efficiency it's not possible or desired to use an internal network between the subunits or locations to transport traffic to/from the internet from one organizational subunit to another. One way to run such a network would be for the enterprise to advertise its aggregate in a small number of locations. The traffic is then delivered to those locations, and then from there sent back to an ISP that has a path to the subunit in question. However, this has the downside that traffic has to pass through one of the locations advertising the aggregate, using up additional bandwidth and possibly incurring long detours. For instance, if an organization advertises its prefix in Europe then a third party in the US that sends traffic to one of the organization's offices in the US may see its traffic cross the Atlantic twice. The solution is to ask one or more ISPs to advertise the aggregate?preferably ones with a large geographic footprint. By default, networks hand over traffic to a remote network as soon as possible ("hot potato" routing), so in this case the traffic just has to flow to the closest location where the ISP in question has a presence. If that ISP then connects to an ISP serving the organizational subunit in question, the traffic can be handed over between the two ISPs at the nearest location where they interconnect. This way, deaggregates only have to be carried by ISPs providing the aggregate of last resort service and the ISPs connecting subunits of the organization. Because the organization has customer - service provider relationships with each, presumably those ISPs will not filter the deaggregates. The rest of the document talks about encoding GPS coordinates into BGP communities, which gets a bit detailed. Iljitsch From benno at NLnetLabs.nl Wed Oct 29 15:56:08 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Wed, 29 Oct 2014 15:56:08 +0100 Subject: [bcop] updated agenda for RIPE 69 BCOP TF Message-ID: <54510008.5010204@NLnetLabs.nl> Hi all, We have an updated (and final) agenda for the BCOP TF meeting on Monday 3 November, 18.00-19.20. Agenda: - Opening [< 3 min] - BCOP around the world, Aaron Hughes [5 min] - Euro-IX IXP BCOPs, Bijal Sanghani [10 min] - IPv6 troubleshooting for helpdesks, Jen Linkova [12 min] - BCP38 + Enterprise and IX filtering, Aaron Hughes [12 min] - BGP BCOP, Guillaume Valadon [12 min] - Deaggregation by large organizations, Iljitsch van Beijnum [15 min] - MANRS (aka Routing Resilience Manifesto), Andrei Robachevsky [12 min] Hope to see you in London! Jan Zorz Benno Overeinder -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/