- BCOP - mailman.ripe.net

IPv6 deployment for small residential providers
by William Waites 10 Nov '14

10 Nov '14

Just to follow up on the question I just asked following the BCOP draft on troubleshooting IPv6 for residential providers, should we write a companion document focused on small providers that explains how to deploy IPv6? I am happy to start writing, would anyone like to help? Cheers, -w

6 9

Re: [bcop] IPv6 deployment for small residential providers
by 马严 04 Nov '14

04 Nov '14

1 0

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

IPv6 troubleshooting for helpdesks - draft v.01
by Jan Zorz ＠ go6.si 09 Sep '14

09 Sep '14

Dear BCOP community, Just to let you know, the co-authors of "IPv6 troubleshooting for helpdesks" document published the next version of the document with some new and also a bit more fine tuned old content and revised structure. Please find the latest version in attach and also on following URL: http://go6.si/ipv6-troubleshooting-for-helpdesks/ http://go6.si/docs/IPv6-troubleshooting-for-helpdesks-v01.pdf (direct download) As the role of this BCOP TF is to find possible cooperation and further contribution - please read the document and contact the authors if you would like to work together and add some ideas. All other ideas and suggestions also welcome on this list. Cheers and thnx, Jan Zorz

1 0

Feedback Requested: Routing Resilience Manifesto
by Benno Overeinder 02 Sep '14

02 Sep '14

Posted for Andrei Robachevsky, ISOC. Colleagues, A small group of network operators has been working on defining a minimal, but feasible package of recommended measures that, if deployed on a wide scale, could result in visible improvements to the security and resilience of the global routing system. Many operators are ahead of the curve and already implement much more than the proposed recommendations. But we believe that gathering support for these relatively small steps could pave the road to more significant actions on a global scale. We called this set of recommendations a Routing Resilience Manifesto – you can find a draft document here: https://www.routingmanifesto.org/. This initial version of the Manifesto was drafted by a small group, but we need a wider community review, your feedback, and, ultimately, your support to make this initiative fly. It was already presented at several venues, like RIPE and NANOG, and now we open it for a more detailed review. Please note that this is very much a work in progress. Please review the document and provide your feedback and text suggestions online or via routingmanifesto(a)isoc.org by 31 August 2014. Regards, Andrei Robachevsky Internet Society

3 3

Re: [bcop] Fwd: [Bcop-gc] documentation ipv6 prefix
by 马严 27 Aug '14

27 Aug '14

6 7

Re: [bcop] Fwd: [Bcop-gc] documentation ipv6 prefix
by Alex Saroyan 22 Aug '14

22 Aug '14

Hi, From another view maybe it is better to "teach" people to better understand ipv6 subneting and prevent possible classfull style misconceptions. Best. /Alex "Jan Zorz @ go6.si" <jan(a)go6.si> wrote: >On 22/08/14 02:56, 马严 wrote: >> Hi, Jan and all, >> >> As RFC3849 specified, the prefix reserved for documentation is a /32 block, >> 2001:DB8::/32 >> while people can use the following: >> net A = 2001:db8:1::/48 >> net B = 2001:db8:2::/48 >> net C = 2001:db8:3::/48 >> we can also use >> net A = 2001:db8:1::/48 >> net B = 2001:db8:8000::/48 >> net C = 2001:db8:a000::/48 >> for being easy recognized as separated networks. > >Yes, I agree, but this is different just to some limited extent. People, >not very familiar with IPv6 and on their learning curve might mistakenly >understand this as prefixes in one network. To be really sure they >distinguish between the networks (being just different local networks or >different AS-es) I think completely different IPv6 prefixes should be >used, visually different from the first "character" on... > >I thought this is what Japanese colleagues are suggesting... > >(Including Seiichi-san to cc:) > >Cheers, Jan > >> The only shortcoming that I can think of is, because 2001:db8::/32 is >> one big block, when being used to describe >> inter-domain network topology, /32 address block may easily be >> considered as all networks belong to one organization. >> Any comment? >> >> I also cc:ed this email to the co-author of RFC3849, G.Huston, Chief >> Scientist from APNIC, for further discussion. >> >> Best regards, >> --MA Yan >> >> ----- reply email ----- >> *Sender:*Jan Zorz @ go6.si <jan(a)go6.si> >> *Recipient:*bcop <bcop(a)ripe.net> >> *Time:*08/21/2014 22:11:55 >> *Subject:*[bcop] Fwd: [Bcop-gc] documentation ipv6 prefix >> >> >> Dear RIPE BCOP community, >> >> I got a question from Seiichi Kawamura, JANOG BCOP co-chair and I think >> this suggestion/question would be best if discussed here on this >> mailing >> list (and maybe also on IPv6 WG ml). >> >> Please read below. >> >> Cheers, Jan >> >> -------- Original Message -------- >> Date: Tue, 19 Aug 2014 10:04:56 +0900 >> From: Seiichi Kawamura <kawamucho(a)mesh.ad.jp> >> >> Fellow BCOPers >> >> Hi there. >> Some folks in Japan, especially tech >> bloggers and tech documentation producers >> are saying that we need more ipv6 documentation >> prefix than just 2001:db8::/32 >> >> When describing a classic 3 prefix >> network topology they would use >> >> net A = 2001:db8:1::/48 >> net B = 2001:db8:2::/48 >> net C = 2001:db8:3::/48 >> >> where as with v4, >> >> net A = 192.0.2.0/24 >> net B = 198.51.100.0/24 >> net C = 203.0.113.0/24 >> >> The 3 IPv6 prefixes are too similar and it's >> intuitively hard to tell if the 3 prefixes are >> talking about a network, or is it 3 separate networks. >> I guess this is bad especially for educational >> tutorial documentation. >> >> So I'm thinking that if there are 2 more prefixes >> defined as documentation, I would say that's enough. >> We can maybe even revive 3ffe:: and make that documentation purpose. >> >> However, I'm intersted in hearing opinions from other regions. >> Do you think there are any such needs in your region? >> >> -Seiichi >> >> _______________________________________________ >> Bcop-gc mailing list >> Bcop-gc(a)elists.isoc.org >> https://elists.isoc.org/mailman/listinfo/bcop-gc >> >> >> > >

