October 2014 - BCOP - mailman.ripe.net

updated agenda for RIPE 69 BCOP TF
by Benno Overeinder 29 Oct '14

29 Oct '14

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/

1 0

Deaggregation by enterprise LIR document
by Iljitsch van Beijnum 24 Oct '14

24 Oct '14

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

2 2

Correlation between network complexity and troubleshooting time (and resources)...
by Jan Zorz ＠ go6.si 22 Oct '14

22 Oct '14

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

2 3

IPv6 troubleshooting for helpdesks document - please read before BCOP TF meeting in London
by Jan Zorz ＠ go6.si 20 Oct '14

20 Oct '14

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

2 3

Re: [bcop] Deaggregation by large organizations
by Iljitsch van Beijnum 16 Oct '14

16 Oct '14

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.

1 0

Deaggregation by large organizations
by Iljitsch van Beijnum 15 Oct '14

15 Oct '14

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.

3 2

tentative agenda and call for BCOPs
by Benno Overeinder 14 Oct '14

14 Oct '14

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 <benno(a)NLnetLabs.nl> or Jan <zorz(a)isoc.org>. 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/

1 0