- BCOP - mailman.ripe.net

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