1 0

Fwd: [Bcop-gc] documentation ipv6 prefix
by Jan Zorz ＠ go6.si 21 Aug '14

21 Aug '14

Dear RIPE BCOP community, I got a question from Seiichi Kawamura, JANOG BCOP co-chair and I think this suggestion/question would be best if discussed here on this mailing list (and maybe also on IPv6 WG ml). Please read below. Cheers, Jan -------- Original Message -------- Date: Tue, 19 Aug 2014 10:04:56 +0900 From: Seiichi Kawamura <kawamucho(a)mesh.ad.jp> Fellow BCOPers Hi there. Some folks in Japan, especially tech bloggers and tech documentation producers are saying that we need more ipv6 documentation prefix than just 2001:db8::/32 When describing a classic 3 prefix network topology they would use net A = 2001:db8:1::/48 net B = 2001:db8:2::/48 net C = 2001:db8:3::/48 where as with v4, net A = 192.0.2.0/24 net B = 198.51.100.0/24 net C = 203.0.113.0/24 The 3 IPv6 prefixes are too similar and it's intuitively hard to tell if the 3 prefixes are talking about a network, or is it 3 separate networks. I guess this is bad especially for educational tutorial documentation. So I'm thinking that if there are 2 more prefixes defined as documentation, I would say that's enough. We can maybe even revive 3ffe:: and make that documentation purpose. However, I'm intersted in hearing opinions from other regions. Do you think there are any such needs in your region? -Seiichi _______________________________________________ Bcop-gc mailing list Bcop-gc(a)elists.isoc.org https://elists.isoc.org/mailman/listinfo/bcop-gc

1 0

BCOP presentation at RIPE meeting in Warsaw
by Jan Zorz ＠ go6.si 10 Jun '14

10 Jun '14

Dear BCOP group, I would like to get a short slot in BCOP TF meeting in Warsaw, I would like to present the 00 version of a draft "IPv6 troubleshooting for helpdesks" The 00 draft can be found in PDF format here: http://go6.si/ipv6-troubleshooting-for-helpdesks/ (find the link at the end of the text). I would encourage you to read the text and comment in terms if this is something that could be the best current operational practice - and particularly I'm searching for people that would join the working pack and continue the technical IPv6 part in IPv6 WG, where we would like to check for IPv6 technical validity and soundness of the document. Thank you very much, Jan Zorz

3 9

Re: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs
by Alex Saroyan 22 May '14

22 May '14

