From benno at NLnetLabs.nl Mon May 5 17:21:25 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Mon, 05 May 2014 17:21:25 +0200 Subject: [bcop] RIPE 68 BCOP TF agenda, Monday 12 May Message-ID: <5367AC75.7070207@NLnetLabs.nl> 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/ From robachevsky at isoc.org Wed May 7 17:49:21 2014 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Wed, 7 May 2014 17:49:21 +0200 Subject: [bcop] RIPE 68 BCOP TF agenda, Monday 12 May In-Reply-To: <5367AC75.7070207@NLnetLabs.nl> References: <5367AC75.7070207@NLnetLabs.nl> Message-ID: <536A5601.9020408@isoc.org> Hi, If we have time I can give an update on the "code of conduct" initiative I presented in Athens. It got renamed into Routing Resilience Manifesto and has some substance now, but still far from being complete. Andrei Benno Overeinder wrote on 05/05/14 17:21: > 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 > > From mayan at bupt.edu.cn Thu May 8 07:48:17 2014 From: mayan at bupt.edu.cn (=?gbk?B?wu3Rzw==?=) Date: Thu, 08 May 2014 07:48:17 +0800(CST) Subject: [bcop] =?gbk?q?RIPE_68_BCOP_TF_agenda=2C_Monday_12_May?= Message-ID: <20140507234817.1CE5519F374@mx1.bupt.edu.cn> An HTML attachment was scrubbed... URL: From benno at NLnetLabs.nl Fri May 9 09:49:01 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 09 May 2014 09:49:01 +0200 Subject: [bcop] Updated RIPE 68 BCOP TF agenda, Monday 12 May Message-ID: <536C886D.7060402@NLnetLabs.nl> 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/ From furry13 at gmail.com Thu May 15 00:57:39 2014 From: furry13 at gmail.com (Jen Linkova) Date: Thu, 15 May 2014 00:57:39 +0200 Subject: [bcop] BCOP presentation at RIPE meeting in Warsaw In-Reply-To: <53467548.9050407@go6.si> References: <53467548.9050407@go6.si> Message-ID: Hi Jan, finally I've managed to summarize my comments to the doc ;) 0) the document says that the target audience is residential ISPs and enterprise IT helpdesk while most of troubleshooting steps are mostly applicable for residential ISPs as they imply that there are CPE/home devices/etc. Shall we create another doc for enterprise networks or just extend this one? 1) You suggest to have a local mirror of the test-ipv6. While it definitely makes sense, using the local mirror might hide some edge connectivity issues so it worth mentioning. We might recommend to use *both*. 2) Section 5 You provide detailed instruction on how to run ping, but then saying just 'check DNS settings' and even 'configure different servers' - support engineers who need explanations on ping, would need more detailed explanations on how to change DNS settings. "If IPv4 is working but the page is unavaliable' - I'd assume that an engineer could not tell if 'IPv4 is working'. So IMHO we shall just say that if site is unreachange - troubleshoot as any other 'I can not open this page' v4-only case. If we believe that troubleshooting such case is in scope of this document, I'd suggest to include traceroute as a troubleshooting step. 3) Helpdesk code section: I'd use different fonts/color to distinguish between 'fixed' and 'example' fields in the output. 4) Code 112 (v4 + broken Ipv6) - can we show the process as a flowchart? if-then-else? For example, the doc says 'determine if Ipv6 is offered'. I'd add 'if it is not,, the customer either has a misconfigured CPE (which has IPv6 enables while it should not), or there is other Ipv6-enabled device which is used as a router. Check CPE configuration/state for IPv6 and disable it if it has it enabled'. - I'd re-phrase step 2 as smth like 'if IPv6 is offered to the customer and you manage their CPE, check if CPE has a approved firmware version. Upgrade it if it does not'. - I'd say that grep (to find the IPv6 address on MacOS) should be 'grep -E "en|inet6" so interface name is visible (to avoid the scnario when addresses are assigned to wrong interface); - the IPv6 addresses table is a little bit confusing: -- it contains 6to4 case which should not cause code 112 (as well as Teredo case); -- some sections say 'call theor router vendor for support'. I believe we shall clarify somewhere in the beginning of the document that we assume that the support deals with customers CPE and if it is not a case, those CPE-related instructions should be either 'escalate' or 'advise customer to contact their router vendor for support' (which in my reality would never happen.....:) -- as each section of the tabel has instructions (and the last row says 'escalate', it is not clear in which case the engieer should proceed to the next step (checking the home router config). the section of home router config check is a little bit confusing. When we just say 'check the configuration of the device', it does not mean much as we don't specify what we are looking for. Maybe we shall say smth like: - 'if CPE is managed by your support, check if CPE is configured as per your internal documentation' (as we might say somewhere in the doc that in that case it is strongly recommended to have a separate how-to on what should be configured on those CPEs); - check if the LAN interface has IPv6 address from the ISP allocated range; - check on user device if it has routers's both link-local (fe80:...) and ISP-assigned address in the neighbor discovery cache ( wrote: > 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 > -- SY, Jen Linkova aka Furry From benno at NLnetLabs.nl Wed May 21 22:37:59 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Wed, 21 May 2014 22:37:59 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: References: Message-ID: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> 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 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 at mailman.nanog.org > http://mailman.nanog.org/mailman/listinfo/bcop -------------- next part -------------- An HTML attachment was scrubbed... URL: From cgrundemann at gmail.com Thu May 22 00:19:42 2014 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 21 May 2014 16:19:42 -0600 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: References: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> Message-ID: On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong 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 > 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 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 at mailman.nanog.org >> http://mailman.nanog.org/mailman/listinfo/bcop > > > > _______________________________________________ > BCOP mailing list > BCOP at mailman.nanog.org > http://mailman.nanog.org/mailman/listinfo/bcop > -- @ChrisGrundemann http://chrisgrundemann.com From alexsaroyan at gmail.com Thu May 22 08:13:11 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Thu, 22 May 2014 10:13:11 +0400 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs Message-ID: 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 wrote: >On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong 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 >> 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 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 at mailman.nanog.org >>> http://mailman.nanog.org/mailman/listinfo/bcop >> >> >> >> _______________________________________________ >> BCOP mailing list >> BCOP at mailman.nanog.org >> http://mailman.nanog.org/mailman/listinfo/bcop >> > > > >-- >@ChrisGrundemann >http://chrisgrundemann.com > From wrarmstrong at gmail.com Thu May 22 00:13:25 2014 From: wrarmstrong at gmail.com (Bill Armstrong) Date: Wed, 21 May 2014 17:13:25 -0500 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> References: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> Message-ID: 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. Bill On Wed, May 21, 2014 at 3:37 PM, Benno Overeinder 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 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 at mailman.nanog.org > http://mailman.nanog.org/mailman/listinfo/bcop > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zorz at isoc.org Thu May 22 09:11:45 2014 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Thu, 22 May 2014 09:11:45 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> References: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> Message-ID: <537DA331.7020801@isoc.org> On 21/05/14 22:37, Benno Overeinder 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. hey, yes, we need a group of people that would go ahead, write the draft in English and put it in NANOG and RIPE BCOP iniciatives for review/comment phase... Cheers, Jan From zorz at isoc.org Thu May 22 09:16:56 2014 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Thu, 22 May 2014 09:16:56 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: References: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> Message-ID: <537DA468.7010501@isoc.org> On 22/05/14 00:13, Bill Armstrong 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. Hi, Yes, that's the reason why we are playing with the idea of cross-regions cooperation on some documents - to see how the world differs culturally even in areas where things should not be that much different - a BGP session is a BGP session, right? :) Cheers, Jan From zorz at isoc.org Thu May 22 09:19:57 2014 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Thu, 22 May 2014 09:19:57 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: References: <8654E7CF-37CE-457C-9E04-806118AA30BB@NLnetLabs.nl> Message-ID: <537DA51D.6050306@isoc.org> On 22/05/14 00:19, Chris Grundemann wrote: > 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. Indeed... Well, IPv6 for helpdesks document have been worked on just in RIPE region currently, but when we go through review/comment phase and reach the rough consensus in this region I'm looking into submitting it alos to NANOG BCOP for review and see what happens ;) cheers, Jan From zorz at isoc.org Thu May 22 09:22:01 2014 From: zorz at isoc.org (Jan Zorz - ISOC) Date: Thu, 22 May 2014 09:22:01 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: References: Message-ID: <537DA599.3090506@isoc.org> On 22/05/14 08:13, Alex Saroyan wrote: > 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 Brilliant! We can start forming a group with Francios Contat and see how we can move forward thnx, Jan From karsten_thomann at linfre.de Thu May 22 11:22:19 2014 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Thu, 22 May 2014 11:22:19 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: References: Message-ID: <537DC1CB.3060402@linfre.de> Hi, I would also like to participate as much as my time allows. Am 22.05.2014 08:13, schrieb Alex Saroyan: > 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 wrote: > >> On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong 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 >>> 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 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 at mailman.nanog.org >>>> http://mailman.nanog.org/mailman/listinfo/bcop >>> >>> >>> _______________________________________________ >>> BCOP mailing list >>> BCOP at mailman.nanog.org >>> http://mailman.nanog.org/mailman/listinfo/bcop >>> >> >> >> -- >> @ChrisGrundemann >> http://chrisgrundemann.com >> From jan at go6.si Thu May 22 11:30:22 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 22 May 2014 11:30:22 +0200 Subject: [bcop] BCOP presentation at RIPE meeting in Warsaw In-Reply-To: References: <53467548.9050407@go6.si> Message-ID: <537DC3AE.7080809@go6.si> On 15/05/14 00:57, Jen Linkova wrote: > Hi Jan, > > finally I've managed to summarize my comments to the doc ;) Hi, thank you very much for all your comments. I'm bringing part of this discussion to IPv6 WG mailing list as it is of technical nature and I think it belongs here. I put all your comments in our issues tracker, reachable publicly at https://git.steffann.nl/go6/ipv6-troubleshooting-for-helpdesks/issues > 1) You suggest to have a local mirror of the test-ipv6. While it > definitely makes sense, using the local mirror might hide some edge > connectivity issues so it worth mentioning. We might recommend to use > *both*. Yes, absolutely. This diversity would also help the ISP to understand if he has any IPv6 issues in other parts of the network other than access ;) > > 2) Section 5 > You provide detailed instruction on how to run ping, but then saying > just 'check DNS settings' and even 'configure different servers' - > support engineers who need explanations on ping, would need more > detailed explanations on how to change DNS settings. > > "If IPv4 is working but the page is unavaliable' - I'd assume that an > engineer could not tell if 'IPv4 is working'. So IMHO we shall just > say that if site is unreachange - troubleshoot as any other 'I can not > open this page' v4-only case. > If we believe that troubleshooting such case is in scope of this > document, I'd suggest to include traceroute as a troubleshooting step. seems as a good idea. let us think about that ;) > > 3) Helpdesk code section: > I'd use different fonts/color to distinguish between 'fixed' and > 'example' fields in the output. > > 4) Code 112 (v4 + broken Ipv6) > > - can we show the process as a flowchart? if-then-else? that's a bit hard one... do we have anybody specialized in flowcharts here? > For example, the doc says 'determine if Ipv6 is offered'. I'd add 'if > it is not,, the customer either has a misconfigured CPE (which has > IPv6 enables while it should not), or there is other Ipv6-enabled > device which is used as a router. Check CPE configuration/state for > IPv6 and disable it if it has it enabled'. > > - I'd re-phrase step 2 as smth like 'if IPv6 is offered to the > customer and you manage their CPE, check if CPE has a approved > firmware version. Upgrade it if it does not'. > > - I'd say that grep (to find the IPv6 address on MacOS) should be > 'grep -E "en|inet6" so interface name is visible (to avoid the scnario > when addresses are assigned to wrong interface); > > - the IPv6 addresses table is a little bit confusing: > -- it contains 6to4 case which should not cause code 112 (as well as > Teredo case); > -- some sections say 'call theor router vendor for support'. I > believe we shall clarify somewhere in the beginning of the document > that we assume that the support deals with customers CPE and if it is > not a case, those CPE-related instructions should be either 'escalate' > or 'advise customer to contact their router vendor for support' (which > in my reality would never happen.....:) > -- as each section of the tabel has instructions (and the last row > says 'escalate', it is not clear in which case the engieer should > proceed to the next step (checking the home router config). > > the section of home router config check is a little bit confusing. > When we just say 'check the configuration of the device', it does not > mean much as we don't specify what we are looking for. Maybe we shall > say smth like: > - 'if CPE is managed by your support, check if CPE is configured as > per your internal documentation' (as we might say somewhere in the doc > that in that case it is strongly recommended to have a separate how-to > on what should be configured on those CPEs); > - check if the LAN interface has IPv6 address from the ISP allocated range; > - check on user device if it has routers's both link-local (fe80:...) > and ISP-assigned address in the neighbor discovery cache ( commands); > - check the routing table on the user's device; see if the default > route points to the router's address. If not - check if DHCP and or > RAs are enabled on the home router. > - run ipv6 traceroute to isp.test-ipv6 site and see where the traceroure stops. I think this are all good suggestions. We'll go through them during our authosr edit cycle meeting, probably during the IETF meeting in Toronto. > > > Code 46 Section > - I'd sugegst to run traceroute to see where it stops. If traceroute > does not show any issues - escalate. If it does outside of your > network - contact the affected netwokr NOC. ack... > > > IMHO a section should be added which explains what kind of information > should be collected for an escalation. I'd suggest: > - Ipv4 and Ipv6 traceroute; > - ifconfig output > - routing table output > - maybe packet capture for the session which is having issues. I think this is asking a bit too much to a first level helpdesk employee... I don't know... Cheers, Jan From jan at go6.si Thu May 22 11:35:25 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 22 May 2014 11:35:25 +0200 Subject: [bcop] BCOP presentation at RIPE meeting in Warsaw In-Reply-To: References: <53467548.9050407@go6.si> Message-ID: <537DC4DD.5020907@go6.si> [now with IPv6 WG address in cc:, actually] On 15/05/14 00:57, Jen Linkova wrote: > Hi Jan, > > finally I've managed to summarize my comments to the doc ;) Hi, thank you very much for all your comments. I'm bringing part of this discussion to IPv6 WG mailing list as it is of technical nature and I think it belongs here. I put all your comments in our issues tracker, reachable publicly at https://git.steffann.nl/go6/ipv6-troubleshooting-for-helpdesks/issues > 1) You suggest to have a local mirror of the test-ipv6. While it > definitely makes sense, using the local mirror might hide some edge > connectivity issues so it worth mentioning. We might recommend to use > *both*. Yes, absolutely. This diversity would also help the ISP to understand if he has any IPv6 issues in other parts of the network other than access ;) > > 2) Section 5 > You provide detailed instruction on how to run ping, but then saying > just 'check DNS settings' and even 'configure different servers' - > support engineers who need explanations on ping, would need more > detailed explanations on how to change DNS settings. > > "If IPv4 is working but the page is unavaliable' - I'd assume that an > engineer could not tell if 'IPv4 is working'. So IMHO we shall just > say that if site is unreachange - troubleshoot as any other 'I can not > open this page' v4-only case. > If we believe that troubleshooting such case is in scope of this > document, I'd suggest to include traceroute as a troubleshooting step. seems as a good idea. let us think about that ;) > > 3) Helpdesk code section: > I'd use different fonts/color to distinguish between 'fixed' and > 'example' fields in the output. > > 4) Code 112 (v4 + broken Ipv6) > > - can we show the process as a flowchart? if-then-else? that's a bit hard one... do we have anybody specialized in flowcharts here? > For example, the doc says 'determine if Ipv6 is offered'. I'd add 'if > it is not,, the customer either has a misconfigured CPE (which has > IPv6 enables while it should not), or there is other Ipv6-enabled > device which is used as a router. Check CPE configuration/state for > IPv6 and disable it if it has it enabled'. > > - I'd re-phrase step 2 as smth like 'if IPv6 is offered to the > customer and you manage their CPE, check if CPE has a approved > firmware version. Upgrade it if it does not'. > > - I'd say that grep (to find the IPv6 address on MacOS) should be > 'grep -E "en|inet6" so interface name is visible (to avoid the scnario > when addresses are assigned to wrong interface); > > - the IPv6 addresses table is a little bit confusing: > -- it contains 6to4 case which should not cause code 112 (as well as > Teredo case); > -- some sections say 'call theor router vendor for support'. I > believe we shall clarify somewhere in the beginning of the document > that we assume that the support deals with customers CPE and if it is > not a case, those CPE-related instructions should be either 'escalate' > or 'advise customer to contact their router vendor for support' (which > in my reality would never happen.....:) > -- as each section of the tabel has instructions (and the last row > says 'escalate', it is not clear in which case the engieer should > proceed to the next step (checking the home router config). > > the section of home router config check is a little bit confusing. > When we just say 'check the configuration of the device', it does not > mean much as we don't specify what we are looking for. Maybe we shall > say smth like: > - 'if CPE is managed by your support, check if CPE is configured as > per your internal documentation' (as we might say somewhere in the doc > that in that case it is strongly recommended to have a separate how-to > on what should be configured on those CPEs); > - check if the LAN interface has IPv6 address from the ISP allocated range; > - check on user device if it has routers's both link-local (fe80:...) > and ISP-assigned address in the neighbor discovery cache ( commands); > - check the routing table on the user's device; see if the default > route points to the router's address. If not - check if DHCP and or > RAs are enabled on the home router. > - run ipv6 traceroute to isp.test-ipv6 site and see where the traceroure stops. I think this are all good suggestions. We'll go through them during our authosr edit cycle meeting, probably during the IETF meeting in Toronto. > > > Code 46 Section > - I'd sugegst to run traceroute to see where it stops. If traceroute > does not show any issues - escalate. If it does outside of your > network - contact the affected netwokr NOC. ack... > > > IMHO a section should be added which explains what kind of information > should be collected for an escalation. I'd suggest: > - Ipv4 and Ipv6 traceroute; > - ifconfig output > - routing table output > - maybe packet capture for the session which is having issues. I think this is asking a bit too much to a first level helpdesk employee... I don't know... Cheers, Jan From jan at go6.si Thu May 22 11:36:28 2014 From: jan at go6.si (Jan Zorz @ go6.si) Date: Thu, 22 May 2014 11:36:28 +0200 Subject: [bcop] BCOP presentation at RIPE meeting in Warsaw In-Reply-To: References: <53467548.9050407@go6.si> Message-ID: <537DC51C.4070702@go6.si> On 15/05/14 00:57, Jen Linkova wrote: > Hi Jan, > > finally I've managed to summarize my comments to the doc ;) > > 0) the document says that the target audience is residential ISPs and > enterprise IT helpdesk while most of troubleshooting steps are mostly > applicable for residential ISPs as they imply that there are CPE/home > devices/etc. Shall we create another doc for enterprise networks or > just extend this one? Hi, This is a discussion for BCOP crowd... Suggestions? Cheers, Jan From sb at lab.dtag.de Thu May 22 11:31:45 2014 From: sb at lab.dtag.de (Sebastian Becker) Date: Thu, 22 May 2014 11:31:45 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: <537DC1CB.3060402@linfre.de> References: <537DC1CB.3060402@linfre.de> Message-ID: <13151AD7-8F77-4032-B07D-7569F6208BFE@lab.dtag.de> +1! Me, too! -- Sebastian Becker sb at lab.dtag.de Am 22.05.2014 um 11:22 schrieb Karsten Thomann : > Hi, > > I would also like to participate as much as my time allows. > > Am 22.05.2014 08:13, schrieb Alex Saroyan: >> 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 wrote: >> >>> On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong 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 >>>> 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 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 at mailman.nanog.org >>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>> >>>> >>>> _______________________________________________ >>>> BCOP mailing list >>>> BCOP at mailman.nanog.org >>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>> >>> >>> >>> -- >>> @ChrisGrundemann >>> http://chrisgrundemann.com >>> > > ############################################## # Mail Account for technical purposes only ############################################## From hlk at solido.net Thu May 22 11:31:47 2014 From: hlk at solido.net (=?iso-8859-1?Q?Henrik_Lund_Kramsh=F8j?=) Date: Thu, 22 May 2014 11:31:47 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: <537DC1CB.3060402@linfre.de> References: <537DC1CB.3060402@linfre.de> Message-ID: <5948EC4B-45CA-4E49-AC21-CC969819C1EC@solido.net> On 22/05/2014, at 11.22, Karsten Thomann wrote: > Hi, > > I would also like to participate as much as my time allows. +1 We are also a very small organization, so we can share a lot of our internal docs/templates without restrictions. Best regards Henrik > > Am 22.05.2014 08:13, schrieb Alex Saroyan: >> 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 wrote: >> >>> On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong 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 >>>> 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 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 at mailman.nanog.org >>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>> >>>> >>>> _______________________________________________ >>>> BCOP mailing list >>>> BCOP at mailman.nanog.org >>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>> >>> >>> >>> -- >>> @ChrisGrundemann >>> http://chrisgrundemann.com >>> > > -- Henrik Lund Kramsh?j, Follower of the Great Way of Unix internet samurai cand.scient CISSP hlk at kramse.org hlk at solidonetworks.com +45 2026 6000 http://solidonetworks.com/ Network Security is a business enabler -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: Message signed with OpenPGP using GPGMail URL: From benno at NLnetLabs.nl Thu May 22 16:05:46 2014 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Thu, 22 May 2014 16:05:46 +0200 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: <5948EC4B-45CA-4E49-AC21-CC969819C1EC@solido.net> References: <537DC1CB.3060402@linfre.de> <5948EC4B-45CA-4E49-AC21-CC969819C1EC@solido.net> Message-ID: <537E043A.40205@NLnetLabs.nl> Thanks all. This is really great! I will make sure Francois and his colleagues will be in the loop (see CC). I guess there will be coordination between the NANOG, JANOG, and RIPE BCOP activities (Chris, Jan, and others?). It would be great to learn from each other from different regions. For the RIPE area, we need to make a plan, some time lines, people involved, etc., such that we coordinate activities and monitor some progress. I will not contribute to the document though, that is up to you, but I can help you out in facilitating the activities, coordination, etc. Just a helping hand. Cheers, -- Benno On 22/05/14 11:31, Henrik Lund Kramsh?j wrote: > > On 22/05/2014, at 11.22, Karsten Thomann > wrote: > >> Hi, >> >> I would also like to participate as much as my time allows. > > +1 > > We are also a very small organization, so we can share a lot of our > internal docs/templates without restrictions. > > > Best regards > > Henrik > > >> >> Am 22.05.2014 08:13, schrieb Alex Saroyan: >>> 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 wrote: >>> >>>> On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong >>>> 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 >>>>> 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 >>>>>> 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 at mailman.nanog.org >>>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>>> >>>>> >>>>> _______________________________________________ BCOP >>>>> mailing list BCOP at mailman.nanog.org >>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>>> >>>> >>>> >>>> -- @ChrisGrundemann http://chrisgrundemann.com >>>> >> >> > > -- Henrik Lund Kramsh?j, Follower of the Great Way of Unix internet > samurai cand.scient CISSP hlk at kramse.org hlk at solidonetworks.com +45 > 2026 6000 http://solidonetworks.com/ Network Security is a business > enabler > -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From Li.Li at terago.ca Thu May 22 16:39:49 2014 From: Li.Li at terago.ca (Li Li) Date: Thu, 22 May 2014 14:39:49 +0000 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: <537E043A.40205@NLnetLabs.nl> References: <537DC1CB.3060402@linfre.de> <5948EC4B-45CA-4E49-AC21-CC969819C1EC@solido.net> <537E043A.40205@NLnetLabs.nl> Message-ID: <90D761DEFB1F87449ED5CEA38983ACD41EB4BD@tornv42.teraint.net> I am also interested in participating and sharing my experience. Regards, Li Li -----Original Message----- From: BCOP [mailto:bcop-bounces at mailman.nanog.org] On Behalf Of Benno Overeinder Sent: Thursday, May 22, 2014 10:06 AM To: Henrik Lund Kramsh?j; Karsten Thomann Cc: Markus de Br?n; Francois C; Alex Saroyan; bcop at mailman.nanog.org; Bill Armstrong; Guillaume Valadon; bcop at ripe.net Subject: Re: [BCOP-discuss] [bcop] eBGP Configuration BCOP - Call for Volunteer SMEs Thanks all. This is really great! I will make sure Francois and his colleagues will be in the loop (see CC). I guess there will be coordination between the NANOG, JANOG, and RIPE BCOP activities (Chris, Jan, and others?). It would be great to learn from each other from different regions. For the RIPE area, we need to make a plan, some time lines, people involved, etc., such that we coordinate activities and monitor some progress. I will not contribute to the document though, that is up to you, but I can help you out in facilitating the activities, coordination, etc. Just a helping hand. Cheers, -- Benno On 22/05/14 11:31, Henrik Lund Kramsh?j wrote: > > On 22/05/2014, at 11.22, Karsten Thomann > wrote: > >> Hi, >> >> I would also like to participate as much as my time allows. > > +1 > > We are also a very small organization, so we can share a lot of our > internal docs/templates without restrictions. > > > Best regards > > Henrik > > >> >> Am 22.05.2014 08:13, schrieb Alex Saroyan: >>> 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 wrote: >>> >>>> On Wed, May 21, 2014 at 4:13 PM, Bill Armstrong >>>> 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 >>>>> 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 >>>>>> 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 at mailman.nanog.org >>>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>>> >>>>> >>>>> _______________________________________________ BCOP mailing list >>>>> BCOP at mailman.nanog.org >>>>> http://mailman.nanog.org/mailman/listinfo/bcop >>>>> >>>> >>>> >>>> -- @ChrisGrundemann http://chrisgrundemann.com >>>> >> >> > > -- Henrik Lund Kramsh?j, Follower of the Great Way of Unix internet > samurai cand.scient CISSP hlk at kramse.org hlk at solidonetworks.com +45 > 2026 6000 http://solidonetworks.com/ Network Security is a business > enabler > -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ _______________________________________________ BCOP mailing list BCOP at mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/bcop From modonovan at btireland.net Thu May 22 22:07:42 2014 From: modonovan at btireland.net (Mick O'Donovan) Date: Thu, 22 May 2014 21:07:42 +0100 Subject: [bcop] [BCOP-discuss] eBGP Configuration BCOP - Call for Volunteer SMEs In-Reply-To: <537DA599.3090506@isoc.org> References: <537DA599.3090506@isoc.org> Message-ID: <8AF2045F-2D87-47B1-B035-6F1ACD0EDBCE@btireland.net> I?m a total newbie but (maybe naively) I would like to participate in this also. Mick On 22 May 2014, at 08:22, Jan Zorz - ISOC wrote: > On 22/05/14 08:13, Alex Saroyan wrote: >> 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 > > Brilliant! > > We can start forming a group with Francios Contat and see how we can move forward > > thnx, Jan >