Hi, Maybe I missed something, was busy to participate this Ripe meeting. Just want to express my will in participating to BGP BCOP. Best Regards /Alex Saroyan Chris Grundemann <cgrundemann(a)gmail.com> wrote: >On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong <wrarmstrong(a)gmail.com> wrote: >> Thanks for the info Benno! With that also being a fledgling initiative, >> there is probably no harm in NANOG moving toward that same goal...Now, >> merging the documents and determining which best practice is in-fact BEST >> may become interesting, but that is a problem for the future. > >Indeed! > >>From my perspective: After NANOG 61 we should have a good grasp on who >all from this region is willing and able to participate. At that time >I suggest that we merge the interested NANOGers with the interested >RIPE'rs and form one BGP BCOP cross-regional working group to build a >single document which we can both publish (or we can choose one place >to publish if that makes more sense)... > >I note that the RIPE "IPv6 Helpdesk" BCOP is being written using a >similar model, with folks from both regions working together to draft >a single document. > >$0.02 >~Chris > >> >> Bill >> >> >> On Wed, May 21, 2014 at 3:37 PM, Benno Overeinder <benno(a)nlnetlabs.nl> >> wrote: >>> >>> Hi, >>> >>> With the last RIPE68 meeting, a BGP configuration BCOP proposal was >>> presented by Francios Contat, see >>> https://ripe68.ripe.net/programme/meeting-plan/bcop-tf/. >>> >>> In the slides, Francios explained their approach: get ISPs on board, >>> definitions, scenarios, good practices, etc. The presentation was a call for >>> interest for others to join. Next is to redefine goals, scope, etc., such >>> that it will become a manageable document. Work to obtain input, review, >>> collect comments will take place in the RIPE Routing Working Group. >>> >>> The document already available is in French, but Google translate does a >>> good job to obtain an English version. >>> >>> Best, >>> >>> Benno Overeinder >>> >>> >>> Op 21 mei 2014 om 17:35 heeft Bill Armstrong <wrarmstrong(a)gmail.com> het >>> volgende geschreven: >>> >>> Ahoy There! >>> Over the last few months the NANOG BCOP committee has combed through the >>> NANOG and various other NOG/IETF-Ops mailing lists and have identified a >>> stack reoccurring or pressing questions and concerns which we are using as >>> seeds for our initial BCOP Appeals. One exceptionally frequent line of >>> questions tend to be rooted in what amounts to "eBGP 101/102"(how to turn up >>> and test a peer and potential pitfalls there-in). While there is already a >>> "Public Peering Exchange" BCOP and a draft for "IPv6 Peering" is in the >>> works, it appears that the fundamentals need to be captured and put on >>> display. Although there are already a handful of SMEs on-board, our goal is >>> to define the BEST practices so the more insight we can get into this >>> problem the better! If you are interested in acting as a SME for the "eBGP >>> Configuration BCOP" please let me know, this is your chance to sow your >>> expertise across the internet! >>> >>> THANKS! >>> Bill Armstrong >>> >>> P.S. >>> I'll be at NANOG 61 so if you aren't sure about the commitment or have >>> questions about the BCOP process don't hesitate to track me down for a chat! >>> >>> _______________________________________________ >>> >>> BCOP mailing list >>> BCOP(a)mailman.nanog.org >>> http://mailman.nanog.org/mailman/listinfo/bcop >> >> >> >> _______________________________________________ >> BCOP mailing list >> BCOP(a)mailman.nanog.org >> http://mailman.nanog.org/mailman/listinfo/bcop >> > > > >-- >@ChrisGrundemann >http://chrisgrundemann.com >

8 7

Re: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs
by Benno Overeinder 22 May '14

22 May '14

Hi, With the last RIPE68 meeting, a BGP configuration BCOP proposal was presented by Francios Contat, see https://ripe68.ripe.net/programme/meeting-plan/bcop-tf/. In the slides, Francios explained their approach: get ISPs on board, definitions, scenarios, good practices, etc. The presentation was a call for interest for others to join. Next is to redefine goals, scope, etc., such that it will become a manageable document. Work to obtain input, review, collect comments will take place in the RIPE Routing Working Group. The document already available is in French, but Google translate does a good job to obtain an English version. Best, Benno Overeinder > Op 21 mei 2014 om 17:35 heeft Bill Armstrong <wrarmstrong(a)gmail.com> het volgende geschreven: > > Ahoy There! > Over the last few months the NANOG BCOP committee has combed through the NANOG and various other NOG/IETF-Ops mailing lists and have identified a stack reoccurring or pressing questions and concerns which we are using as seeds for our initial BCOP Appeals. One exceptionally frequent line of questions tend to be rooted in what amounts to "eBGP 101/102"(how to turn up and test a peer and potential pitfalls there-in). While there is already a "Public Peering Exchange" BCOP and a draft for "IPv6 Peering" is in the works, it appears that the fundamentals need to be captured and put on display. Although there are already a handful of SMEs on-board, our goal is to define the BEST practices so the more insight we can get into this problem the better! If you are interested in acting as a SME for the "eBGP Configuration BCOP" please let me know, this is your chance to sow your expertise across the internet! > > THANKS! > Bill Armstrong > > P.S. > I'll be at NANOG 61 so if you aren't sure about the commitment or have questions about the BCOP process don't hesitate to track me down for a chat! > _______________________________________________ > BCOP mailing list > BCOP(a)mailman.nanog.org > http://mailman.nanog.org/mailman/listinfo/bcop

3 3

Updated RIPE 68 BCOP TF agenda, Monday 12 May
by Benno Overeinder 09 May '14

09 May '14

Please find below the provisional agenda for the BCOP TF meeting at RIPE 68, Monday 12 May, 18:00-19:00. * Opening: BCOP TF charter (discussion and approve charter text) (5-10 min) * IPv6 troubleshooting for helpdesks, Jan Zorz et al. (15 min) * BGP configuration BCOP, Francois Contat et al. (15 min) * DNSSEC operational practices for authoritative name servers, Matthijs Mekking (15 min) * Update on the "Code of Conduct" Initiative, Andrei Robachevsky (10 min) * Closing: new ideas for BCOP documents and follow-up (5-10 min) New ideas for BCOP documents are of course still welcome and can be discussed at closing of TF session or on the email list. Best regards, -- Benno and Jan -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Re: [bcop] RIPE 68 BCOP TF agenda, Monday 12 May
by 马严 08 May '14

08 May '14

1 0

RIPE 68 BCOP TF agenda, Monday 12 May
by Benno Overeinder 07 May '14

07 May '14

Hi, Please find below the provisional agenda for the BCOP TF meeting at RIPE 68, Monday 12 May, 18:00-19:00. * Opening: BCOP TF charter (discussion and approve charter text) (5-10 min) * IPv6 troubleshooting for helpdesks, Jan Zorz et al. (15 min) * BGP configuration BCOP, Francois Contat et al. (15 min) * DNSSEC operational practices for authoritative name servers, Matthijs Mekking (15 min) * Closing: new ideas for BCOP documents and follow-up (5-10 min) New ideas for BCOP documents are of course still welcome and can be discussed at closing of TF session or on the email list. Best regards, -- Benno and Jan -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

2 1

BCOP on DNSSEC
by Matthijs Mekking 16 Apr '14

16 Apr '14

Hi, FYI. Within the IETF, we have two versions of documents describing DNSSEC operational practices for authoritative name servers. These documents are very lengthy because they are considerations and take into account many possibilities. I am now thinking of writing a best current operational practices. To me it makes sense that these can be (at least) two documents, for TLD operators and for hosters of many zones. I hope I can start this activity soon and perhaps I can share some of that work in BCOP at Warsaw. Best regards, Matthijs

2 1

Best Current Operational Practices TF proposed charter published
by Benno Overeinder 07 Apr '14

07 Apr '14

Hi, The RIPE BCOP Task Force proposed charter is now published on the RIPE TF webpage, see http://www.ripe.net/ripe/groups/tf/best-current-operational-practices-task-…. Comments on proposed charter are welcome on the bcop(a)ripe.net mailing list and the TF meeting in Warsaw. We intend to get the charter approved at the first TF meeting in Warsaw. Best regards, Jan Zorz & Benno Overeinder -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Call for proposals BCOP task force
by Benno Overeinder 07 Apr '14

07 Apr '14

The RIPE BCOP Task Force proposed charter is now published on the RIPE TF webpage, see http://www.ripe.net/ripe/groups/tf/best-current-operational-practices-task-…. Now we are accepting the proposals for presentations from intended BCOP documents authors for our next RIPE meeting in Warsaw. If you are willing to start working on your own Best Current Operational Practices - BCOP document and talk about that in Warsaw (and maybe get some co-authors), please get in touch with Jan or myself. Best, Jan Zorz and Benno Overeinder -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/

1 0

Re: [bcop] Indosat (AS4761) BGP Hijack
by Blake WILLIS 07 Apr '14

07 Apr '14

On 3 Apr 2014, at 1:45 PM, IP TAC wrote: > Dear Partner, > > The problem caused by misconfig by our third-party support. > We already have plan to prevent the problem exist in the future if any misconfig happen again. > We apologize for the inconvenience. Greetings, May I take this opportunity to suggest that you (& anyone else listening that doesn't already have two levels of prevention on their BGP customers) implement a BGP max-prefix setting on your customer peer-groups to prevent this sort of incident in the future (in addition to using per-customer prefix filters)? Plenty of networks are rolling out IPv6; <A HREF="http://en.wikipedia.org/wiki/Resource_Public_Key_Infrastructure">RPKI</A> may take longer... Best regards, --- Blake Willis Consulting Network Architect

2 1

Content Providers and IPv6
by Chris Grundemann 26 Nov '13

26 Nov '13

Hail BCOPers! I've had quite a bit of interest from several folks in BCOPs for deploying IPv6 at a content provider. Who has experience in this realm? We need a few SMEs with real experience to put this together. Please respond if you are interested and I'll help organize the effort. CDNs are another (subset) area to look into as well - calling all SMEs... Thanks! ~Chris -- @ChrisGrundemann http://chrisgrundemann.com

4 4